ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver ||
pac85 has joined #zink
<pac85> So regarding the problem I had yesterday with trasnform feedback and geometry shaders. Stream out is normally generated by the state tracker but not when no gs is used. Now since I'm generating the geometry shader myself I should fill that struct myself right?
<zmike> yeh just copy it from the previous stage
<pac85> I tried that but the vertex shader doesn't seem to have any output streams.
<zmike> you mean the pipe_stream_output_info is zeroed?
<pac85> Not all zeroed but the num_outputs field is 0
<zmike> do you have an example test?
<pac85> I'm using piglit's ./bin/ext_transform_feedback-separate
<zmike> if I break in zink_shader_create I see the first shader has outputs
<zmike> (gdb) p *so_info
<zmike> $1 = {num_outputs = 4, stride = {3, 4, 2, 4}, output = {{register_index = 5, start_component = 0, num_components = 3, output_buffer = 0, dst_offset = 0, stream = 0}, {register_index = 1, start_component = 0, num_components = 4, output_buffer = 1, dst_offset = 0, stream = 0}, {register_index = 4, start_component = 0, num_components = 2, output_buffer = 2, dst_offset = 0, stream = 0}, {register_index = 3, start_component = 0,
<zmike> num_components
<zmike> = 4, output_buffer = 3, dst_offset = 0, stream = 0}, {register_index = 0, start_component = 0, num_components = 0, output_buffer = 0, dst_offset = 0, stream = 0} <repeats 60 times>}}
<pac85> Uhm, I was reading it like this ctx->gfx_stages[prev_vertex_stage]->sinfo.so_info.num_outputs . Seems like it doesn't get copied there?
<pac85> breaking there I get the same output as you
<zmike> ahh I see
<zmike> yea so those outputs are only the ones that are explicit
<zmike> you need to check sinfo->have_xfb
<zmike> probably all the xfb outputs in this shader are being inlined
<pac85> Oh I see what is happening. Thank you!
<pac85> Do you think it would be acceptable to have a new field in zink_shader_info to hold the original value of so_info so that I can use it in the generated gs? Something like original_so_info. I managed to make it pass the tests this way
<zmike> I'm not sure why you'd need it?
<pac85> How else can I know about the so_info thay gallium generated during the creation of the emulation gs?
<zmike> you shouldn't need it
<zmike> the variables that are being passed through from the previous vertex stage should have xfb info preserved
<pac85> I see, but strangely enough it doesn't work. I'll investigate it more
<zmike> probably getting zeroed during zink_shader_create()
<zmike> ideally you'd want to preserve all of that and not run update_so_info again
<pac85> so_info is filled by update_so_info, the one passed by gallium is not stored anywhere
<zmike> right
<zmike> you shouldn't need it
<zmike> it's a passthrough, so you should just copy the sinfo from the previous stage
<zmike> and not do any further work
<pac85> Maybe update_so_info does something different when acting on a geometry shader?
<zmike> it shouldn't unless you're using multiple streams
<zmike> nir_foreach_shader_out_variable(var, nir)
<zmike> var->data.explicit_xfb_buffer = 0;
<zmike> this is probably what's breaking your gs passthrough
<pac85> You are right
<pac85> so I need to not zero those out for the passthorugh shader
sinanmoh- has quit [Read error: Connection reset by peer]
sinanmohd has joined #zink
<pac85> I was able to pass the tests with the changes you suggested and I've updated the MR. Thanks once again
pac85 has quit [Quit: Konversation terminated!]
pac85 has joined #zink
<zmike> 👍
pac85 has quit [Quit: Konversation terminated!]
sinanmohd has quit [Ping timeout: 480 seconds]
<anholt_> zmike: why does zink use a copy to get query results?
<zmike> anholt_: for consistency with cases where results should persist beyond pool resets
<zmike> the results are always copied to a buffer for readback
<anholt_> do you reset pools regularly? Seems like you could just save off old pool contents when you have to reset
<anholt_> well, queries are not the problem here. I can disable the copy entirely and it doesn't move the needle.
<zmike> pools are reset very regularly, yes
<zmike> and yeah I spent a while looking at queries and they don't seem to affect anything here
<zmike> will be gone a few hours bbl
anholt_ has quit [Quit: Leaving]
anholt has joined #zink