[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