On Thu, Jul 13, 2017 at 9:57 AM, Eric Anholt <e...@anholt.net> wrote:
> Jason Ekstrand <ja...@jlekstrand.net> writes: > > > I know what you're all thinking: Why are we adding yet another format > > enum? I asked myself the same question. Really, I've spent enough of my > > life writing format enum conversion tables that I should know better. > > > > It all started as an attempt to write patch 6 which prints the formats of > > images used in shaders in nir_print. Unfortunately, what I wanted to do > > was to use _mesa_enum_to_string to convert the GL enum (which is what we > > were using before) into a string to print. The problem is that this > > function exists in mesa/main and is therefore unavailable in nir_print(). > > So, instead of writing a remap table just for nir_print(), I decided to > > bite the bullet and add something to shader_enums. > > > > Really, I think this makes a fair amount of sense as the image formats in > > GLSL or SPIR-V really live in their own compiler enum space. The only > > reason why we re-used the GL enums before was for convenience. This > meant > > that spirv_to_nir had a big table to convert SPIR-V enums to GL enums > which > > is a bit awkward since it's for Vulkan. In any case, I don't think this > > actually makes the situation any worse. > > Could we just pull the Mesa formats and their names up to the top, > instead? > I knew someone would ask that question... Yes, that's what we really should do in the long run. One of these days, I'd like to have a single format enum to which all other enums get converted. Unfortunately, when that happens, I'll probably want to refactor MESA_FORMAT a bit to make it more compatible with Vulkan and that's going to be a lot of work.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
