Re: [PATCH 1/6] wined3d: Add wined3d_shader_resource_view_desc.

[Henri Verbeet]

On 6 June 2016 at 11:39, Józef Kucia  wrote:
> +enum wined3d_view_type
> +{
> - WINED3D_VTYPE_BUFFER                    = 1,
> - WINED3D_VTYPE_TEXTURE_1D                = 2,
> - WINED3D_VTYPE_TEXTURE_1D_ARRAY          = 3,
> - WINED3D_VTYPE_TEXTURE_2D                = 4,
> - WINED3D_VTYPE_TEXTURE_2D_ARRAY          = 5,
> - WINED3D_VTYPE_TEXTURE_3D                = 6,
> - WINED3D_VTYPE_TEXTURE_CUBE              = 7,
> - WINED3D_VTYPE_TEXTURE_CUBE_ARRAY        = 8,
>
> +};
> -

Not a fan of the "VTYPE" in the enum elements. It does match "RTYPE"
from enum wined3d_resource_type, but that is itself a leftover from
when it more closely matched D3DRESOURCETYPE.
> +struct wined3d_shader_resource_view_desc
> +{
> - enum wined3d_format_id format_id;
> - enum wined3d_view_type view_type;
> - union
> - {
> -
>    struct
> -
>    {
> -
>        unsigned int start_idx;
> -
>        unsigned int count;
> -
>        unsigned int flags;
> -
>    } buffer;
> -
>    struct
> -
>    {
> -
>        unsigned int level_idx;
> -
>        unsigned int level_count;
> -
>        unsigned int layer_idx;
> -
>        unsigned int layer_count;
> -
>    } texture;
> - } u;
>
> +};

Is the "view_type" field needed? I seem to remember that the view type
needs to match the resource type, so you shouldn't be able to e.g.
create a texture view on a buffer resource. The main other reasons I
can imagine for having the field are cube views, and perhaps shaders
making a distinction between array textures with a single layer and
non-array textures. The latter could easily be handled by setting
"layer_count" to ~0u for non-array textures, but since we have a
"flags" field with plenty of extra bits, I think we could just use
that to mark both cube and array views.

[PATCH 1/6] wined3d: Add wined3d_shader_resource_view_desc.

[Józef Kucia]

On Mon, Jun 6, 2016 at 2:59 PM, Henri Verbeet  wrote:
> Is the "view_type" field needed? I seem to remember that the view type
> needs to match the resource type, so you shouldn't be able to e.g.
> create a texture view on a buffer resource. The main other reasons I
> can imagine for having the field are cube views, and perhaps shaders
> making a distinction between array textures with a single layer and
> non-array textures. The latter could easily be handled by setting
> "layer_count" to ~0u for non-array textures, but since we have a
> "flags" field with plenty of extra bits, I think we could just use
> that to mark both cube and array views.

Yes, this information can be encoded in the "flags" field. The main
reasons for the "view_type" field are cube views and cube array views.