| Age | Commit message (Collapse) | Author |
|---|
|
The no_rast fallback was getting partially overwritten by later TNL init,
resulting in a segfault when things were in a mixed-up state.
|
|
Apparently a bit gets flipped in the addressing for some rows of each tile.
|
|
|
|
If you have a GPU using this code and it has the offsets up in this space,
this fails.
|
|
Per airlied's suggestion.
|
|
Only when fog's enabled, of course.
In the usual case, this is just a pass-through operation.
|
|
Fixes stack overflow on Windows.
|
|
|
|
tests/bug_3195 doesn't render right, but at least it doesn't segfault this way.
|
|
Oooops. Hehe.
|
|
Properly set t->filter_1 for r300_state to emit.
Expect buggies as people see LOD bias enabled for the first time...
|
|
Not like it matters, though, since it's not taking effect yet.
|
|
Needs a bit more work on submission.
|
|
Don't try to clean in xorg since GLcore is gone.
|
|
I don't like PROGRAM_BUILTIN; could we either patch Mesa or just use a different constant?
|
|
r5xx should fallback if it encounters a bad FP.
TODO: Re-enable the dumb shader so we don't have to completely fallback.
|
|
This new generic transform replaces "special" instructions by more generic
variants. Hopefully, we will be able to share this code between r300 and r500.
|
|
MOV, ADD and MUL do not fit the hardware as well as MAD, but they are less
complex and thus leave more room for future optimizations.
|
|
|
|
Add the code emission source file, and comment out unneeded tex de-swizzling.
|
|
Yes, I know it's massive. Imagine how I felt, auditing 3000 lines of code.
|
|
*Pulls paper bag down over head*
|
|
|
|
Since ARB_fragment_program and friends are defined to ignore the setting of
the GL_TEXTURE_COMPARE_FUNC parameter, we have to explicitly enable the
shadow comparison by marking the texture unit in ShadowSamplers when
appropriate.
|
|
|
|
Streamlining source and destination registers, as well as texcoord scaling for
RECT textures is now done in a radeon_program based transformation.
The idea is that this will allow us to optimize away unnecessary indirections
more easily.
|
|
The idea/hope is that radeon_program will serve as an intermediate
representation for r3xx up to r6xx fragment and vertex programs.
Right now, it is nothing more than a simplistic wrapper around Mesa's
prog_instruction, together with the notion of clauses, taken from r6xx docs.
The clauses will eventually be used to represent the nodes that are used in
r300 family fragment programs.
|
|
|
|
|
|
Refactor so that r300_pfs_compile_state "owns"/holds a pointer to
r300_fragment_program instead of the other way round. This is more natural from
an object orientation point of view.
Move the compiled hardware state into r300_fragment_program_code, in
anticipation of on-the-fly program recompilation based on external OpenGL
state.
|
|
|
|
r500 code still used r300_pfs_compile_state, which contains some fields that
really only make sense on r3xx type hardware. In order to allow both fragprog
implementations to go forward without disturbing each other, I've pushed this
structure down into the respective r[3|5]00_fragprog.c
|
|
|
|
|
|
This is for loading swrast_dri.so from libGL.
MakeContextCurrent() seems to unbind the context right after binding it and
DRI drivers also have a noop DriverAPI.UnbindContext ...
|
|
|
|
|
|
test in if.glsl
|
|
|
|
e.g.
const int kernelSize = 9;
uniform vec2 kernel[kernelSize];
|
|
|
|
|
|
|
|
Someone changed the function parameters but didn't bother to update the
comments.
Also, whitespace changes, clean-ups.
|
|
|
|
This is an API breakage only.
|
|
The objects are swappable, so we're less concerned by excessive object
allocation now, and it's about a 20% performance improvement. If we get
concerns about the memory consumption from others, we can look into a
compromise position later.
|
|
|
|
|
|
|
