| Bug ID | 89148 |
|---|---|
| Summary | r300g: Kernel rejected CS in Wine d3d multisample test |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/r300 |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | stefandoesinger@gmx.at |
| QA Contact | dri-devel@lists.freedesktop.org |
When running Wine's d3d8 and d3d9 tests in r300g an invalid command stream is sent to the kernel: [ 916.508352] [drm:radeon_cs_packet_parse] *ERROR* Unknown packet type 1 at 2451 ! [ 916.508358] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! [ 916.508902] [drm:radeon_cs_packet_parse] *ERROR* Unknown packet type 1 at 69 ! [ 916.508905] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! The user space driver notices the error and writes a message to stderr. The test that triggered the invalid command subsequently fails. The failing line in the tests is http://source.winehq.org/git/wine.git/blob/f75d1b0c2f77d8c85f7c2a9bcc3545f14e271a86:/dlls/d3d8/tests/visual.c#l3704 . The test performs a copy from a multisampled color buffer to system memory. Wined3d first resolves the multisampled renderbuffer to a non-multisampled texture and calls glGetTexImage. Interestingly it is the glGetTexImage step that fails. The texture has format GL_BGRA, type GL_UNSIGNED_INT_8_8_8_8_REV and internal format GL_SRGB8_ALPHA8. We call glGetTexImage in plenty of places in this configuration, and this is the only case where this fails. I'll try to pin this down a bit further. The bug can be reproduced by running make visual.ok in dlls/d3d8/tests in a Wine build tree. System information: Wine commit ID: f75d1b0c2f77d8c85f7c2a9bcc3545f14e271a86 Mesa commit ID: e333035c47a6a4cc88f0f9ca2bced500538bebae Kernel: 3.19 libdrm: 2.4.59 X server: 1.16.3 Distribution: Gentoo
Note that the texture is never used as a source or destination= in a regular draw. It is specified with glTexImage2D, but the data pointer is NULL, and glTexSubImage2D is never used. It is only filled with data through the FBO_= blit call that resolves the multisampled renderbuffer. As far as I can see no PB= O is used.
Type 1 packets shouldn't be emitted at all and none of the user mode drivers emit them. I suspect either the command stream is getting corrupted somewhere or there is a prior packet count getting set wrong.
My semi-educated guess would be that the multisample resolve b= lit sets the size wrong. That would explain why out of the many glGetTexImage calls we're doi= ng this is the only one that fails. Time to write a stand-alone test case I guess.
Created attachment 113562 =
[details]
Test program
This program reproduces the result. As a 32 bit binary it generates the same
type 1 command that is rejected. As a 64 bit program it crashes with the
following backtrace:
(gdb) bt
#0 0x00007ffff75c8c90 in ?? () from /lib64/libc.so.6
#1 0x00007ffff2e0bcd3 in memcpy (__len=3D32, __src=3D<optimized out>,
__dest=3D<optimized out>) at /usr/include/bits/string3.h:51
#2 r300_emit_blend_state (r300=3D<optimized out>, size=3D8, state=3D=
<optimized out>)
at r300_emit.c:57
#3 0x00007ffff2e0f150 in r300_emit_dirty_state (r300=3Dr300@entry=3D0x=
649950) at
r300_emit.c:1450
#4 0x00007ffff2e12018 in r300_emit_states (instance_id=3D-1, index_bias=3D=
0,
buffer_offset=3D0, index_buffer=3D0x0, flags=3D<optimized out>, r300=
=3D0x649950) at
r300_render.c:259
#5 r300_prepare_for_rendering (r300=3Dr300@entry=3D0x649950, flags=3D&=
lt;optimized
out>, flags@entry=3DPREP_EMIT_STATES, index_buffer=3Dindex_buffer=
4;entry=3D0x0,
cs_dwords=3Dcs_dwords@entry=3D21, buffer_offset=3Dbuffer_offset@ent=
ry=3D0,
index_bias=3Dindex_bias@entry=3D0,=20
instance_id=3Dinstance_id@entry=3D-1) at r300_render.c:311
#6 0x00007ffff2e13258 in r300_blitter_draw_rectangle (blitter=3D<optimi=
zed out>,
x1=3D0, y1=3D0, x2=3D256, y2=3D256, depth=3D0, type=3DUTIL_BLITTER_ATTRIB_N=
ONE, attrib=3D0x0)
at r300_render.c:1141
#7 0x00007ffff2d7d3df in util_blitter_custom_color (blitter=3D0x61c7f0,
dstsurf=3Ddstsurf@entry=3D0x79e030, custom_blend=3Dcustom_blend@ent=
ry=3D0x0) at
util/u_blitter.c:2146
#8 0x00007ffff2e06b91 in r300_simple_msaa_resolve (pipe=3Dpipe@entry=
=3D0x649950,
dst=3Ddst@entry=3D0x79dcd0, dst_level=3Ddst_level@entry=3D0,
dst_layer=3Ddst_layer@entry=3D0, src=3D<optimized out>,
format=3DPIPE_FORMAT_B8G8R8A8_SRGB) at r300_blit.c:737
#9 0x00007ffff2e08396 in r300_msaa_resolve (info=3D0x7ffffffbdc70,
pipe=3D0x649950) at r300_blit.c:783
#10 r300_blit (pipe=3D0x649950, blit=3D<optimized out>) at r300_blit.=
c:809
#11 0x00007ffff2c2ad97 in st_BlitFramebuffer (ctx=3D<optimized out>,
readFB=3D0x796f30, drawFB=3D0x79d6b0, srcX0=3D<optimized out>, srcY0=
=3D<optimized out>,
srcX1=3D<optimized out>, srcY1=3D256, dstX0=3D0, dstY0=3D0, dstX1=3D2=
56, dstY1=3D256,
mask=3D16384, filter=3D9728)
at state_tracker/st_cb_blit.c:263
#12 0x00007ffff2af2ff2 in _mesa_BlitFramebuffer (srcX0=3D<optimized out&=
gt;,
srcY0=3D0, srcX1=3D<optimized out>, srcY1=3D256, dstX0=3D<optimize=
d out>,
dstY0=3D<optimized out>, dstX1=3D256, dstY1=3D256, mask=3D16384, filt=
er=3D9728) at
main/blit.c:509
#13 0x000000000040132f in init ()
#14 0x000000000040148a in main ()
Further testing shows that the GL_SRGB8_ALPHA8 internal format of the
destination texture is the problem. Replacing this with GL_RGBA8 makes the =
test
work fine. Note that when GL_EXT_sRGB_decode is available Wine always creat=
es
sRGB textures and sets GL_TEXTURE_SRGB_DECODE_EXT to GL_SKIP_DECODE_EXT to =
get
d3d-style sRGB read correction toggling.
Created attachment 113620 [details] [review] add some debugging output Can you apply this kernel patch and attach your kernel log output when you hit the error?
Created attachment 113719 [det= ails] [review] workaround Can you test this patch? Note that GL_ARB_framebuffer_sRGB is unsupported.<= /pre>
I'll try it in the next two days. If the workaround doesn't wo= rk I'll try to get the log Alex asked for.
I'm pretty sure the CS parser errors were caused by random gar= bage emitted by r300g. The driver doesn't expect an sRGB format in the framebuffer, which o= nly seems to happen with glBlitFramebuffer.
No more segfaults, but it still has a rejected CS: [129870.605179] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 8387584 have 524288) ! [129870.605186] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (163= 82 2 0 256) [129870.605189] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
| What | Removed | Added |
|---|---|---|
| Attachment #113719 is obsolete | 1 |
Created attachment 113802 [details] [review]
fix
This patch should fix it.
Attachment 113802 [details] fix=
es the invalid CS / crash and my test program now reads a
color. However, sRGB color correction seems to be applied at some stage. No=
te
that the test program is not using GL_ARB_framebuffer_sRGB (which isn't
supported on r500 anyway), and that GL_TEXTURE_SRGB_DECODE_EXT is set to
GL_SKIP_DECODE_EXT.
It seems that the correction is applied during blitting. If I clear the 2D
texture directly the expected result (0x0000ff80) is returned. If I use the
renderbuffer and blit I get 0x0000ff37.
(Wine expects that glBlitFramebuffer never applies sRGB correction when
blitting from an sRGB texture, but this codepath is only used if
GL_EXT_sRGB_decode is not supported. In this case we load two copies of the
texture, one sRGB and one RGB, and use glBlitFramebuffer to blit between th=
em
if the application toggles sRGB on and off.)
r300g doesn't do sRGB conversion for MSAA resolves. It always = interprets the textures as linear and only averages the samples.
The thing that seems to trigger the sRGB correction is the fac= t that the destination texture has an sRGB internal. If I change it to GL_RGBA8 I get = the expected result. The format of the source RB doesn't seem to matter here.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
Fixed by 9953586af2254f83a610d4cd284f52f37fa18b98 and c939231e7223510408a446400ad23b8b5ce2922e. My test program returns the corre= ct color and the Wine test passes. Thanks!