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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jul 26 20:10:38 UTC 2017


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

--- Comment #13 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Topi Pohjolainen from comment #12)
> (In reply to Topi Pohjolainen from comment #11)
> > (In reply to Jason Ekstrand from comment #10)
> > > (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.
> > 
> > You are correct, it does change the format. But the tiling vs align remains.
> > Old uses Y-tiling with valign 2 and new uses X-tiling with valign 2. Latter
> > should be correct while the former shouldn't.
> > 
> 
> Can we actually use valign2 with R32_UINT in general?

We probably have to whack VALIGN as part of adjusting to single-slice.  It also
shouldn't matter at that point since there are no mip-levels or array slices to
align.  Though I could see the hardware just being picky.

-- 
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/d35d23c3/attachment.html>


More information about the intel-3d-bugs mailing list