Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
Keep external includes to glxheader.h and xmesa includes to xmesaP.h.
Drop the following from xm_image.h:
- dix-config.h (comes from glheader.h)
- xfree86 includes (come from GL/xmesa_xf86.h)
- ifdef __CYGWIN__ (leftover ? xm_api.c has something similar)
|
|
|
|
|
|
|
|
It is no longer linked with DRI drivers, libGL passes function pointers through
the DRI interface.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Drop XMesaSetVisualDisplay(), XMesaReset(), no longer used.
Add XMesaCopyContext() and move the GlxSetRenderTables() call for XGL within
XMesaForceCurrent(). This is to make xserver/GL/mesa/X/xf86glx.c unaware of
Mesa internals.
Also, clean some ifdef's to make it clear that USE_XSHM and XFree86Server are
mutually exclusive.
Lastly,
- move gcstruct.h from glxheader.h up to xmesa_xf86.h since it calls *gc->ops
- drop GL/glxtokens.h from xm_api|dd.c, GLX tokens come from glcore.h and are
used irrelevant of XFree86.
|
|
|
|
|
|
Was removed during glsl-compiler work. Still need to go back and revisit this
because of the interaction with fragment shaders...
|
|
Always call driFlipRenderbuffers() with pfCurrentPage value, in case it's
initially 1 instead of 0. May fix some issues with pageflip, the same fix was
applied to r128, radeon and r200 (6e0e6eff05727ac8833c2b2dffc51c6619427e77).
|
|
dereferences it.
Same fix as for r300 (which fixed https://bugs.freedesktop.org/show_bug.cgi?id=10417),
since it's likely an issue with those drivers too.
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=10417 .
|
|
mis-count in offset led to mis-rendering and lockups;
units are 4 bytes rather than 1. Noticed by Chris Salch.
fixes bug 7994, possibly others.
|
|
|
|
As far as we know, the hardware prefers outputs packed tightly together
with no holes caused by outputs that are not even read by the fragment
program. Therefore, we slightly rewrite vertex programs in this case.
It would be interesting to test this interaction between vertex programs
and fragment programs further, because some of that rewrite may be
unnecessary. However, play it safe for now and don't change the current
behaviour.
|
|
|
|
|
|
|
|
Since the recent renderbuffer refcounting fixes it's no longer sufficient to
just remove the old renderbuffer from the framebuffer and then add the new one
because the former may decrease the reference count to 0 and delete the old
renderbuffer.
|
|
|
|
|
|
|
|
values for nr of entries) should meet the requirement.
|
|
|
|
|
|
The texture_rectangle fix introduced a bug where every texture instruction
caused a new indirection.
|
|
|
|
Still crashes out on scissor regs
|
|
R300 hardware takes texcoords in the range 0..1 even for rectangle
textures. Previously, the necessary texcoord conversion was applied
to the texture coordinate during vertex processing in a render stage.
This is obviously wrong when fragment programs are used, which can
calculate arbitrary coordinates for TEX instructions. Therefore,
we now inject an appropriate MUL instruction before a TEX that
reference a rectangle texture.
|
|
There used to be an assertion when a fragment program accesses an incomplete
texture image. Work around this assertion.
Note: I am unsure whether this workaround produces the desired result
(0,0,0,1) on all hardware.
|
|
When no textures were enabled, a KIL instruction triggered an assertion
in r300_setup_rs_unit.
|
|
|
|
|
|
Nicolai writes:
When the pixmap pixel format has no alpha channel, the x11 driver
(software rendering) adds a wrapped alpha channel on request.
During SwapBuffers, this alpha channel is not copied from back to
front, which means that the front buffer doesn't really contain the
contents that the back buffer previously contained.
A subsequent glReadPixels from the front buffer will return an
incorrect result. The following patch attempts to fix this.
|
|
|
|
|
|
StateFlags has been updated in _mesa_add_state_reference
|
|
|