| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fixed function vertex program shouldn't need to deal or touch tex coords
if stuffing is enabled.
Though I'm not 100% this won't break assumption made elsewhere it seems like
the correct thing to do, and makes r300g point sprites a lot easier to implement.
draw: fix point-sprite when vertex program is used.
This commit regressed draw, so fix it as well to help bisection.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The point size min/max registers (unused by mesa state tracker) were removed
since most hardware couldn't do much with them. However, we don't want to have
to rely on hw to do point size clamping correctly to implementation
dependent limits, hence have to do that in the vertex shader. This should also
solve a potential problem with (non-AA) points smaller than 1.0 which according
to OGL still have size 1.0.
Note that OGL point rendering is odd, in particular point sprites are rasterized
differently to points. Some hardware might support those different modes, but in
any case the different clamping values used for smooth/multisampled/sprite
enabled points might help a bit for hw which rasterizes points the same as point
sprites.
Also tweak mesa's ff to vertex shader translation so don't have to clamp twice in
case of point attenuation.
|
|
|
|
|
| |
It does nothing else while being less useful than exit() because it lacks
attributes that real exit() has.
|
|
|
|
|
|
|
| |
The padding was there to indicate the amount of space left from the
number of expected bytes in the struct minus allocated bits. But
uint bitfields get packed so that they don't cross uint boundaries, and we
ended up allocating an extra dword to hold the pad field!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
| |
|
|
|
|
| |
Fixes piglit fp-fog failure with gallium.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Varying material inputs were not being picked up from the same slots
where the VBO code is currently placing them (GENERIC0 and above).
Most often they were just being ignored.
|
|
|
|
|
|
| |
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
|
|
|
|
|
|
| |
This is a quick fix for z fighting in quake4 caused by the mismatch
between vertex transformation here and in the position_invarient code.
Full fix would be to make this driver-tunable and adjust both
position_invarient and ffvertex_prog.c code to respect driver
preferences.
|
|
|
|
|
|
| |
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'dots' register wasn't getting properly un-negated and un-swizzled
after emitting the code for back-face lighting. So, if more than one
light source was enabled, the specular exponent for the next light source
was wrong.
During execution we were evaluating pow(x, y) where y was negative instead
of positive. This led to the outcome being zero or NaN.
This fixes the occasional black triangles seen in isosurf when hacked to
enable two-sided lighting.
|
| |
|
|
|
|
| |
This was never fully fleshed out and hasn't been used.
|
|
|
|
| |
New gl_texgen struct allows quite a bit of code reduction.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/ffvertex_prog.c
src/mesa/main/texenvprogram.c
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The max texture coord units is still 8. All the fixed-function paths are
still limited to 8 too. But GLSL shaders can use more samplers now.
Note that some texcoord-related data structures are declared to be 16
elements in size rather than 8. This just simplifies the code in a few
places; the extra elements aren't accessible to the user.
These changes haven't been extensively tested yet, but sanity checking has
been done.
It should be possible to increase the max image units/samplers to 32 without
doing anything special. Beyond that we'll need longer bitfields in a few
places.
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/shader/prog_execute.c
src/mesa/shader/slang/library/slang_vertex_builtin_gc.h
|
| |
| |
| |
| |
| | |
Dots is re-used if more than one light is enabled. Previously
the negate flag of dots may affect next light.
|
| | |
|
|\| |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| | |
Conflicts:
src/mesa/main/context.c
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Don't use a fixed-size array. Saves memory in most cases and avoids
potential overflow for long programs.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
substitute"
There was a bug in emit_degenerate_lit() that caused the SLT to produce
unpredictable results in lit.z
Plus, added a bunch of new comments.
|
| |
| |
| |
| |
| |
| | |
This reverts commit e841b92d9c8bf48085b4996df828ae745977f931.
This fixes two specular lighting conform failures.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This reverts commit feceb43948f76cc4d4c8ecbb86b1b1f438c6daee.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Use a faster path in that case & make gears go faster.
|
| |
| |
| |
| |
| | |
Start pulling over some of the optimizations from the fixed function
paths.
|
| | |
|
| | |
|