[PATCH v2 3/7] wined3d: Implement lighting with directional lights in process_vertices_strided().

[Matteo Bruni]

On Fri, May 17, 2019 at 8:09 PM Paul Gofman <gofmanp at gmail.com> wrote:
>
> On 5/17/19 20:01, Henri Verbeet wrote:
> > On Fri, 17 May 2019 at 20:47, Paul Gofman <gofmanp at gmail.com> wrote:
> >> Do you think it is ok then just to use it (providing the first context
> >> from device, as I don't have one in process_vertices()), initialize
> >> wined3d_ffp_vs_settings and use the fields from there to initialize the
> >> similar fieldsin the local structure (as I cannot replace it anyway due
> >> to the lights)? I can do that of course, my only concern is that it
> >> might end up adding nearly the same amount of code that it saves.
> > You can acquire a context by calling "context_acquire(device, NULL,
> > 0);", and release it again with "context_release();".
>
> I figured I can't acquire context if CSMT is on because the
> wined3d_process_vertices() is called not from CSMT thread. Does it mean
> we should make wined3d_device_process_vertices() go through CSMT first,
> or I rather make wined3d_ffp_get_vs_settings() work with NULL context
> (by skipping the fields which can't be estimated without)?

I'd try with the latter first. Moving process_vertices() over to the
CS thread seems awkward to me.

FWIW we should probably get rid of the struct gl_info uses in
wined3d_ffp_get_vs_settings(), maybe by setting a flag in d3d_info if
we have enough (backend / GL) varyings to support all the fixed
function (d3d) varyings. Actually, all the uses of
wined3d_max_compat_varyings() are like that, we could get rid of the
function entirely.
I can write the patch if you haven't already.

That aside, I think wined3d_ffp_get_vs_settings() shouldn't have a
context parameter but simply get stream_info and d3d_info from the
caller. You want to pass your own stream_info from
wined3d_device_process_vertices() anyway and you can get to d3d_info
from device->adapter.