<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 13, 2017 at 9:57 AM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> I know what you're all thinking:  Why are we adding yet another format<br>
> enum?  I asked myself the same question.  Really, I've spent enough of my<br>
> life writing format enum conversion tables that I should know better.<br>
><br>
> It all started as an attempt to write patch 6 which prints the formats of<br>
> images used in shaders in nir_print.  Unfortunately, what I wanted to do<br>
> was to use _mesa_enum_to_string to convert the GL enum (which is what we<br>
> were using before) into a string to print.  The problem is that this<br>
> function exists in mesa/main and is therefore unavailable in nir_print().<br>
> So, instead of writing a remap table just for nir_print(), I decided to<br>
> bite the bullet and add something to shader_enums.<br>
><br>
> Really, I think this makes a fair amount of sense as the image formats in<br>
> GLSL or SPIR-V really live in their own compiler enum space.  The only<br>
> reason why we re-used the GL enums before was for convenience.  This meant<br>
> that spirv_to_nir had a big table to convert SPIR-V enums to GL enums which<br>
> is a bit awkward since it's for Vulkan.  In any case, I don't think this<br>
> actually makes the situation any worse.<br>
<br>
</span>Could we just pull the Mesa formats and their names up to the top,<br>
instead?<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br></div></div>