12:42 <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?

12:44 <zmike> yeh just copy it from the previous stage

12:51 <pac85> I tried that but the vertex shader doesn't seem to have any output streams.

13:00 <zmike> you mean the pipe_stream_output_info is zeroed?

13:10 <pac85> Not all zeroed but the num_outputs field is 0

13:12 <zmike> do you have an example test?

13:28 <pac85> I'm using piglit's ./bin/ext_transform_feedback-separate

13:30 <zmike> if I break in zink_shader_create I see the first shader has outputs

13:30 <zmike> (gdb) p *so_info

13:30 <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,

13:30 <zmike> num_components

13:30 <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>}}

13:37 <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?

13:37 <pac85> breaking there I get the same output as you

13:38 <zmike> ahh I see

13:38 <zmike> yea so those outputs are only the ones that are explicit

13:39 <zmike> you need to check sinfo->have_xfb

13:39 <zmike> probably all the xfb outputs in this shader are being inlined

13:50 <pac85> Oh I see what is happening. Thank you!

15:10 <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

15:11 <zmike> I'm not sure why you'd need it?

15:12 <pac85> How else can I know about the so_info thay gallium generated during the creation of the emulation gs?

15:12 <zmike> you shouldn't need it

15:13 <zmike> the variables that are being passed through from the previous vertex stage should have xfb info preserved

15:14 <pac85> I see, but strangely enough it doesn't work. I'll investigate it more

15:15 <zmike> probably getting zeroed during zink_shader_create()

15:16 <zmike> ideally you'd want to preserve all of that and not run update_so_info again

15:18 <pac85> so_info is filled by update_so_info, the one passed by gallium is not stored anywhere

15:19 <zmike> right

15:19 <zmike> you shouldn't need it

15:19 <zmike> it's a passthrough, so you should just copy the sinfo from the previous stage

15:19 <zmike> and not do any further work

15:21 <pac85> Maybe update_so_info does something different when acting on a geometry shader?

15:21 <zmike> it shouldn't unless you're using multiple streams

15:21 <zmike> nir_foreach_shader_out_variable(var, nir)

15:21 <zmike> var->data.explicit_xfb_buffer = 0;

15:22 <zmike> this is probably what's breaking your gs passthrough

15:26 <pac85> You are right

15:27 <pac85> so I need to not zero those out for the passthorugh shader

16:00 <pac85> I was able to pass the tests with the changes you suggested and I've updated the MR. Thanks once again

16:18 <zmike> 👍

19:36 <anholt_> zmike: why does zink use a copy to get query results?

19:54 <zmike> anholt_: for consistency with cases where results should persist beyond pool resets

19:55 <zmike> the results are always copied to a buffer for readback

19:55 <anholt_> do you reset pools regularly? Seems like you could just save off old pool contents when you have to reset

19:57 <anholt_> well, queries are not the problem here. I can disable the copy entirely and it doesn't move the needle.

19:59 <zmike> pools are reset very regularly, yes

20:00 <zmike> and yeah I spent a while looking at queries and they don't seem to affect anything here

20:00 <zmike> will be gone a few hours bbl