[PATCH v2 0/11] MR79: wined3d: Refactor format flags into two groups.

[Chip Davis (@cdavis5e)]

On Wed May 18 05:41:48 2022 +0000, **** wrote:
> Zebediah Figura replied on the mailing list:
> ```
> On 5/16/22 20:26, Chip Davis (@cdavis5e) wrote:
> > There are only three unused format flags left. I will soon submit changes
> > which add four more format flags.
> > 
> > I've noticed that format flags generally fall into two groups:
> > 
> > * The first group consists of flags describing the content of a pixel
> >    format, e.g. whether or not this is a depth format, or whether this is
> >    a blocked format. These flags are the same for all resource types.
> > * The second group consists of flags describing capabilities of the
> >    implementation with this format. These can and do vary by resource
> >    type.
> > 
> > Only the second group needs to be stored per-resource-type.
> > 
> Here are some thoughts, some of which are from Henri:
> * Personally, I think this makes sense on its own merits, as a means of 
> clarifying. It's weird to me that flags like FLOAT are stored per 
> resource type when conceptually they're independent of resource type.
> * On the other hand, it's not clear that it's worthwhile. It's a lot of 
> churn, when it'd be easy enough to free up space by extending to 64 
> bits, or even getting rid of some obsolete flags.
> * Patches 10 and 11 in particular are an awful lot of churn, and the 
> naming isn't clearly an improvement. Maybe instead of "base_flags" we 
> could say "attributes"?
> * If we're moving things around, I believe we also want to move 
> DECOMPRESS to the "base flags" group.
> * I don't think BUMPMAP belongs in the format_texture_info array, but 
> rather format_base_flags.
> * There's some flags left in "caps" that are logically capabilities, but 
> arguably don't need to be per resource type, e.g. UNORDERED_ACCESS, 
> VERTEX_ATTRIBUTE, RENDERTARGET, DEPTH_STENCIL, SHADOW, INDEX_BUFFER. 
> Maybe it's better to leave them where they are, though...
> * Maybe instead of flags we could use bitfields, which would give us a 
> bit more freedom in general and probably help naming. On the other hand 
> it makes it harder to copy the flags field around as a whole...
> ```
> * If we're moving things around, I believe we also want to move 
DECOMPRESS to the "base flags" group.

No we don't. AIUI that's for when the implementation doesn't support uploading the compressed data directly, which can and does vary by resource type--most infamously, OpenGL doesn't support compressed volume textures.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/79#note_987