some of the ALU instructions are different on r6xx vs r7xx,
separate the alu translation to separate files, and use family
to pick which compile stage to use.
Depth clamping seems to be implicit if clipping is disabled.
It's not perfect, but it's good enough for wine and passes
the corresponding piglit tests.
This quiets a compiler warning, (and ensures a segmentation fault rather
than memory corruption if this variable is written through before being
initialized elsewhere).
While bootstrapping the dependencies, make will see the "include depend"
directive before the depend file has been created. To avoid a spurious
warning in this case we use "-include" instead, (which differs precisely
in the fact that it will not emit a diagnostic if the named file does
not exist).
This avoids two "function defined but not used" warnings. For the yyinput
function we define YY_NO_INPUT which tells flex to simply not generate this
function.
For unput, we add a call to this function, but inside a while(0) so
that it will quiet the warning without actually changing any
functionality.
Add declarations for two functions generated in the flex ouput. It
would be nicer if flex simply declared these generated functions as
static, but for now we can at least avoid the warning this way.
Instead of one big boolean indicating indirect addressing, use a
bitfield indicating which register files are accessed with indirect
addressing.
Most shaders that use indirect addressing only use it to access the
constant buffer. So no need to use an array for temporary registers
in this case.
The previous code assumed that all elements of the address register
were the same. But it can vary from pixel to pixel or vertex to
vertex so we must use a gather operation when dynamically indexing
the constant buffer.
Still need to fix this for the temporary register file...
If max_index=0xffffffff and elt_bias > 0 the test for
elt_bias + max_index >= DRAW_PIPE_MAX_VERTICES
was wrong. Check earlier if max_index=0xffffffff and do the
"fail" case.
This fixes the piglit draw-elements-base-vertex test (and probably
some other things).
When defining mipmap level 'L' and level L-1 exists and the new level's
internalFormat matches level L-1's internalFormat, then use the same hw
format. Otherwise, do the regular ctx->Driver.ChooseTextureFormat() call.
This avoids a problem where we end up choosing different hw formats for
different mipmap levels depending on how the levels are defined (glTexImage
vs. glCopyTexImage vs. glGenerateMipmap, etc).
The root problem is the ChooseTextureFormat() implementation in some
drivers uses the user's glTexImage format/type parameters in the choosing
heuristic. Later mipmap levels might be generated with different calls
(ex: glCopyTexImage()) so we don't always have format/type info and the
driver may choose a different format.
For more background info see the July 2010 mesa-dev thread "Bug in
_mesa_meta_GenerateMipmap"