It turns out that it's not just deviceID dependent, and there's some additional
undefined factor that determines the bit 6 swizzling. It's now controllable
with swizzle_mode=[012] until we get a response on how to automatically detect.
Before, the presence of a 'return' statement always prevented inlining
a function. This was because we didn't want to accidentally return from
the _calling_ function. We still need the semantic of 'return' when inlining
but we can't always use unconditional branches/jumps (GPUs don't always
support arbitrary branching).
Now, we allow inlining functions w/ return if the return is the last
statement in the function. This fixes the common case of a function
that returns a value, such as:
vec4 square(const in vec4 x)
{
return x * x;
}
which effectively compiles into:
vec4 square(const in vec4 x)
{
__retVal = x * x;
return;
}
The 'return' can be no-op'd now and we can inline the function.
cherry-picked from master
Before, the presence of a 'return' statement always prevented inlining
a function. This was because we didn't want to accidentally return from
the _calling_ function. We still need the semantic of 'return' when inlining
but we can't always use unconditional branches/jumps (GPUs don't always
support arbitrary branching).
Now, we allow inlining functions w/ return if the return is the last
statement in the function. This fixes the common case of a function
that returns a value, such as:
vec4 square(const in vec4 x)
{
return x * x;
}
which effectively compiles into:
vec4 square(const in vec4 x)
{
__retVal = x * x;
return;
}
The 'return' can be no-op'd now and we can inline the function.
This isn't complete yet. It does cover the two most common usage cases,
though, and at least the third one (POINT_DISTANCE_ATTENUATION) is possible,
so I'll do that later.
. There is both a per-texture unit and a per-texture object (at least for
OpenGL 1.4); this should now be supported properly.
. The LOD bias calculation in r300_state has been simplified and corrected
(need to multiply by 32 instead of 31, and ensure clamping)
. do not clamp LOD bias in TexEnv, as that behaviour conflicts with what
the spec says
. set Const.MaxTextureLodBias properly
. remove the no_neg_lod_bias property; if somebody can explain what
it's good for, we can add it back in, but according to Google, nobody
seems to use it
. removed some dead code and unused variables
The operation doesn't really make sense. It triggered a bug in the r300 DRI
driver (and possibly other drivers that simulate 1D textures via 2D textures).
I've added an isolated test case for this bug to Piglit, so everybody wins.
OK, seems a lot of people have been getting the idea that nouveau is
dying lately - I decided to commit some of the work I've been doing lately
to prove them wrong :) Progress on my side is slow due to lack of time
mainly, but I'm still around.
Firstly, don't even bother trying to use gallium on G8x/G9x yet, it won't
work. I've deliberately left all the necessary winsys changes out of the
commits for a very good reason - I don't know what we're going to need from
the DRM exactly yet and don't want to be continually breaking interfaces
as I discover additional requirements. On my side, I think I've gone
through about 3 different DRM interface changes, and have just discovered
that I may need more yet. It'd be very annoying for everyone who uses
nouveau to keep things in sync. Once I've got it sorted - I'll commit a
lot of cool stuff. Stay tuned.
Also, don't look at the shader code.. it's horribly nasty and full of hacks,
I used it as an opportunity to learn G8x GPU programs at the same time.
New semi-decent code is in works, and will follow at some point. :)
