| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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>
|
|
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
|
|
Haven't seen failures yet, but if/when there are, more investigation will
be done.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The polygon stipple pattern, like the viewport and the
polygon face orientation, must be inverted on the i965
when rendering to a FBO (which itself has an inverted pixel
coordinate system compared to raw Mesa).
In addition, the polygon stipple offset, which orients
the stipple to the window system, disappears when rendering
to an FBO (because the window system offset doesn't apply,
and there's no associated FBO offset).
With these fixes, the conform triangle and polygon stipple
tests pass when rendering to texture.
|
|
|
|
In the i965, the FBO coordinate system is inverted from the standard
OpenGL/Mesa coordinate system; that means that the viewport and the
polygon face orientation have to be inverted if rendering to a FBO.
The viewport was already being handled correctly; but polygon face
was not. This caused a conform failure when rendering to texture with
two-sided lighting enabled.
This fixes the problem in the i965 driver, and adds to the comment about
the gl_framebuffer "Name" field so that this isn't a surprise to other
driver writers.
|
|
It seems the code that set up the FB_WRITE message was incomplete in this
case. The number of payload registers was wrong and that caused a hang.
It would be good to have a second set of eyes take a look at this...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we're using anything but GL_NEAREST sampling of a cube map, we need to
use the BRW_TEXCOORDMODE_CUBE texcoord wrap mode. Before this, the GPU
would either lock up or subsequent texture filtering would be corrupted.
|
|
Before this change we would up emitting instructions with invalid register
numbers. This typically (but not always) hung the GPU. For now, just
prevent emitting bad instructions to avoid hangs. Still need to do some
kind of proper error recovery.
|
|
This is the size of the intermediate instruction buffer.
|
|
|
|
|
|
This function scans the shader to see if it has any GLSL features like
conditionals and loops. Calling this during state validation is expensive.
Just call it when the shader is given to the driver and save the result.
There's some new/temporary assertions to be sure we don't get out of sync
on this.
|
|
|
|
This can improve debugging with INTEL_DEBUG=batch,sync by giving smaller
batchbuffers.
|
|
I keep wanting to hack this knob in as a one-time thing, so it seemed useful
to have all the time.
|
