I think this should be removed entirely. I added it in 2005 because Mesa back then choked on our protected memory(X server freeze or kernel panic). Around 2008 I checked if this bug still exists, and it seems to be fixed.
If anyone still runs into this bug he should seriously consider upgrading his Mesa installation...
Am 07.05.2010 um 23:20 schrieb Gerald Pfeifer:
Looking at the current code in flush_to_framebuffer_drawpixels it occurs to me that we really need to mark the memory we want to _read_ volatile, not the local variable that is used to "force" reading said memory.
That is more direct, more logical, and even more efficient.
Looking at the generated code of all of dlls/wined3d/surface.c the only material difference is
movb %al, -25(%ebp)
which is saving the byte we are trying to read onto the stack and into the local variable. And that is the part that indeed is not necessary.
Gerald
dlls/wined3d/surface.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c index bb18b95..199a1bd 100644 --- a/dlls/wined3d/surface.c +++ b/dlls/wined3d/surface.c @@ -1839,8 +1839,7 @@ static void flush_to_framebuffer_drawpixels(IWineD3DSurfaceImpl *This, GLenum fm * ReleaseDC, and the app won't use the dc any more afterwards. */ if((This->Flags & SFLAG_DIBSECTION) && !(This->Flags & SFLAG_PBO)) {
volatile BYTE read;read = This->resource.allocatedMemory[0];
*(volatile BYTE*)This->resource.allocatedMemory;}
if(This->Flags & SFLAG_PBO) {
-- 1.6.6.2