[virglrenderer-devel] [PATCH virglrenderer] shader: fix Unigine Heaven 4.0 shader translation
Marc-André Lureau
marcandre.lureau at gmail.com
Wed Sep 7 18:51:52 UTC 2016
Hi
Interesting test, it requires a lot of RAM.
On my laptop, I get (with my wip qemu virgl-thread, using spice local
display):
- ~430 native
- ~250 with vtest
- ~250 with guest&qemu and 4G
- ~100 with guest&qemu and 2G
It seems to me if we could still optimize the CPU usage, and somehow do
double-buffering (keep rendering while displaying), we could get even
better results.
To run the test with vtest, I had to workaround an assert, that I don't
know how to fix properly:
diff --git a/src/gallium/drivers/virgl/virgl_context.c
b/src/gallium/drivers/virgl/virgl_context.c
index 9007583..4e9daa5 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -108,8 +108,9 @@ static void virgl_attach_res_sampler_views(struct
virgl_context *vctx,
unsigned i;
while (remaining_mask) {
i = u_bit_scan(&remaining_mask);
+ if (!tinfo->views[i])
+ continue;
assert(tinfo->views[i]);
I have random similar crash in the guest too (quite unpredictable):
Thread 1 "heaven_x64" received signal SIGSEGV, Segmentation fault.
0x00007f83893cc3de in virgl_attach_res_sampler_views
(vctx=vctx at entry=0x1c22c00,
shader_type=shader_type at entry=1) at virgl_context.c:113
113 res = virgl_resource(tinfo->views[i]->base.texture);
(gdb) bt
#0 0x00007f83893cc3de in virgl_attach_res_sampler_views
(vctx=vctx at entry=0x1c22c00,
shader_type=shader_type at entry=1) at virgl_context.c:113
#1 0x00007f83893cc703 in virgl_reemit_res (vctx=0x1c22c00) at
virgl_context.c:182
#2 virgl_flush_eq (ctx=ctx at entry=0x1c22c00, closure=0x1c22c00) at
virgl_context.c:637
#3 0x00007f83893ccbf8 in virgl_flush_from_st (ctx=0x1c22c00,
fence=<optimized out>, flags=<optimized out>) at virgl_context.c:659
#4 0x00007f83893cd6b0 in virgl_encoder_write_cmd_dword
(ctx=ctx at entry=0x1c22c00,
dword=dword at entry=67075) at virgl_encode.c:43
#5 0x00007f83893cd76b in virgl_encode_delete_object (ctx=0x1c22c00,
handle=1306480, object=object at entry=6) at virgl_encode.c:72
#6 0x00007f83893ccc81 in virgl_destroy_sampler_view (ctx=<optimized out>,
view=0x7aca1b0) at virgl_context.c:741
#7 0x00007f83893cca17 in pipe_sampler_view_reference (view=0x0,
ptr=0x1c22fc8) at ../../../../src/gallium/auxiliary/util/u_inlines.h:151
#8 virgl_set_sampler_views (ctx=0x1c22c00, shader_type=1,
start_slot=<optimized out>, num_views=<optimized out>, views=<optimized
out>) at virgl_context.c:724
#9 0x00007f8388fffd68 in cso_set_sampler_views (ctx=0x1ca2ee0,
shader_stage=<optimized out>, count=9, views=<optimized out>) at
cso_cache/cso_context.c:1301
#10 0x00007f8388e670c1 in update_textures (st=<optimized out>,
mesa_shader=<optimized out>, prog=<optimized out>, max_units=16,
sampler_views=0x1c8c140, num_textures=0x1c8c644) at
state_tracker/st_atom_texture.c:465
#11 0x00007f8388e6296d in st_validate_state (st=st at entry=0x1c8a710,
pipeline=pipeline at entry=ST_PIPELINE_RENDER) at state_tracker/st_atom.c:289
#12 0x00007f8388e8343b in st_draw_vbo (ctx=0x1c50600, prims=0x7ffe99b5a580,
nr_prims=1, ib=0x7ffe99b5a560, index_bounds_valid=<optimized out>,
min_index=<optimized out>, max_index=<optimized out>, tfb_vertcount=0x0,
stream=0,
indirect=0x0) at state_tracker/st_draw.c:176
#13 0x00007f8388e44d34 in vbo_validated_drawrangeelements
(ctx=ctx at entry=0x1c50600,
mode=mode at entry=4, index_bounds_valid=index_bounds_valid at entry=0 '\000',
start=start at entry=4294967295, end=end at entry=4294967295, count=count at entry=2688,
type=5123, indices=0x0, basevertex=0, numInstances=1, baseInstance=0)
at vbo/vbo_exec_array.c:849
#14 0x00007f8388e44db5 in vbo_exec_DrawElementsInstanced (mode=4,
count=2688, type=5123, indices=0x0, numInstances=1) at
vbo/vbo_exec_array.c:1030
On Wed, Sep 7, 2016 at 10:49 PM <marcandre.lureau at redhat.com> wrote:
> From: Marc-André Lureau <marcandre.lureau at redhat.com>
>
> The benchmark fails to start, the translation of gl_Identity is incorrect,
>
> UMAD TEMP[0], SV[0].xxxx, TEMP[0].xxxx, TEMP[1]
>
> is translated to:
>
> temp0[0] = vec4(uintBitsToFloat((gl_InstanceID *
> floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
>
> Which results in the following error:
> shader failed to compile
> 0:23(34): error: could not implicitly convert operands to arithmetic
> operator
> 0:23(34): error: operands to arithmetic operators must be numeric
> 0:23(17): error: no matching function for call to
> `uintBitsToFloat(error)'; candidates are:
>
> It seems we can use the same workaround as gl_VertexID, I didn't
> observe any regression running various gl_InstanceId tests from
> piglit:
>
> temp0[0] =
> vec4(uintBitsToFloat((floatBitsToUint(vec4(intBitsToFloat(gl_InstanceID)))
> * floatBitsToUint(temp0[0].xxxx) + floatBitsToUint(temp0[1]))));
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
> ---
> src/vrend_shader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/vrend_shader.c b/src/vrend_shader.c
> index 0350b12..a80c3f1 100644
> --- a/src/vrend_shader.c
> +++ b/src/vrend_shader.c
> @@ -1632,7 +1632,7 @@ iter_instruction(struct tgsi_iterate_context *iter,
> } else if (src->Register.File == TGSI_FILE_SYSTEM_VALUE) {
> for (j = 0; j < ctx->num_system_values; j++)
> if (ctx->system_values[j].first == src->Register.Index) {
> - if (ctx->system_values[j].name == TGSI_SEMANTIC_VERTEXID)
> + if (ctx->system_values[j].name == TGSI_SEMANTIC_VERTEXID
> || ctx->system_values[j].name == TGSI_SEMANTIC_INSTANCEID)
> snprintf(srcs[i], 255, "%s(vec4(intBitsToFloat(%s)))",
> stypeprefix, ctx->system_values[j].glsl_name);
> else
> snprintf(srcs[i], 255, "%s%s", prefix,
> ctx->system_values[j].glsl_name);
> --
> 2.10.0
>
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
--
Marc-André Lureau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20160907/59938437/attachment-0001.html>
More information about the virglrenderer-devel
mailing list