[PATCH 4/5] wined3d: Introduce shader_run_compute operation for the spirv backend.

Jan Sikorski jsikorski at codeweavers.com
Wed Aug 11 04:50:33 CDT 2021


> On 10 Aug 2021, at 20:50, Henri Verbeet <hverbeet at gmail.com> wrote:
> 
> On Tue, 10 Aug 2021 at 10:35, Jan Sikorski <jsikorski at codeweavers.com> wrote:
>> ---
>> dlls/wined3d/shader_spirv.c    | 112 +++++++++++++++++++++++++++++++++
>> dlls/wined3d/wined3d_private.h |   2 +
>> 2 files changed, 114 insertions(+)
>> 
> And this too is never used anywhere until patch 5/5 in this series.

Yes, do I squash it all together then?

>> +    .shader_run_compute = wined3d_spirv_run_compute,
>> };
>> 
> "shader_run_compute" remains uninitialised for the other shader backends.

It should be initialised to NULL, which seemed appropriate, but if we don’t want this I’ll make it spit an ERR.

> Conceptually, it doesn't seem quite proper for the shader backends to
> do compute dispatch by themselves; ideally these would only translate
> shaders, although in practice they're also responsible for setting up
> some related state, for OpenGL in particular.
> 
> I'm not sure whether you perhaps already considered and rejected this,
> but would it be very hard to use the existing .shader_select_compute()
> operation from wined3d_unordered_access_view_vk_clear()? Or perhaps
> simply adapter_vk_dispatch_compute()?

My understanding is that I can’t touch wined3d_state, so in order to unite with existing functionality I’d have to decouple it from the state. Maybe we want this anyway? It looks straightforward to do for shader_select_compute. adapter_vk_dispatch_compute() mostly applies state so I don’t see how it could be of use here.

- Jan


More information about the wine-devel mailing list