| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Use the same input map handling for fftnl and vertex programs. It doesn't
enable any new functionality (should make it easy to support per-vertex
materials though), but the code is much cleaner.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
into vbo-0.2
Conflicts:
src/mesa/array_cache/sources
src/mesa/drivers/dri/i965/brw_context.c
src/mesa/drivers/dri/i965/brw_draw.c
src/mesa/drivers/dri/i965/brw_fallback.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_vs_tnl.c
src/mesa/drivers/dri/mach64/mach64_context.c
src/mesa/main/extensions.c
src/mesa/main/getstring.c
src/mesa/tnl/sources
src/mesa/tnl/t_save_api.c
src/mesa/tnl/t_save_playback.c
src/mesa/tnl/t_vtx_api.c
src/mesa/tnl/t_vtx_exec.c
src/mesa/vbo/vbo_attrib.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_save_api.c
src/mesa/vbo/vbo_save_draw.c
|
| | | |
|
| | |
| |
| |
| | |
and texture inputs to them. Not widely tested yet. This should eliminate all fallbacks due to vertex programs, except writes to back facing colors, or when exceeding a hw limit (12 temps, 12 attribs etc.).
|
| |/ |
|
| |
|
|
| |
computation into the vertex program (not yet fixed for swtnl). Simplify (and correct) the VTX_TCL_OUTPUT_VTXFMT handling when using vertex programs, turns out it's solely driven by the needs of the past-vertex stage of the pipeline, this should fix lockups with ill-specified applications using vertex programs (for instance applications enabling fog but not writing to fog coord output will now get (conformant) undefined results instead of lockups).
|
| |
|
|
| |
nearly the same as outlined in bug #4707, except it disables perspective correction for point sprites to make them actually work. And, separate the state atom into two as the tcl parameters would overwrite vertex program parameters when active. Also implement the GL_VERTEX_PROGRAM_POINT_SIZE_ARB option to make vertex programs outputting a point size work correctly (untested). Smooth points will still always be size 1. While here, enable gouraud shading for fog when using fog coord.
|
| |
|
|
| |
already in a tcl fallback, otherwise the chip will instantly lock up when vertex progs are enabled the next time not in a tcl fallback (fixes for instance guaranteed lockup running any program which uses vertex progs with tcl_mode=0 and then later with tcl_mode=1).
|
| |
|
|
| |
generic attribs cause a fallback, but otherwise it seems to work quite well. Passes all glean vertProg1 tests with the exception of the degnerated LIT case (which is a hw limitation), as well as runs the r200 render path of doom3/quake4 (1.1 patch needed for quake4). The code is heavily borrowed from the r300 driver as vertex programs encoding is almost identical. arb_vertex_program is not yet announced by default and still needs to be enabled via driconf.
|
| |
|
|
|
|
| |
with seccolor on rv200 and r200.
Submitted by: sroland
|
| |
|
|
| |
vtxfmt not causing a fallback when fog coords are active.
|
| |
|
|
| |
point sprite primitive.
|
| | |
|
| |
|
|
| |
same as tnl->render_inputs). Fixes recent tcl problems.
|
| | |
|
| | |
|
| |
|
|
| |
coordinate of the vertex (bugzilla #1648)
|
| | |
|
| | |
|
| |
|
|
|
| |
and enable hardware quads on r200 and radeon. samples/prim renders quads
correctly now.
|
| |
|
|
| |
fog coords (it seems the chip cannot do fog factor computation when not using fragment depth as fog coord source). vtxfmt uses fallback for now (most code present but some magic would be needed if replaying vertices is necessary later on).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
coordinate generation. Original code by Roland Schiedegger, with changes by
myself. While here, ensure that the swtcl path does tnl_install_attrs enough
when fog/specular are being (en/dis)abled.
Notable effects:
- projtex test works with TCL and is closer with swtcl (Bugzilla #1461)
- 8/9 squares work in texgenmix instead of 3.
- texcyl "reflect" mode works (GL_SPHERE_MAP is now a fallback -- unclear if the
hardware can actually support it).
- flickering in doom3 replaced by just plain darkness.
- blocktube fixed (Bugzilla #984)
- fixes stex3d
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
errors on r100 and rendering errors and hangs on r200 (same for R100 without
OLD_PACKETS).
If a command buffer filled after some state (EmitState or a VBPNTR write) was
emitted, the lock was grabbed, the buffer flushed, a new buffer prepared, and
the lock dropped. Another client could come in, set its own state as part of
rendering, and when the first client flushed the rendering commands depending
on the previous state, it got the 2nd client's state. This is fixed by checking
for enough space before beginning a set of state emits and rendering, and
flushing the buffer first if so. This guarantees that the buffer won't wrap.
Also, move the "lost_context = 1" from the end of cmdbuf flushing to
UNLOCK_HARDWARE for clarity (at a minimum) that any time the lock is dropped,
state may get overwritten. We don't have enough information at the point of the
LOCK_HARDWARE to reset our state to the last UNLOCK_HARDWARE point in the case
that we did lose our context, but saving the information to rebuild that state
may be a useful optimization (ipers data suggests up to 5%).
|
| |
|
|
| |
workarounds only for r200, not derivatives.
|
| |
|
|
| |
MaxTextureUnits (Andreas Stenglein, Ronny Vindenes)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
