[Bug 22567] intelx gma 45 blender broken

http://bugs.freedesktop.org/show_bug.cgi?id=22567

--- Comment #2 from tscmga <tscmga <at> gmail.com>  2009-06-30 18:11:06 PST ---
(In reply to comment #0)
> Created an attachment (id=27280)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=27280) [details]
> this is the screen shot of blender
> 
> OpenGL vendor string: Tungsten Graphics, Inc
> OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM
> 20090326 2009Q1 RC2 x86/MMX/SSE2
> OpenGL version string: 2.0 Mesa 7.4
> OpenGL shading language version string: 1.10
> 
> 
> 
> on this kernel blender is ok.
> Linux tscmga-laptop 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
> GNU/Linux
> 
> 
> but on this kernel blender is broken
> Linux tscmga-laptop 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC
> 2009 i686 GNU/Linux
>  other newer kernels has the same problem . 
> 
> it is like that glclear failed! becuase i am writing a game on linux ,i find a
> problem with glclear . i think this is a problem with . 
> and i find some nehe lesson failed to clear zbuffer (the vbo example ). the
> same problem with me. and i find a game failed clear zbuffer too. i solved this

[Bug 22567] New: intelx gma 45 blender broken

http://bugs.freedesktop.org/show_bug.cgi?id=22567

           Summary: intelx gma 45 blender broken
           Product: Mesa
           Version: unspecified
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: tscmga <at> gmail.com

Created an attachment (id=27280)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=27280)
this is the screen shot of blender

OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM
20090326 2009Q1 RC2 x86/MMX/SSE2
OpenGL version string: 2.0 Mesa 7.4
OpenGL shading language version string: 1.10

on this kernel blender is ok.
Linux tscmga-laptop 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
GNU/Linux

but on this kernel blender is broken
Linux tscmga-laptop 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC

[Bug 22567] intelx gma 45 blender broken

http://bugs.freedesktop.org/show_bug.cgi?id=22567

--- Comment #1 from tscmga <tscmga <at> gmail.com>  2009-06-30 18:08:36 PST ---
Created an attachment (id=27281)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=27281)
this is my opengl program. it using vbo. i didn't call
glbindvertexbufferarb(0),

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------

Re: Re : Re : Problem with the xdemo glsync

On Tue, 2009-06-30 at 09:18 -0700, Jesse Barnes wrote:
> That depends...  If you're getting hit by scheduling latency (i.e. your
> app doesn't actually get scheduled on the CPU until several ms after
> the vblank interrupt fires), then there's no easy way to fix it.  You
> could try realtime scheduling and configuring things just right so that
> your waiting apps always get scheduled in time, but that's going to be
> difficult in a general purpose environment.
> 
> If the interrupt is arriving too late, you could try one of the other
> hardware mechanisms (fire an interrupt at a scanline near the bottom of
> the screen instead, to give you some extra time or something).

Without looking at the demo source code, I suspect the problem might be
something else. The implementation of sgi_video_sync in Mesa simply
waits for the vblank interval and does nothing else.

So, if I:

 - Do a bunch of rendering
 - Wait for vblank
 - glXSwapBuffers

Then my command buffers will not be flushed to the video card until
after vblank. If the command buffers take time to execute, then the
swap buffers is delayed and you get a tear. So, you need to glFlush()
before waiting for vblank.

There's a more subtle reason why you want to actually glFinish() rather
than glFlush() - if your rendering takes long enough so that you can't
keep up with the refresh rate:

Re: Re : Re : Problem with the xdemo glsync

On Wed, 01 Jul 2009 11:53:14 -0400
Owen Taylor <otaylor <at> redhat.com> wrote:

> On Tue, 2009-06-30 at 09:18 -0700, Jesse Barnes wrote:
> > That depends...  If you're getting hit by scheduling latency (i.e.
> > your app doesn't actually get scheduled on the CPU until several ms
> > after the vblank interrupt fires), then there's no easy way to fix
> > it.  You could try realtime scheduling and configuring things just
> > right so that your waiting apps always get scheduled in time, but
> > that's going to be difficult in a general purpose environment.
> > 
> > If the interrupt is arriving too late, you could try one of the
> > other hardware mechanisms (fire an interrupt at a scanline near the
> > bottom of the screen instead, to give you some extra time or
> > something).
> 
> Without looking at the demo source code, I suspect the problem might
> be something else. The implementation of sgi_video_sync in Mesa simply
> waits for the vblank interval and does nothing else.
> 
> So, if I:
> 
>  - Do a bunch of rendering
>  - Wait for vblank
>  - glXSwapBuffers
> 
> Then my command buffers will not be flushed to the video card until
> after vblank. If the command buffers take time to execute, then the
> swap buffers is delayed and you get a tear. So, you need to glFlush()
> before waiting for vblank.

