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
>
