| Age | Commit message (Collapse) | Author |
|---|
|
also fixup old interface, gets rid of white boxes in compiz
|
|
|
|
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>
|
|
Conflicts:
src/mesa/drivers/dri/r300/r300_cmdbuf.c
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/r300/r300_swtcl.c
src/mesa/drivers/dri/r300/radeon_ioctl.c
src/mesa/drivers/dri/radeon/radeon_screen.c
|
|
|
|
|
|
|
|
The xlib build was using the system's Xlib headers or bombing if they
weren't available.
|
|
radeonScheduleSwap() already takes the lock in the SwapBuffers case, only
the CopySubBuffer case was missing it.
|
|
Otherwise they fail with AIGLX at least.
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes back-buffer rendering when MESA_BACK_BUFFER=pixmap
|
|
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.
|
|
|
|
|
|
This fixes a hang on context destruction on rs690
|
|
|
|
A bit of refactoring with an eye toward ES2 and GL 3.1
|
|
|
|
This was never fully fleshed out and hasn't been used.
|
|
|
|
|
|
It complained about uninitialized values
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
When we finish emitting swtcl objects, we request space in the cmdbuf,
and flush if no space exists. However in this case we also flush
the DMA buffer we just put the vertices we wanted to send in.
This checks in advance if we have space in the buffer.
|
|
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.
|
|
|
|
|
