[Bug 101910] [BYT] ES31-CTS.functional.copy_image.non_compressed.viewclass_96_bits.rgb32f_rgb32f

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Topi Pohjolainen from comment #9)
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20170726/90c09134/attachment.html>