| Age | Commit message (Collapse) | Author |
|---|
|
|
|
i965 can either do SRGBA8_REV format or SARGB8 format, but not SRGBA8.
Could add SRGBA8_REV support to mesa, but simply use SARGB8 for now.
While here, also add true srgb luminance / luminance_alpha support -
unfortunately the published docs fail to mention which asics support
this, tested on g43 so assume this works on any g4x.
|
|
need to respect the user-supplied base format, not the one derived from
the texture format actually used.
|
|
|
|
|
|
|
|
|
|
This is a (partial) backport of the signed texture format support in OGL 3.1.
Since it wasn't promoted from an existing extension roll our own.
|
|
use color format constants instead of magic numbers
remove handling of cpp 0 or 3 (neither is possible) in various places
don't misconfigure 8 bit surface blits as rgb565
|
|
|
|
The default texture is used when a sampler uses an incomplete texture.
This change fixes the piglit fp-incomplete test.
|
|
|
|
|
|
|
|
if you hit this you've already failed but we shouldn't crash
|
|
|
|
- remove disabled code
- silence compiler warnings (uinitialized values)
- remove unneeded code
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
|
|
Fixes Sun cc error:
"r300_cmdbuf.c", line 142: invalid cast expression
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Since core Mesa MAX_TEXTURE_LEVELS was bumped, we were incorrectly advertising
a maximum texture size of 4096 on older chips, causing corrupted menu text in
Extreme Tux Racer or Armagetron.
Also make sure our texture image array can actually hold all the mipmap levels
we support...
|
|
|
|
To distinguish from the -0.2 version still being maintained on the
gallium-mesa-7.4 branch. There are already greater interface changes
between these two branches than there were between -0.2 and -0.1.
Also stop injecting Tungsten into the vendor string - the Gallium in
the renderer string should be sufficient.
|
|
The FBO pixel coordinate system, with (0,0) as the
upper-left pixel, is inverted in Y compared to the
normal OpenGL pixel coordinate system, which has
(0,0) as its lower-left pixel.
Viewport and polygon stipple are sensitive to this
inversion; so is point rasterization. The basic
fix is simple: when rendering to an FBO, instead
of the normal RASTRULE_UPPER_RIGHT that's
appropriate for OpenGL windows, use the Y inversion
RASTRULE_LOWER_RIGHT.
Unfortunately, current Intel documentation has this
value listed as "Reserved, but not seen as useful".
It does work on at least some i965-class devices,
though; and the worst that could happen if an
older device didn't support it would be incorrect
point rasterization to FBOs, which is what happens
already, so this fix is at least no worse than what
happens presently, and is better for some (and possibly
all) i965-class devices.
|
|
|
|
This also cuts instructions by just using the existing bit in the payload
rather than computing it from the determinant in the SF unit and passing it
as a varying down to the WM. Something still goes wrong with getting the
backface color right, but a simpler shader appears to get the right result.
|
|
Previously, we would sample (f,glFrontFacing,undef,undef) instead of the
(f,0,0,1) that fragment.fogcoord is supposed to return. Due to
glFrontFacing's presence in FOGC.y, we'll still give bad results there when
glFrontFacing is used.
Bug #19122, piglit testcase fp-fog.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Turns out that XXX comment was important. We weren't flagging the WM to
re-update with the statistics enable, so we got zeroes out of our query.
Bug #20740, fixes piglit occlusion_query test.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
|
|
Re work depth issues.
Do a lot more FBO abstactions
fixup depth/stencil buffer interactions
|
|
|
|
also fixup old interface, gets rid of white boxes in compiz
|
|
|
|
|
|
|
|
|
|
|
|
same as ARGB need to add a parameter to get ptr32
|
|
|
