Re: wined3d: Call wined3d_cs_emit_unload_resource outside of command stream.

[Henri Verbeet]

On 17 February 2017 at 03:47, Sebastian Lackner  wrote:
> Signed-off-by: Sebastian Lackner
>
> dlls/wined3d/device.c |   15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)

Why would you want to do that?

wined3d: Call wined3d_cs_emit_unload_resource outside of command stream.

[Sebastian Lackner]

On 17.02.2017 08:35, Henri Verbeet wrote:
> On 17 February 2017 at 03:47, Sebastian Lackner  wrote:
> > Signed-off-by: Sebastian Lackner
> >
> > dlls/wined3d/device.c |   15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
>
> Why would you want to do that?

Well, it depends a bit how you are planning to deal with
wined3d_cs_emit_*() calls on the command stream. Just appending at the
end of the stream wouldn't be a good idea here, because its executed
after all the contexts are already destroyed. Dispatching immediately
might work, but is a bit dangerous because there is currently only one
buffer, and you are replacing the content while the previous command
is still active. Feel free to ignore if you are planning to use a
different solution for this problem.

Best regards,
Sebastian

wined3d: Call wined3d_cs_emit_unload_resource outside of command stream.

[Henri Verbeet]

On 17 February 2017 at 08:49, Sebastian Lackner  wrote:
> Well, it depends a bit how you are planning to deal with
> wined3d_cs_emit_*() calls on the command stream. Just appending at the
> end of the stream wouldn't be a good idea here, because its executed
> after all the contexts are already destroyed. Dispatching immediately
> might work, but is a bit dangerous because there is currently only one
> buffer, and you are replacing the content while the previous command
> is still active. Feel free to ignore if you are planning to use a
> different solution for this problem.

The idea is to dispatch calls immediately, yeah. Strictly speaking the
patch that introduced wined3d_device_delete_opengl_contexts_cs()
depends on another patch that isn't currently upstream to properly
handle that case in wined3d_cs_st_require_space() and
wined3d_cs_st_submit(), but I only realised that after submitting the
patch. In practice it shouldn't matter in this specific case though,
since the CS packet's contents are consumed before the new packet is
emitted.