On Tue, Aug 14, 2018 at 5:47 AM, Gurchetan Singh
<gurchetansi...@chromium.org> wrote:
This is virgl analogue to cf6dad.
Fixes:
dEQP-GLES31.functional.image_load_store.3d.atomic.*
Example test cases:
dEQP-GLES31.functional.image_load_store.3d.atomic.add_r32ui_return_value
dEQP-GLES31.functional.image_load_store.3d.atomic.min_r32ui_return_value
dEQP-GLES31.functional.image_load_store.3d.atomic.max_r32ui_return_value
dEQP-GLES31.functional.image_load_store.3d.atomic.and_r32ui_return_value
---
src/gallium/drivers/virgl/virgl_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/virgl/virgl_screen.c
b/src/gallium/drivers/virgl/virgl_screen.c
index 421fde5249..745a502189 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -36,7 +36,7 @@
#include "virgl_context.h"
#define SP_MAX_TEXTURE_2D_LEVELS 15 /* 16K x 16K */
-#define SP_MAX_TEXTURE_3D_LEVELS 9 /* 512 x 512 x 512 */
+#define SP_MAX_TEXTURE_3D_LEVELS 12 /* 2048 x 2048 x 2048 */
#define SP_MAX_TEXTURE_CUBE_LEVELS 13 /* 4K x 4K */
I don't think this is a good idea.
OpenGL ES 3.1 only requires 256^3 support, so this is going to fail
when running on such hardware. I'm working on patches that actually
pass what the host supports instead.
But, a puzzling details is that these tests don't use more than 512 in
either direction. They use max 320 (= 64 * 5). And mesa seems to think
256 is the actual max here. So something is going wrong between us
reportig this to mesa and
There's also a bug in the test, where it tests size that are out of
spec without checking the max-size, it seems. I have a patch for this
also.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
