| Age | Commit message (Collapse) | Author |
|---|
|
Not like it matters, though, since it's not taking effect yet.
|
|
Needs a bit more work on submission.
|
|
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*
|
|
|
|
|
|
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 ...
|
|
|
|
Someone changed the function parameters but didn't bother to update the
comments.
Also, whitespace changes, clean-ups.
|
|
|
|
|
|
Also, build driverfuncs.c into libmesa.a since it's always needed.
|
|
|
|
|
|
This workaround is similar to the one found in r200_span.c.
It seems like some part of the read hardware doesn't realize that
VRAM has changed. By reading from an arbitrary position, this is fixed.
The piglit test bugs/r300-readcache is a regression test for this bug.
|
|
|
|
If an app does not use GL_EXT_tex_filter_aniso, this lets driconf set it instead.
|
|
This also fixes a bug with Zfunc set to GL_NEVER in glean/paths.
|
|
This fixes the glean/maskedClear test.
|
|
The glean/readPixSanity test passes now.
|
|
Thanks to Corbin for the initial cut today. Fixed some minor stuff (in
particular, make sure we still use a MIP_LINEAR filtering mode; anisotropy
without MIP_LINEAR filtering is not the truly pleasing anisotropy).
|
|
|
|
Not quite finished, maybe? Not sure.
|
|
To do: Add a slightly more accurate LIT. Will do later.
|
|
The texture layout calculations for mipmapped cubemaps used to be completely
wrong, since the GPU expects images to be grouped by miplevel instead of by
face number.
This has been fixed now, though the memory layout is still slightly incorrect
for the smaller miplevels. Unfortunately, the docs are lacking in that area.
|
|
This commit should not affect the functionality at all, just cleanup
some of the original texture filter guesswork using information from
the register documentation.
|
|
This variable was only ever written to, but nobody used its value.
|
|
|
|
I'll release a libdrm 2.3.1 without TTM apis included from a special
drm branch that should allow mesa 7.1 to build against it.
I've had to turn off DRI2 stuff.
|
|
This is only part of the fix. Someone with more autoconf-fu will have
to fix the rest
|
|
|
|
Thanks to nh for the r3xx version.
|
|
Setup fg_depth_src for depth writing programs and change early Z (ztop)
semantics.
Piglit's version of glean/fragprog test passes now (unlike Glean, its
dependency on EXT_fog_coord, which we don't support, is optional).
R3xx only at the moment, but should be straightforward to adapt to R5xx
(I don't own an R5xx, and I don't want to break anything.)
|
|
The KIL instruction only works if at least one texture unit is enabled
in hardware.
Texture instructions do not support swizzles, negations etc. natively,
so we now emit an explicit swizzling etc. operation when the texture coordinate
requires it.
This fixes the Piglit fp-kil test.
|
|
Why didn't anybody tell me we were missing this one? I thought I committed it ages ago!
|
