Age | Commit message (Collapse) | Author |
|
|
|
|
|
opcodes. When enabled via environment vars, gears runs and almost
looks right but other apps are still quite buggy.
|
|
|
|
so r200SetBuffer, r200SpanRenderStart and r200SpanRenderFinish get called again.
Bugzilla #3705, #3706.
|
|
Restore that behavior with new _mesa_alloc_texmemory() function.
Should fix via_sse_memcpy() problem in found with flightgear.
|
|
is basically patch #2939 from X.org bugzilla #3379. This does *not*
fix the bug as it does not dynamically generate stubs at run-time. It
just gets things one step closer.
|
|
either with software or hardware rendering.
|
|
|
|
by Idr. This patch is based on Idr patch to radeon driver.
Change #if 1 to #if 0 (r300_context.c:l69) for old dispatch
tab.
|
|
|
|
|
|
|
|
|
|
Remove old (pre-renderbuffer) span code instead of converting that too. Remove this old code from mach64 (the dead code was not fully converted to spantmp2 previously) too.
|
|
|
|
|
|
|
|
|
|
include $(TOP)/configs/current in glapi/Makefile so those vars can be
easily overridden by any system config, if needed.
|
|
Now, OLD_RENDERBUFFER marks code that needs to eventually be removed when
all the drivers are updated to no longer need the SetBuffer() function.
|
|
|
|
|
|
individual drivers and put them in common code. It is still possible for a driver to define its own macros if it has special needs. This affects CLIPPIXEL, CLIPSPAN, HW_CLIPLOOP, HW_ENDCLIPLOOP, and for drivers using the spantmp2 template also GET_SRC_PTR and GET_DST_PTR.
|
|
device-specific code. A new Python script
(src/mesa/glapi/extension_helper.py) generates a list of all
entry-points for all known extensions. Each driver the selects only
the extensions that it needs and enables the via either
driInitExtensions or driInitSingleExtension.
This code has been compile-tested on a drivers, but has only been
run-tested on mga and i915 (on i830 hardware).
These changes were discussed at length on the mesa3d-dev mailing list.
http://marc.theaimsgroup.com/?t=111947074700001&r=1&w=2
|
|
|
|
|
|
testing the flags field.
Move definition of all the MAT_FLAGs into the m_matrix.c file since they're
now private.
|
|
This cleans up and simplifies the arithmetic quite a bit.
|
|
Pixel count can be negative (this could be fixed elsewhere), so adapt the
functions to work with such inputs correctly (same behaviour as non-optimized
functions).
Bugzilla #2317
Submitted by idr
|
|
-use depth tiling if tiling is enabled
|
|
|
|
Fix slipup from CVS update that was commented out and did not show up during compilation.
|
|
Emit wait idle and pacify r300 before emitting state - this seems to improve stability.
|
|
|
|
|
|
If that stuff is still needed, lots of other updates are needed anyway.
Also, some misc MALLOC/FREE -> _mesa_malloc/free() changes.
|
|
|
|
|
|
during fallbacks. In one case, _swsetup_Wakeup had just been called, covering
the need there, and in the other case, we can simply exit the entire
radeonChooseVertexState function, knowing that it will be called again once we
leave the fallback.
Bugzilla #: 2516
Submitted by: sroland
|
|
|
|
RADEON_DEBUG=fall.
|
|
values to reserved fields on the card, resulting in all-black output and
sometimes hangs.
Submitted by: Thomas Winischhofer
|
|
|
|
|
|
|
|
|
|
glTexImage3D that caused me so many problems during the re-development
of the API scripts reared its ugly head again. This has been fixed by
tracking the parameter string for each entry-point individually.
This has the annoying side-effect that the names of the parameters in
all aliases of a function must be the same or gl_apitemp.py will
generate bad code. :( The changes in
src/mesa/glapi/{gl_API.xml,glapitable.h} and src/glx/x11/* are caused
by fixing the parameter names in various function aliases that didn't
match.
Reported by: Eric Anholt, Jacob Jansen
|
|
Romanick for pointing it out. Please review.
|
|
span functions pass in a gl_renderbuffer to indicate which color
buffer should be drawn into. Optimized line/triangle routines are
smart enough to know which buffer to draw into as well.
The swrast->SetBuffer() routine should eventually be removed from
all drivers.
|