On Fri, May 17, 2019 at 8:09 PM Paul Gofman gofmanp@gmail.com wrote:
On 5/17/19 20:01, Henri Verbeet wrote:
On Fri, 17 May 2019 at 20:47, Paul Gofman gofmanp@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.