Re: [PATCH 2/5] wined3d: Pass a context to read_from_framebuffer.
2015-10-12 22:34 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>:
Sometimes the context won't be reusable because we need a specific context to access the WGL drawable. Afterwards we need to switch back to the caller's context. Bug 34574 is related to this. This is only relevant for backbuffer offscreen rendering, and in practise it is rare. It'll only matter if the application is blitting from an onscreen surface to a currently active offscreen one. For everything else the offscreen surface is copied into the texture when it is deactivated.
Note that in most cases the wined3d_context * structure is the same for both surfaces involved in the blit, but context->render_offscreen differs for source and destination. That's why context_restore needs a surface and not the old context.
I'm open to placing the extra context_acquire / context_release calls into the callers. We need them in 4 places: read_from_framebuffer, surface_blt_to_drawable, surface_blt_fbo and surface_load_fb_texture.
Yes, IMHO that would be better, although I haven't actually tried that so it might turn out to be bad in practice. Obviously ignore this suggestion altogether if Henri thinks otherwise :P
Henri once upon a time didn't like this (I haven't looked for my previous patch attempt from 2 years ago) and suggested a context_restore call instead. This is what I did here. I guess it would be nicer if context_restore accepted two contexts, but we're intentionally not using a separate GL context nor struct wined3d_context for backbuffer offscreen rendering. Neither the GL context switch nor keeping track of all d3d states is necessary for backbuffer ORM to do its job. 2015-10-13 12:29 GMT+02:00 Matteo Bruni <matteo.mystral(a)gmail.com>:
2015-10-12 22:34 GMT+02:00 Stefan Dösinger <stefan(a)codeweavers.com>:
Sometimes the context won't be reusable because we need a specific context to access the WGL drawable. Afterwards we need to switch back to the caller's context. Bug 34574 is related to this. This is only relevant for backbuffer offscreen rendering, and in practise it is rare. It'll only matter if the application is blitting from an onscreen surface to a currently active offscreen one. For everything else the offscreen surface is copied into the texture when it is deactivated.
Note that in most cases the wined3d_context * structure is the same for both surfaces involved in the blit, but context->render_offscreen differs for source and destination. That's why context_restore needs a surface and not the old context.
I'm open to placing the extra context_acquire / context_release calls into the callers. We need them in 4 places: read_from_framebuffer, surface_blt_to_drawable, surface_blt_fbo and surface_load_fb_texture.
Yes, IMHO that would be better, although I haven't actually tried that so it might turn out to be bad in practice. Obviously ignore this suggestion altogether if Henri thinks otherwise :P
2015-10-13 12:53 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>:
Henri once upon a time didn't like this (I haven't looked for my previous patch attempt from 2 years ago) and suggested a context_restore call instead. This is what I did here.
I guess it would be nicer if context_restore accepted two contexts, but we're intentionally not using a separate GL context nor struct wined3d_context for backbuffer offscreen rendering. Neither the GL context switch nor keeping track of all d3d states is necessary for backbuffer ORM to do its job.
True that. The handling of context->render_offscreen and related states is a mess (not to mention the bugs it has caused over time) :/ I guess my reservations have mostly to do with acquiring and immediately releasing the context to restore the previous state, although it looks like avoiding that dance would practically require reimplementing context_acquire() inside context_restore() so meh...
participants (2)
-
Matteo Bruni -
Stefan Dösinger