Re: [PATCH 06/10] d3d9: use wined3d_rendertarget_view_create instead of wined3d_rendertarget_view_create_from_surface in d3d9_surface_get_rendertarget_view
On 19 October 2015 at 19:07, Riccardo Bortolato rikyz619@gmail.com wrote:
- desc.format_id = resource_desc.format;
- desc.u.texture.level_idx = surface->sub_resource_idx;
- desc.u.texture.layer_idx = 0;
This is wrong for cube texture surfaces.
Is this different from d3d8?
Ciao, Riccardo
2015-10-20 16:37 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 19 October 2015 at 19:07, Riccardo Bortolato rikyz619@gmail.com wrote:
- desc.format_id = resource_desc.format;
- desc.u.texture.level_idx = surface->sub_resource_idx;
- desc.u.texture.layer_idx = 0;
This is wrong for cube texture surfaces.
On 20 October 2015 at 16:42, Riccardo Bortolato rikyz619@gmail.com wrote:
Is this different from d3d8?
No, it's wrong there too, I just missed it. It happens to work in practice because wined3d_rendertarget_view_init() only uses the value to calculate the sub-resource index, but it would break as soon as we tried to create ARB_texture_view views for wined3d rendertarget views.
But d3d9_surface->sub_resource_idx is layer * container->level_count + level so view->sub_resource_idx would still be ok, maybe view->depth would be broken instead? But then it would be a problem of layer_count, not layer_idx.
I know I'm somehow abusing wined3d_rendertarget_view_init() and the desc structure but in practice it feels better than storing and passing around an otherwise useless parameter (level idx)
Relevant snippet from wined3d/view.c: struct wined3d_texture *texture = wined3d_texture_from_resource(resource); struct wined3d_resource *sub_resource;
view->sub_resource_idx = desc->u.texture.layer_idx * texture->level_count + desc->u.texture.level_idx; sub_resource = wined3d_texture_get_sub_resource(texture, view->sub_resource_idx);
view->buffer_offset = 0; view->width = sub_resource->width; view->height = sub_resource->height; view->depth = desc->u.texture.layer_count;
Ciao, Riccardo
2015-10-20 17:36 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 20 October 2015 at 16:42, Riccardo Bortolato rikyz619@gmail.com wrote:
Is this different from d3d8?
No, it's wrong there too, I just missed it. It happens to work in practice because wined3d_rendertarget_view_init() only uses the value to calculate the sub-resource index, but it would break as soon as we tried to create ARB_texture_view views for wined3d rendertarget views.
On 20 October 2015 at 18:05, Riccardo Bortolato rikyz619@gmail.com wrote:
But d3d9_surface->sub_resource_idx is layer * container->level_count + level so view->sub_resource_idx would still be ok,
That's what I said. :)
But at some point we'll need to create actual OpenGL texture views, and then we'll need to correct level and layer indices instead of just the sub-resource index. (See also https://www.opengl.org/registry/specs/ARB/texture_view.txt for reference.)
Well if instead of
+ resource = wined3d_texture_get_resource(surface->wined3d_texture);
I call wined3d_texture_get_sub_resource() then once control goes back to wined3d we can know texture_level and texture_layer for that particular surface (casting the surface from the subresource e.g. in wined3d_rendertarget_view_init()).
The sub_resource_idx "hack" would still be in place (maybe we can mitigate it with some inline comment) but the potential issue you pointed out could be easily solved then?
Ciao, Riccardo
2015-10-20 19:26 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 20 October 2015 at 18:05, Riccardo Bortolato rikyz619@gmail.com wrote:
But d3d9_surface->sub_resource_idx is layer * container->level_count + level so view->sub_resource_idx would still be ok,
That's what I said. :)
But at some point we'll need to create actual OpenGL texture views, and then we'll need to correct level and layer indices instead of just the sub-resource index. (See also https://www.opengl.org/registry/specs/ARB/texture_view.txt for reference.)
On 20 October 2015 at 21:13, Riccardo Bortolato rikyz619@gmail.com wrote:
Well if instead of
- resource = wined3d_texture_get_resource(surface->wined3d_texture);
I call wined3d_texture_get_sub_resource() then once control goes back to wined3d we can know texture_level and texture_layer for that particular surface (casting the surface from the subresource e.g. in wined3d_rendertarget_view_init()).
That would work in principle, but I don't think it's what we want.
What is your preferred solution then?
Ciao, Riccardo
2015-10-21 15:11 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 20 October 2015 at 21:13, Riccardo Bortolato rikyz619@gmail.com wrote:
Well if instead of
- resource = wined3d_texture_get_resource(surface->wined3d_texture);
I call wined3d_texture_get_sub_resource() then once control goes back to wined3d we can know texture_level and texture_layer for that particular surface (casting the surface from the subresource e.g. in wined3d_rendertarget_view_init()).
That would work in principle, but I don't think it's what we want.
On 21 October 2015 at 17:04, Riccardo Bortolato rikyz619@gmail.com wrote:
What is your preferred solution then?
I'm not sure I have a preferred solution yet, but the easy option would be to turn wined3d_rendertarget_view_create_from_surface() into wined3d_rendertarget_view_create_from_sub_resource(). (As opposed to hacking wined3d_rendertarget_view_create().)
-
Henri Verbeet -
Riccardo Bortolato