Age | Commit message (Collapse) | Author |
|
It could only be called from XMesaCopySubBuffer but this function is not used
by XFree86.
It seems that XMesaPutImageHelper would handle sub-images but never got
finished. Proper sub-image helpers should be written if need be.
|
|
This uses xmesa.h as the GLcore interface and avoids adding an explicit GLcore
inteface which would not be a proper interface anyway.
It puts the declarations of the three functions specific for XMesa/XFree86 in
xmesa.h, we can push them down to xmesa_xf86.h if hiding behind XFree86Server
ifdef's is not enough.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|