[Mesa-dev] TGSI ISA formalization

[Corbin Simpson]

On Thu, Jun 17, 2010 at 11:34 AM, Zack Rusin <zackr at vmware.com> wrote:
> Why would you want that? Is that useful to anyone? The state trackers
> will use the instructions they need whether a group of GPUs supports
> it or not, i.e. it's not like they could emulate LOAD.
>
> Besides we can't really do that. We already had a number of discussions
> about caps and the outcome each time was that you can't just create a few
> groups and expect the hardware to neatly fall into them (while quite frankly I
> never quite agreed with this sentiment, majority has spoken). In any way
> the question of which opcodes the given hardware supports is not up to
> gallium docs to define.
>
> I think we can only make it easy for people to understand the instructions
> Gallium does provide and for that logical grouping is really the only way
> to go.

Considering the disparate ISAs of nvfx, r300, i915, and things we
don't have public drivers for (yet), like poulsbo and volari; and
considering the inability of contexts to fail to compile shaders, I'd
say that this is not such a simple thing.

Sure, TGSI has double opcodes. One might think that this is awesome,
and writes a shader using double opcodes. But, it mysteriously doesn't
work on r300g. Either it asserts (current behavior), or it drops all
the rendering on the floor. We have no way to tell the state tracker
that the shader failed to compile. In my mind, this is a big problem,
since it requires drivers to magically Just Work for any shader. GL
(and IIRC D3D) permit shaders to fail for arbitrary reasons; why can't
we do the same?

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>