18 May
2022
18 May
'22
8:22 p.m.
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.