On Sat, Oct 21, 2017 at 10:22:09AM +0200, Christian Gmeiner wrote: > Hi Wladimir > > 2017-10-21 7:28 GMT+02:00 Wladimir J. van der Laan <laa...@gmail.com>: > > On Fri, Oct 20, 2017 at 10:21:28PM +0200, Christian Gmeiner wrote: > >> Fixes piglit/bin/oes_texture_float half > >> > >> Signed-off-by: Christian Gmeiner <christian.gmei...@gmail.com> > >> --- > >> src/gallium/drivers/etnaviv/etnaviv_translate.h | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/src/gallium/drivers/etnaviv/etnaviv_translate.h > >> b/src/gallium/drivers/etnaviv/etnaviv_translate.h > >> index 0761251a36..c82a244e6d 100644 > >> --- a/src/gallium/drivers/etnaviv/etnaviv_translate.h > >> +++ b/src/gallium/drivers/etnaviv/etnaviv_translate.h > >> @@ -249,6 +249,8 @@ etna_compatible_rs_format(enum pipe_format fmt) > >> return PIPE_FORMAT_B4G4R4A4_UNORM; > >> case 4: > >> return PIPE_FORMAT_B8G8R8A8_UNORM; > >> + case 8: > >> + return PIPE_FORMAT_B8G8R8A8_UNORM; > > > > That's the same as 4. How does the RS know it has to copy 8 bytes per pixel? > > > > I tried all possible values for case 8 and there are a handful of them > which helped to pass > oes_texture_float half piglit. I am not really sure if RS @gc2000 even > supports 64bit clears/blits (as I never > have seen them in any cmd stream dumps). Lets see if I can find the > the format used by RS for 64bit clears/blits. > In the worst case we need to fall back to a slower blit method. Will > look into the this today.
OK thanks for the explanation. Unfortunately I'm not sure about that either. I don't really understand why this makes it pass the test, but it's interesting. Doesn't seem too easy to fall back on sw here, especially on gc2000 because of the split-tiled and supertiled formats. Regards, Wladimir _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