[RFC] PIPE_CAP_BLITTER

So, a couple months ago I opined about the inability of Gallium to
guarantee non-overlapping blits. I need to revisit the subject.

I can't detect when blits will overlap, every time, without massive hax,
and I'm not terribly certain that the hax work. Somehow (probably
through texture blanketing) I'm seeing two BOs, overlapping, being used
in texture_copy. I have no way of detecting that overlap at the moment,
and doing so is going to be icky.

I propose PIPE_CAP_BLITTER, a simple pipe cap that just says, "Yes, I
have a 2D engine or some other way to do overlapping blits magically."
If this isn't set, use one of the util functions that semi-fallback to
textured drawing instead of straight surface_copy. In some state
trackers (Xorg EXA) this also can be used to indicate to higher
userspace the abilities of the card in a way that permits optimizations.

Sorry for weird word choice; I'm running on like three cans of Red Bull
and a sleep deficit.

~ C.

------------------------------------------------------------------------------

[Bug 20291] reproducible segv during glean/makeCurrent, G45/G965

http://bugs.freedesktop.org/show_bug.cgi?id=20291

--- Comment #32 from zhao jian <jian.j.zhao <at> intel.com>  2009-07-02 01:27:56 PST ---
Yes. I tried with the newest code on G45, it works well. 
Libdrm:         (master)de1ed01214874dcdd6116ff2587c8710d6ed4d2d
Mesa:           (master)5e6b593d35156a0068dc0eb3e55dec086f1cadd3
Xserver:        (master)3525d140567e0ad5f0184e4b37893c47239e1628
Xf86_video_intel:  (master)1e4784bf26e3c154f5673f7b5add3ef7af3b1474

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

------------------------------------------------------------------------------

Re: [RFC] PIPE_CAP_BLITTER

On Wed, 2009-07-01 at 23:47 -0700, Corbin Simpson wrote:
> So, a couple months ago I opined about the inability of Gallium to
> guarantee non-overlapping blits. I need to revisit the subject.
> 
> I can't detect when blits will overlap, every time, without massive hax,
> and I'm not terribly certain that the hax work. Somehow (probably
> through texture blanketing) I'm seeing two BOs, overlapping, being used
> in texture_copy. I have no way of detecting that overlap at the moment,
> and doing so is going to be icky.
> 
> I propose PIPE_CAP_BLITTER, a simple pipe cap that just says, "Yes, I
> have a 2D engine or some other way to do overlapping blits magically."
> If this isn't set, use one of the util functions that semi-fallback to
> textured drawing instead of straight surface_copy. In some state
> trackers (Xorg EXA) this also can be used to indicate to higher
> userspace the abilities of the card in a way that permits optimizations.
> 
> Sorry for weird word choice; I'm running on like three cans of Red Bull
> and a sleep deficit.

I think this is pretty reasonable -- the alternative is just to ditch
the blitter functionality altogether.  It's a pretty wierd little pimple
on the side of an otherwise fairly focused set of interfaces, providing
exceptions to most rules (eg: the only surfaces being modified are those
bound with pipe_framebuffer_state... unless you use pipe_surface_copy())

I really wouldn't be sad to see them go...

Keith

[PATCH] vbo: plug a leak

This patch plugs a leak triggerable by display lists. I am not
familiar with this part of mesa, maybe there are better ways to do
this, in that case regard the patch as a pointer to the problem.

Tested and works with sauerbraten and gears.

Please review!

Thanks,
Kristof

>From 5567e4ea594d95bd76b4df9feb408b49a466d378 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= <tade60 <at> freemail.hu>
Date: Wed, 1 Jul 2009 19:35:39 +0200
Subject: [PATCH 4/8] vbo: plug a leak

---
 src/mesa/vbo/vbo_save_api.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 3c4c8ac..d0f4949 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
 <at>  <at>  -380,6 +380,11  <at>  <at>  static void _save_compile_vertex_list( GLcontext *ctx )
    /* Reset our structures for the next run of vertices:
     */
    _save_reset_counters( ctx );
+
+   if (node->current_data) {

Re : Re : Re : Problem with the xdemo glsync

------------------------------------------------------------------------------

_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev