Re: DRI2 cliprect
On Nov 22, 2007 12:19 PM, Jerome Glisse [EMAIL PROTECTED] wrote: Hi Kristian, Got a question on cliprect this might be dumb but what happen if hw is limited on numbers of cliprect it can handle ? Does the X server also provide some kind of informations like buffer draw order (in which case cliprect are only usefull to save cpy memory) ? The plan for DRI2 is to always have private back buffers (well, non-clipped at least, they may be shared with other clients), and to do double buffering, even for single-buffered fbconfigs. The cliprects are kept in the kernel and the swap buffer is implemented there. This will just do a copy of the clip rects from the back buffer to the front buffer. So the DRI driver won't have to worry about cliprects at all, and hardware can't limit the amount of cliprects, since we just have to do a bitblt per cliprect. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On Nov 22, 2007 4:23 AM, Keith Whitwell [EMAIL PROTECTED] wrote: ... My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. The way drivers actually work at the moment is to emit a full state as a preamble to each batchbuffer. Depending on the hardware, this can be pretty low overhead, and it seems that the trend in hardware is to make this operation cheaper and cheaper. This works fine without the lock. There is another complimentary trend to support one way or another multiple hardware contexts (obviously nvidia have done this for years), meaning that effectively the hardware (effectively) does the context switches. This is probably how most cards will end up working in the future, if not already. Neither of these need a lock for detecting context switches. Sure enough, but the problem is that without the lock userspace can't say oops, I lost the context, let me prepend this state emission preamble to the batchbuffer. in a race free way. If we want conditional state emission, we need to make that decision in the kernel. For example, the super ioctl could send the state emission code as a separate buffer and also include the expected context handle. This lets the kernel compare the context handle supplied in the super ioctl with the most recently active context handle, and if they differ, the kernel queues the state emission buffer first and then the rendering buffer. If the context handles match, the kernel just queues the rendering batch buffer. However, this means that user space must prepare the state emission code for each submission, whether or not it will actually be used. I'm not sure if this is too much overhead or if it's negligible? Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Kristian Høgsberg wrote: On Nov 22, 2007 4:23 AM, Keith Whitwell [EMAIL PROTECTED] wrote: ... My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. The way drivers actually work at the moment is to emit a full state as a preamble to each batchbuffer. Depending on the hardware, this can be pretty low overhead, and it seems that the trend in hardware is to make this operation cheaper and cheaper. This works fine without the lock. There is another complimentary trend to support one way or another multiple hardware contexts (obviously nvidia have done this for years), meaning that effectively the hardware (effectively) does the context switches. This is probably how most cards will end up working in the future, if not already. Neither of these need a lock for detecting context switches. Sure enough, but the problem is that without the lock userspace can't say oops, I lost the context, let me prepend this state emission preamble to the batchbuffer. in a race free way. If we want conditional state emission, we need to make that decision in the kernel. The cases I describe above don't try to do this, but if you really wanted to, the way to do it would be to have userspace always emit the preamble but pass two offsets to the kernel, one at the start of the preamble, the other after it. Then the kernel can choose. I don't think there's a great deal to be gained from this optimization, though. For example, the super ioctl could send the state emission code as a separate buffer and also include the expected context handle. This lets the kernel compare the context handle supplied in the super ioctl with the most recently active context handle, and if they differ, the kernel queues the state emission buffer first and then the rendering buffer. If the context handles match, the kernel just queues the rendering batch buffer. However, this means that user space must prepare the state emission code for each submission, whether or not it will actually be used. I'm not sure if this is too much overhead or if it's negligible? I think both preparing it on CPU and executing it on GPU are likely to be pretty negligible, but some experimentation on a system with just a single app running should show this quickly one way or another. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On Nov 22, 2007 5:37 AM, Jerome Glisse [EMAIL PROTECTED] wrote: ... I will go this way too for r300/r400/r500 there is not so much registers change with different contexts and registers which need special treatment will be handled by the drm (this boils down to where 3d get rendered and where is the zbuffer and pitch/tile informations on this 2 buffers; this informations will be embedded in drm_drawable as the cliprect if i am right :)). It will be up to client to reemit enough state for the card to be in good shape for its rendering and i don't think it's worthwhile to provide facilities to keep hw in a given state. Are you suggesting we emit the state for every batchbuffer submission? As I wrote in my reply to Keith, without a lock, you can't check that the state is what you expect and the submit a batchbuffer from user space. The check has to be done in the kernel, and then kernel will then emit the state conditionally. And even if this scheme can eliminate unecessary state emission, the state still have to be passed to the kernel with every batch buffer submission, in case the kernel need to emit it. So i don't need a lock and indeed my actual code doesn't use any except for ring buffer emission (only shared area among different client i can see in my case). So you do need a lock? Could the ring buffer management be done in the drm by the super-ioctl code and would that eliminate the need for a sarea? Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On Nov 22, 2007 4:03 AM, Thomas Hellström [EMAIL PROTECTED] wrote: ... There are probably various ways to do this, which is another argument for keeping super-ioctls device-specific. For i915-type hardware, Dave's approach above is probably the most attracting one. For Poulsbo, all state is always implicitly included, usually as a reference to a buffer object, so we don't really bother about contexts here. For hardware like the Unichrome, the state is stored in a limited set of registers. Here the drm can keep a copy of those registers for each context and do a smart update on a context switch. However, there are cases where it is very difficult to use cliprects from the drm, though I wouldn't say impossible. The idea is to keep the cliprects in the kernel and only render double buffered. The only code that needs to worry about cliprects is swap buffer, either immediate or synced to vblank. What are the cliprect problems you mention? Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13391] Intermittent Xorg crashes with compiz
http://bugs.freedesktop.org/show_bug.cgi?id=13391 --- Comment #2 from [EMAIL PROTECTED] 2007-11-26 11:37 PST --- Created an attachment (id=12728) -- (http://bugs.freedesktop.org/attachment.cgi?id=12728action=view) Another log datapoint for a crashed server This was running Mesa a8fee3a498c8c4966d57a5273408477f3aa3ce73 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13391] Intermittent Xorg crashes with compiz
http://bugs.freedesktop.org/show_bug.cgi?id=13391 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #12728|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13391] Intermittent Xorg crashes with compiz
http://bugs.freedesktop.org/show_bug.cgi?id=13391 --- Comment #3 from [EMAIL PROTECTED] 2007-11-26 11:40 PST --- I've been compiling Mesa with -ggdb -g3 -O1. Can anyone see any reason why my stack traces don't have line numbers? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Kristian Høgsberg wrote: On Nov 22, 2007 5:37 AM, Jerome Glisse [EMAIL PROTECTED] wrote: ... I will go this way too for r300/r400/r500 there is not so much registers change with different contexts and registers which need special treatment will be handled by the drm (this boils down to where 3d get rendered and where is the zbuffer and pitch/tile informations on this 2 buffers; this informations will be embedded in drm_drawable as the cliprect if i am right :)). It will be up to client to reemit enough state for the card to be in good shape for its rendering and i don't think it's worthwhile to provide facilities to keep hw in a given state. Are you suggesting we emit the state for every batchbuffer submission? As I wrote in my reply to Keith, without a lock, you can't check that the state is what you expect and the submit a batchbuffer from user space. The check has to be done in the kernel, and then kernel will then emit the state conditionally. And even if this scheme can eliminate unecessary state emission, the state still have to be passed to the kernel with every batch buffer submission, in case the kernel need to emit it. I didn't explained myself properly, i did mean that it's up to the client to reemit all state in each call to superioctl so there will be full state emission but i won't check it ie if it doesn't emit full state then userspace can just expect to buggy rendering. Meanwhile there is few things i don't want the userspace to mess with as they likely need special treatment like the offset in ram where 3d rendering is going to happen, where are ancillary buffers, ... i expect to have all this informations attached to a drm_drawable (rendering buffer, ancillary buffer, ...) so each call of superioctl will have this: -drm_drawable (where rendering will be) -full state -additional buffers needed for rendering (vertex buffer, textures, ...) So i don't need a lock and indeed my actual code doesn't use any except for ring buffer emission (only shared area among different client i can see in my case). So you do need a lock? Could the ring buffer management be done in the drm by the super-ioctl code and would that eliminate the need for a sarea? This ring lock is for internal use only, so if one client is in superioctl and another is emitting a fence both need to write to ring but with different path to avoid any userspace lock i have a kernel lock which any functions writing to ring need to take; as writing to ring should be short this shouldn't hurt. So no i don't need a lock and i don't want a lock :) Hope i expressed myself better :) Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13181] i915: mipmap rendering broken
http://bugs.freedesktop.org/show_bug.cgi?id=13181 --- Comment #10 from [EMAIL PROTECTED] 2007-11-26 13:16 PST --- I downgraded from GIT to 7.0.2 and the problem doesn't occur anymore. Going to stay with 7.0.2 until the next stable release. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On Nov 26, 2007 3:40 PM, Jerome Glisse [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: On Nov 22, 2007 5:37 AM, Jerome Glisse [EMAIL PROTECTED] wrote: ... I will go this way too for r300/r400/r500 there is not so much registers change with different contexts and registers which need special treatment will be handled by the drm (this boils down to where 3d get rendered and where is the zbuffer and pitch/tile informations on this 2 buffers; this informations will be embedded in drm_drawable as the cliprect if i am right :)). It will be up to client to reemit enough state for the card to be in good shape for its rendering and i don't think it's worthwhile to provide facilities to keep hw in a given state. Are you suggesting we emit the state for every batchbuffer submission? As I wrote in my reply to Keith, without a lock, you can't check that the state is what you expect and the submit a batchbuffer from user space. The check has to be done in the kernel, and then kernel will then emit the state conditionally. And even if this scheme can eliminate unecessary state emission, the state still have to be passed to the kernel with every batch buffer submission, in case the kernel need to emit it. I didn't explained myself properly, i did mean that it's up to the client to reemit all state in each call to superioctl so there will be full state emission but i won't check it ie if it doesn't emit full state then userspace can just expect to buggy rendering. Meanwhile there is few things i don't want the userspace to mess with as they likely need special treatment like the offset in ram where 3d rendering is going to happen, where are ancillary buffers, ... i expect to have all this informations attached to a drm_drawable (rendering buffer, ancillary buffer, ...) so each call of superioctl will have this: -drm_drawable (where rendering will be) -full state -additional buffers needed for rendering (vertex buffer, textures, ...) Great, thanks for clarifying. Sounds good. So i don't need a lock and indeed my actual code doesn't use any except for ring buffer emission (only shared area among different client i can see in my case). So you do need a lock? Could the ring buffer management be done in the drm by the super-ioctl code and would that eliminate the need for a sarea? This ring lock is for internal use only, so if one client is in superioctl and another is emitting a fence both need to write to ring but with different path to avoid any userspace lock i have a kernel lock which any functions writing to ring need to take; as writing to ring should be short this shouldn't hurt. So no i don't need a lock and i don't want a lock :) Hope i expressed myself better :) Hehe, I guess I've been a bit unclear too: what I want to make sure we can get rid of is the *userspace* lock that's currently shared between the X server and the DRI clients. What hear you saying above is that you still need a kernel side lock to synchronize access to the ring buffer, which of course is required. The ring buffer and the lock that protects is lives in the kernel and user space can't access it directly. When emitting batchbuffers or fences, the ioctl() will need to take the lock, but will always release it before returning back to userspace. Sounds like this will all work out after all :) Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Kristian Høgsberg wrote: On Nov 26, 2007 3:40 PM, Jerome Glisse [EMAIL PROTECTED] wrote: Kristian Høgsberg wrote: On Nov 22, 2007 5:37 AM, Jerome Glisse [EMAIL PROTECTED] wrote: ... I will go this way too for r300/r400/r500 there is not so much registers change with different contexts and registers which need special treatment will be handled by the drm (this boils down to where 3d get rendered and where is the zbuffer and pitch/tile informations on this 2 buffers; this informations will be embedded in drm_drawable as the cliprect if i am right :)). It will be up to client to reemit enough state for the card to be in good shape for its rendering and i don't think it's worthwhile to provide facilities to keep hw in a given state. Are you suggesting we emit the state for every batchbuffer submission? As I wrote in my reply to Keith, without a lock, you can't check that the state is what you expect and the submit a batchbuffer from user space. The check has to be done in the kernel, and then kernel will then emit the state conditionally. And even if this scheme can eliminate unecessary state emission, the state still have to be passed to the kernel with every batch buffer submission, in case the kernel need to emit it. I didn't explained myself properly, i did mean that it's up to the client to reemit all state in each call to superioctl so there will be full state emission but i won't check it ie if it doesn't emit full state then userspace can just expect to buggy rendering. Meanwhile there is few things i don't want the userspace to mess with as they likely need special treatment like the offset in ram where 3d rendering is going to happen, where are ancillary buffers, ... i expect to have all this informations attached to a drm_drawable (rendering buffer, ancillary buffer, ...) so each call of superioctl will have this: -drm_drawable (where rendering will be) -full state -additional buffers needed for rendering (vertex buffer, textures, ...) Great, thanks for clarifying. Sounds good. So i don't need a lock and indeed my actual code doesn't use any except for ring buffer emission (only shared area among different client i can see in my case). So you do need a lock? Could the ring buffer management be done in the drm by the super-ioctl code and would that eliminate the need for a sarea? This ring lock is for internal use only, so if one client is in superioctl and another is emitting a fence both need to write to ring but with different path to avoid any userspace lock i have a kernel lock which any functions writing to ring need to take; as writing to ring should be short this shouldn't hurt. So no i don't need a lock and i don't want a lock :) Hope i expressed myself better :) Hehe, I guess I've been a bit unclear too: what I want to make sure we can get rid of is the *userspace* lock that's currently shared between the X server and the DRI clients. What hear you saying above is that you still need a kernel side lock to synchronize access to the ring buffer, which of course is required. The ring buffer and the lock that protects is lives in the kernel and user space can't access it directly. When emitting batchbuffers or fences, the ioctl() will need to take the lock, but will always release it before returning back to userspace. Sounds like this will all work out after all :) Kristian Yes, between i started looking at your dri2 branch and didn't find dri2 branch in your intel ddx repository did you pushed the code anywhere else ? Would help me to see what i need to do for dri2 in ddx. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12570] [TTM] glean case depthStencil causes Assertion failure in DRI driver
http://bugs.freedesktop.org/show_bug.cgi?id=12570 Bug 12570 depends on bug 13091, which changed state. Bug 13091 Summary: [TTM] glean abort with Segmentation fault in GarbageCollectDRIDrawables http://bugs.freedesktop.org/show_bug.cgi?id=13091 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13091] [TTM] glean abort with Segmentation fault in GarbageCollectDRIDrawables
http://bugs.freedesktop.org/show_bug.cgi?id=13091 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|NEW |RESOLVED Component|Drivers/DRI/i915|GLX Resolution||FIXED --- Comment #4 from [EMAIL PROTECTED] 2007-11-26 18:38 PST --- I found that when GLX create dricontext and make context current, it will fetch a dri drawable and inserts this drawable into the glx Hash table. (code path: MakeContextCurrent-FetchDRIDrawable- __glxHashInsert). When GLX destory dricontext, it will look up glx Hash table and get the dri drawable and destroy it, but it forgets to delete the Hash entry!!! So when glean finish second round testing on second visual, it will destory the dri drawable, but it get the first dri drawable entry in hash table, which is wrong. Below is the patch, it will fix this bug. If it is OK, please commit it in. --- a/src/glx/x11/glxcmds.c +++ b/src/glx/x11/glxcmds.c @@ -101,6 +101,7 @@ static void GarbageCollectDRIDrawables(D longer exists in the Xserver */ (*pdraw-driDrawable.destroyDrawable)(pdraw-driDrawable); XF86DRIDestroyDrawable(dpy, sc-scr, draw); +__glxHashDelete(sc-drawHash, draw); Xfree(pdraw); } } while (__glxHashNext(sc-drawHash, draw, (void *)pdraw) == 1); -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
On Mon, 2007-11-26 at 17:15 -0500, Kristian Høgsberg wrote: -full state I assume you'll deal with hardware which supports multiple contexts and avoid the need to include full state with each buffer? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13091] glean abort with Segmentation fault in GarbageCollectDRIDrawables
http://bugs.freedesktop.org/show_bug.cgi?id=13091 [EMAIL PROTECTED] changed: What|Removed |Added Summary|[TTM] glean abort with |glean abort with |Segmentation fault in |Segmentation fault in |GarbageCollectDRIDrawables |GarbageCollectDRIDrawables -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: question about RADEONEnterServer()
On Tue, 2007-11-27 at 07:17 +0800, 郭超洪 wrote: /* TODO: Fix this more elegantly. * Sometimes (especially with multiple DRI clients), this code * runs immediately after a DRI client issues a rendering command. * * The accel code regularly inserts WAIT_UNTIL_IDLE into the * command buffer that is sent with the indirect buffer below. * The accel code fails to set the 3D cache flush registers for * the R300 before sending WAIT_UNTIL_IDLE. Sending a cache flush * on these new registers is not necessary for pure 2D functionality, * but it *is* necessary after 3D operations. * Without the cache flushes before WAIT_UNTIL_IDLE, the R300 locks up. * * The CP_IDLE call into the DRM indirectly flushes all caches and * thus avoids the lockup problem, but the solution is far from ideal. * Better solutions could be: * - always flush caches when entering the X server * - track the type of rendering commands somewhere and issue *cache flushes when they change * However, I don't feel confident enough with the control flow * inside the X server to implement either fix. -- nh if (info-ChipFamily=CHIP_FAMILY_R300) drmCommandNone(info-drmFD, DRM_RADEON_CP_IDLE); } This code is gone in current xf86-video-ati; grep it for info-needCacheFlush. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
