[Mesa-dev] [PATCH 0/4] gallium: add new opcodes needed for ARB_gs5

[Roland Scheidegger]

Am 25.04.2014 19:41, schrieb Ilia Mirkin:
> This is enough to catch up to core mesa, with the exception of
> uaddCarry/usubBorrow -- those will require some thought. I don't like the way
> they were done in core mesa, so I may redo it differently. (Will start a
> discussion on that topic after I've given it more thought.)
> 
> I ran the various piglit tests with
> 
> DRAW_USE_LLVM=0
> GALLIUM_DRIVER=softpipe
> MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5
> 
> after modifying them to require GLSL 1.40. (The extension requires GLSL 1.50
> since it deals with GS stuff as well, but it doesn't matter for any of these
> bits.)
> 
> It felt a bit weird to have to add the 4-source logic, but I'm not sure of a
> better way of doing it. NVC0 has a BFI instruction that takes 3 arguments,
> where the last 2 args are just mushed together into 1.
My guess is all hw will have to do with 3 src args. Seems like radeonsi
would do something similar, though I don't know if all hw does it
exactly the same (meaning you could instead expose the 2 instructions
everybody actually uses). But there's nothing really wrong with
instructions using 4 source regs in gallium.

> 
> Also, ARB_gs5 only lets you have one offset/width setting for the entire
> vector (for both BFI and BFE), but I didn't enforce that in the TGSI
> version. (SM5 doesn't seem to make that restriction either.)
> 
> I'm working on a nvc0 impl for all this too, but wanted to send this out first
> in case I messed something up and will have to change a bunch of things
> around.
> 
> I figure there will later be a PIPE_CAP_SM5 that will be set if all of these
> opcodes are supported (and it could subsume PIPE_CAP_TEXTURE_GATHER_SM5). For
> now, there's too much of ARB_gs5 still unsupported to really worry about it.
PIPE_CAP_SM5 also implies things like tesselation.
I guess though if there's no extensions which would expose some of these
things separately it will eventually have to go all together...
A pity since some of the stuff would be easy to implement for instance
in llvmpipe (like the new instructions) whereas others (non-constant
indexing into sampler arrays???) are definitely not trivial.

> 
> Ilia Mirkin (4):
>   gallium: add new opcodes for ARB_gs5 bit manipulation support
>   glsl: fix bitfield_insert use when doing ldexp lowering
>   mesa/st: implement new bit manipulation opcodes
>   softpipe: add tgsi_exec support for new bit manipulation opcodes
> 
>  src/gallium/auxiliary/tgsi/tgsi_exec.c     | 188 +++++++++++++++++++++++++++++
>  src/gallium/auxiliary/tgsi/tgsi_info.c     |   8 ++
>  src/gallium/auxiliary/util/u_math.h        |  11 ++
>  src/gallium/docs/source/tgsi.rst           |  51 ++++++++
>  src/gallium/include/pipe/p_shader_tokens.h |  11 +-
>  src/glsl/lower_instructions.cpp            |   6 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  70 ++++++++---
>  7 files changed, 324 insertions(+), 21 deletions(-)
> 

Roland