Re: [PATCH 2/8] wined3d: Unbind textures in context_bind_shader_resources().
On 9 March 2017 at 10:03, Józef Kucia <jkucia(a)codeweavers.com> wrote:
Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> ---
The WINED3D_LEGACY_TEXTURE_BINDING flag should prevent from generating the "No resource view bound at index" warnings in D3D9-, allows to safely unbind resources in context_bind_shader_resources(), and make it easier easier to add support for more samplers in D3D10+.
The issue is texture bindings set through wined3d_device_set_texture(), right? Could we get rid of wined3d_device_set_texture() and create shader resource views for those textures instead, similar to how we create rendertarget views in d3d9, etc.? IIRC one of the issues was interactions with sampler and texture stage states. Tangentially, how does this work with "Aon9" shaders?
On Thu, Mar 9, 2017 at 11:20 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
The issue is texture bindings set through wined3d_device_set_texture(), right?
Yes, we have currently two mutually exclusive ways to bind textures in wined3d, and without adding the flag we would overwrite texture bindings set through wined3d_device_set_texture().
Could we get rid of wined3d_device_set_texture() and create shader resource views for those textures instead, similar to how we create rendertarget views in d3d9, etc.? IIRC one of the issues was interactions with sampler and texture stage states.
I haven't looked closely into this, but I think it should be possible. Certainly it would require a lot of more work than this patch series. Texture stage states would probably have to be reworked to some extent.
Tangentially, how does this work with "Aon9" shaders?
"Aon9" shaders don't work in wined3d. For example, constant buffers aren't handled correctly (we have a todo_wine for this). I don't expect texture bindings to work properly in the current git or after this change. I think that "Aon9" shaders are rather a low priority thing. Generally, apps don't seem to ship shaders compiled with feature level 9 support.
On 9 March 2017 at 11:51, Józef Kucia <joseph.kucia(a)gmail.com> wrote:
On Thu, Mar 9, 2017 at 11:20 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
Tangentially, how does this work with "Aon9" shaders?
"Aon9" shaders don't work in wined3d. For example, constant buffers aren't handled correctly (we have a todo_wine for this). I don't expect texture bindings to work properly in the current git or after this change. I think that "Aon9" shaders are rather a low priority thing. Generally, apps don't seem to ship shaders compiled with feature level 9 support. Yeah, I didn't mean in wined3d as such, but I'd expect those to just use the corresponding shader resource view and sampler when referencing a SM3 sampler, right?
On Thu, Mar 9, 2017 at 11:55 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 9 March 2017 at 11:51, Józef Kucia <joseph.kucia(a)gmail.com> wrote:
On Thu, Mar 9, 2017 at 11:20 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
Tangentially, how does this work with "Aon9" shaders?
"Aon9" shaders don't work in wined3d. For example, constant buffers aren't handled correctly (we have a todo_wine for this). I don't expect texture bindings to work properly in the current git or after this change. I think that "Aon9" shaders are rather a low priority thing. Generally, apps don't seem to ship shaders compiled with feature level 9 support. Yeah, I didn't mean in wined3d as such, but I'd expect those to just use the corresponding shader resource view and sampler when referencing a SM3 sampler, right?
Right, there are certainly some additional restrictions, but feature level 9 shaders use the corresponding SRVs and samplers.
participants (2)
-
Henri Verbeet -
Józef Kucia