Bug 101560 - SPIR-V OpSwitch with int64 not supported even though shaderInt64 is true
Summary: SPIR-V OpSwitch with int64 not supported even though shaderInt64 is true
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/Common (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-23 00:22 UTC by programmerjake
Modified: 2017-12-12 06:43 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
SPIR-V vertex shader that uses OpSwitch on a uint64_t (may be incorrect) (916 bytes, application/octet-stream)
2017-06-23 00:22 UTC, programmerjake
Details

Description programmerjake 2017-06-23 00:22:25 UTC
Created attachment 132150 [details]
SPIR-V vertex shader that uses OpSwitch on a uint64_t (may be incorrect)

I noticed that even though shaderInt64 is true on gen 8 and above, the SPIR-V to NIR translator code doesn't support OpSwitch on 64-bit integers.

Supporting 64-bit integers in OpSwitch requires parsing 2 for each switch value, with the target block id, it requires 3 words for each switch case.

The latest commit on master when I checked is e558a7a9888ee56863f11e7ede387689626f6ea9.

see OpSwitch translation code: https://github.com/mesa3d/mesa/blob/master/src/compiler/spirv/vtn_cfg.c#L400

code that enables shaderInt64:
https://github.com/mesa3d/mesa/blob/master/src/intel/vulkan/anv_device.c#L720

Note: from what I can tell, glslang doesn't currently allow creating OpSwitch on a int64, so programs that use OpSwitch this way are probably non-existant.
Comment 1 programmerjake 2017-07-04 08:41:57 UTC
I'm switching this to be a bug in radv because commit 1bc40ae9524477de9d4f73b57b3ae69a40923695 enabled int64 support in radv even though the spir-v to nir translation code hasn't been fixed yet.
Comment 2 Jason Ekstrand 2017-07-05 22:41:43 UTC
Ugh... I guess I didn't read the language on OpSwitch all that carefully the first time around.  This is going to be exceedingly painful to do correctly.  In order to know the number of switch cases, we have to know the bit size of the selector.  However, we need to know the switch cases early when we do the initial CFG walk and, at that point, we haven't processed any instructions other than control-flow so we have no way to know the bit size of the selector.
Comment 3 programmerjake 2017-07-06 02:11:30 UTC
you could implement an initial type-deduction pass; you shouldn't need to know the cfg for that to work, because the OpPhi instructions state their type.
Comment 4 Jason Ekstrand 2017-12-07 01:53:41 UTC
I have a branch for this now:

https://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/spirv-type-tracking
Comment 5 Jason Ekstrand 2017-12-12 06:43:28 UTC
This should be fixed by the following commit:

commit df657ebb68a000b031d1b052748af5df4b645b59
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Wed Dec 6 10:01:22 2017 -0800

    spirv: Add support for all bit sizes in OpSwitch
    
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101560


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.