On 6 June 2016 at 11:39, Józef Kucia jkucia@codeweavers.com 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.