On 07/13/2017 06:57 PM, Jason Ekstrand wrote: > On Thu, Jul 13, 2017 at 6:38 PM, Ian Romanick <i...@freedesktop.org > <mailto:i...@freedesktop.org>> wrote: > > Shouldn't this also update capability_to_string in spriv_info.c? > > > Yes, probably. > > > I'm > also questioning that implementation... there are huge blocks in that > array (e.g., all the elements from 61 to 4322) that are zeroed out by > the initialization. > > > Ugh... I didn't realize we were packing it into an array. :( We really > need to use a switch since it's sparse. > > I think the correct answer here is a bit of python codegen. There is a > json file that provides all of these SPIR-V enums so it should be fairly > easy to do.
I was thinking the same thing. I'm on it. > This will cause spirv_capability_to_string() to > happily return NULL pointers that none of the callers are prepared to > handle. > > > I think you'll find that the SPIR-V parser does all sorts of "bad" > things if you touch it wrong. It was, after all, written for the Vulkan > world where crashing is a valid response to *any* invalid input. We > probably want to make it a bit more robust for GL. I've got something > of a plan for doing so but haven't had the time to sit down and hack on it. > > --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev