[Bug 91509] Depth render buffer corruption

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

            Bug ID: 91509
           Summary: Depth render buffer corruption
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/r200
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: stefandoesinger@gmx.at
        QA Contact: dri-devel@lists.freedesktop.org

Created attachment 117462
  --> https://bugs.freedesktop.org/attachment.cgi?id=117462&action=edit
Screenshot

Since my patches from a few months ago Wine can now use depth renderbuffers
instead of textures for FBOs if GL_ARB_depth_texture is not supported. This
makes FBOs work on r200, but it appears that there is some render corruption.
The best way to describe it is that some parts of the depth buffer seem to be
read or written to the wrong place inside the buffer.

The attached screenshots show the issue. The application I've run here is the
StencilMirror.exe sample from the DirectX 8 SDK. in fbo.png you see incorrect
draws at the edges of the window. nofbo.png uses the GLX drawable (GL_BACK)
instead of rendering to an FBO, which doesn't show the corruption.

The corruption seems to be resolution dependent. I don't see it when I am
running the application at 1400x1050 for example.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2859 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 326 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #1 from Stefan Dösinger <stefandoesinger@gmx.at> ---
Created attachment 117463
  --> https://bugs.freedesktop.org/attachment.cgi?id=117463&action=edit
Screenshot without FBOs

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1218 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 406 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #2 from Stefan Dösinger <stefandoesinger@gmx.at> ---
It seems that the corruption has something to do with FBO sizes where the width
is a multiple of 16. width = 112 to 128 works OK. 129 to 143 is broken. 144 to
160 works, 161 to 175 is broken and so on.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1160 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

Roland Scheidegger <sroland@vmware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #117462|text/plain                  |image/png
          mime type|                            |

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1055 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #3 from Alex Deucher <alexdeucher@gmail.com> ---
On r200, IIRC, linear depth buffers are not supported (only tiled).  I suspect
the cases where it works are when the width aligns to a tile multiple.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1068 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 788 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #4 from Roland Scheidegger <sroland@vmware.com> ---
As a quick hunch based on your observations and some quick look in the code, it
seems depth buffers need to be 128 byte aligned on r200 (and 64 byte on r100
though that's just based on the tile/untile code), but
radeon_alloc_renderbuffer_storage() only does it to 64 bytes: (pitch = ((cpp *
width + 63) & ~63) / cpp;)
Could you try out if increasing that to 128 byte alignment there would help?
For the heck of it I can't figure out though from where the window
depth/colorbuffers get their alignment, so I've no idea how that's calculated
there...
Not sure right now on color buffers neither...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1524 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1631 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #5 from Roland Scheidegger <sroland@vmware.com> ---
(In reply to Roland Scheidegger from comment #4)
> As a quick hunch based on your observations and some quick look in the code,
> it seems depth buffers need to be 128 byte aligned on r200 (and 64 byte on
> r100 though that's just based on the tile/untile code), but
> radeon_alloc_renderbuffer_storage() only does it to 64 bytes: (pitch = ((cpp
> * width + 63) & ~63) / cpp;)
> Could you try out if increasing that to 128 byte alignment there would help?
> For the heck of it I can't figure out though from where the window
> depth/colorbuffers get their alignment, so I've no idea how that's
> calculated there...
> Not sure right now on color buffers neither...

Actually if I see that right it looks like the xorg ati driver would align
things to 64 pixels for non-tiled surfaces and 256 / cpp for tiled ones (so
still 64 pixels for z24s8). That would be even twice of what I suggested above.
May not really be required, though. The docs seem to suggest 8 pixels for color
buffers both for r100 and r200 but tile sized if tiling is used (whatever the
tile size is, seems to be small though, clearly this has to be a micro-tile).
Depth buffer though says 8 pixels for r100 (or tile sized if tiling is enabled,
though on some chips you can't even disable it) and 32 pixels for r200 (though
given the tiling code I have some doubts that's enough for z16). In any case
though I stick to my 128byte recommendation for r200 depth buffers...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2464 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 503 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #6 from Michel Dänzer <michel@daenzer.net> ---
FWIW, the (micro-)tile size is always 8x8. With macro-tiling (called 2D tiling
with current GPUs) enabled, the pitch (and height, for calculating the memory
allocation size) must usually be aligned to a macro-tile boundary. Not sure
offhand how to calculate the macro-tile size on those old GPUs though.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1251 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91509] Depth render buffer corruption

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=91509

--- Comment #7 from Roland Scheidegger <sroland@vmware.com> ---
(In reply to Michel Dänzer from comment #6)
> FWIW, the (micro-)tile size is always 8x8. With macro-tiling (called 2D
> tiling with current GPUs) enabled, the pitch (and height, for calculating
> the memory allocation size) must usually be aligned to a macro-tile
> boundary. Not sure offhand how to calculate the macro-tile size on those old
> GPUs though.

I'm not sure if micro/macro-tiling really apply to r200 depth tiled buffers,
the pattern is quite different to color tiling.

Actually the docs say for rv200:
DEPTHOFFSET: "...128 bit aligned address. When tiling the offset must be
tile-aligned (2KB)"
DEPTHPITCH:"Pitch is specified in multiples of 8 pixels. When tiling the pitch
must be tile-aligned"

And for R200:
DEPTHOFFSET: "Z Buffer Offset must be aligned to 4KB"
DEPTHPITCH: "Pitch is specified in multiples of 32 pixels"

So, in r200, depthoffset wording takes into account that it is always tiled,
however depth pitch doesn't mention it at all, making it sound like no specific
alignment due to tiling would be required. Of course I don't know how true that
really is, in particular for z16 it seems it cannot be true (because the
formula in the driver for tiling only uses (pitch >> 7) both for z16 and z32).
Even if those 128bytes there would be sufficient you're probably quite right
that we're also missing height alignment adjustment (if we'd use 128 bytes for
width and 32 alignment for height that would give us the 4KB aligned blocks
overall too).
Oh, and based on the doc wording clearly the depth pitch would be wrongly
aligned on r100 too (even though based on the formula the driver uses (pitch >>
6) it looks like it could work).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2781 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel