<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f" href="https://bugs.freedesktop.org/show_bug.cgi?id=101910#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f" href="https://bugs.freedesktop.org/show_bug.cgi?id=101910">bug 101910</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to Topi Pohjolainen from <a href="show_bug.cgi?id=101910#c9">comment #9</a>) > While the failing tests themself don't create RGB32F surfaces to back > renderbuffers (in which case they would probably fail as i965 marks RGB32F > as non-renderable), the surfaces nonetheless end up as render targets. As > the titles of all the failing tests say, tests copy two images. Image copies > in turn are implemented in i965 using blorp (_mesa_CopyImageSubData() -> > brw_blorp_copy_miptrees()) which ends up using RGB32F as GPU render target. No, it doesn't. It should be using R32_UINT and manually offsetting to the slice to be copied. There may be bugs there though. > With respect to PRM, isl does the right thing and chooses X-tiling with > valign of 2. This for some reason, however, fails. Old miptree used contrary > to the spec Y-tiling with valign of 2 which for some reason works (at least > in these tests). > Also as mentioned a few comments earlier, for some reason at least > rgb32f_rgb32f.cubemap_to_cubemap works if one uses X-tiling and valign of 4 > (which also is against the spec). My gut suspects something in our code to calculate offsets though I'm not sure.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>