| Age | Commit message (Collapse) | Author |
|---|
|
Before, the instruction's CondUpdate field was mistakenly effecting the
constant-fetch operation.
Fixes progs/glsl/bump.c demo. But there are some other issues related
to condition flags and IF/ELSE that need investigation...
|
|
This gets us the savings for driver-internal viewport calls that
dd1c68f15123a889a3ce9d2afe724e272d163e32 was attempting, without relying
on Xlib internals or clients handling X events.
|
|
This speeds up OA on my GM45 by 21% (more than the original CPU cost of
the upload path). We might still be able to squeeze a few more percent out
by avoiding repeatedly mapping/unmapping buffers as we upload elements into
them.
|
|
|
|
Otherwise current xserver / libGL no longer expose a 32 bit RGBA GLX visual,
and compiz fails.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20479 .
|
|
|
|
EyeDirection -> SpotDirection
_NormDirection -> _NormSpotDirection
|
|
|
|
|
|
|
|
|
|
Everything is in place now for using a true constant buffer for GLSL fragment
shaders. Still some bugs to find though.
|
|
We were accidentally clobbering the next register.
|
|
|
|
Currently, shader constants are stored in the GRF (loaded from the CURBE
prior to shader execution). This severly limits the number of constants
and temps that we can support.
This new code will support (practically) unlimited size constant buffers
and free up registers in the GRF. We allocate a new buffer object for the
constants and read them with "Read" messages/instructions. When only a
small number of constants are used, we can still use the old method.
The code works for fragment shaders only (and is actually disabled) for now.
Need to do the same thing for vertex shaders and need to add the necessary
code-gen to fetch the constants which are referenced by the shader
instructions.
|
|
|
|
This code won't actually be used and will be removed in a subsequent commit.
Just committing for posterity.
|
|
Fixes regression seen with progs/glsl/bump.c
|
|
|
|
|
|
|
|
Used to read float[4] vectors from the constant buffer/surface.
|
|
|
|
|
|
|
|
Call the get_src_reg_imm() function when it's permissible to generate a
literal value src register.
|
|
The value was always 1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1) Don't error-check here. It's done in glx makeCurrent.
2) Allow ctx and the dri drawables to be NULL for future use. This is
currently blocked in glx makeCurrent.
3) Avoid updating dri drawables unless they are completely uninitialized.
Since the updating was done outside of the lock, the driver need to
verify and redo it anyway.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
We don't upload the pixels with the CPU in that case, so the map will
only serve as a way of triggering cache flushes over a bunch of data we
don't touch.
|
|
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.
|
|
|
|
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
|
|
- 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...
|
|
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.
|
|
|
