| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
saves us a dword in sampler state, hw can't do non-integer aniso degree anyway.
To allow aniso 1x (which seems of dubious value but some hardware (radeons)
have such a mode, and even d3d allows specifiying it) redefine anisotropic
filtering as disabled only if max_anistropy is 0.
|
|
|
|
Conflicts:
src/gallium/drivers/nv10/nv10_state.c
src/gallium/drivers/nv20/nv20_state.c
src/gallium/drivers/nv50/nv50_program.c
|
|
This determines if points should be rasterized according to GL point rules
or as normal quads (GL point sprites / d3d points / d3d point sprites).
|
|
Don't need sprite coord origin per coord.
Also, don't need separate sprite enable bit - if all coords have it diabled,
then there are no point sprites (technically, there's a distinction in pre-GL3,
but it only differs in having more leniency in clamping to max size, something
the state tracker would need to handle and the hardware won't bother anyway).
Also, use packed field for the per-coord enables.
All in all, should save 3 dwords in rasterizer state (from 10 down to 7).
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_draw_arrays.c
src/mesa/state_tracker/st_draw_feedback.c
|
|
|
|
This patch removes PIPE_TEX_FILTER_ANISO.
Anisotropic filtering is enabled if and only if max_anisotropy > 1.0.
Values between 0.0 and 1.0, inclusive, of max_anisotropy are to be
considered equivalent, and meaning to turn off anisotropic filtering.
This approach has the small drawback of eliminating the possibility of
enabling anisotropic filter on either minification or magnification
separately, which Radeon hardware seems to support, is currently
support by Gallium but not exposed to OpenGL. If this is actually
useful it could be handled by splitting max_anisotropy in two values
and adding an appropriate OpenGL extension.
NOTE: some fiddling & reformatting by keithw to get this patch to
apply. Hopefully nothing broken in the process.
|
|
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour should match what libdrm_nouveau does closely.
- The solution remains statically sized, but when debugging is on it will check
for abuse.
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
|
|
|
|
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
|
|
|
|
Unfortunately it seems that if depth comparison is
active and we read a 2D texture, i.e. provide only
2 inputs, the second is used for comparison ...
|
|
|
|
|
|
Set the same bits as for linear filtering (in addition
to max anisotropy), and 2 unknown bits I've seen set.
|
|
|
|
|
|
|
|
It's the front stencil methods that have contiguous offsets,
not the back ones.
Unfortunately the names in the header still have FRONT/BACK
reversed, so I'm using hex values until it gets updated.
|
|
Red and blue were interchanged in TIC.
Add border color and some formats.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Must copy token stream on shader create, client is allowed to free
their copy after creating the state object.
|
|
|
|
|
|
OK, seems a lot of people have been getting the idea that nouveau is
dying lately - I decided to commit some of the work I've been doing lately
to prove them wrong :) Progress on my side is slow due to lack of time
mainly, but I'm still around.
Firstly, don't even bother trying to use gallium on G8x/G9x yet, it won't
work. I've deliberately left all the necessary winsys changes out of the
commits for a very good reason - I don't know what we're going to need from
the DRM exactly yet and don't want to be continually breaking interfaces
as I discover additional requirements. On my side, I think I've gone
through about 3 different DRM interface changes, and have just discovered
that I may need more yet. It'd be very annoying for everyone who uses
nouveau to keep things in sync. Once I've got it sorted - I'll commit a
lot of cool stuff. Stay tuned.
Also, don't look at the shader code.. it's horribly nasty and full of hacks,
I used it as an opportunity to learn G8x GPU programs at the same time.
New semi-decent code is in works, and will follow at some point. :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NVIDIA love to make life difficult.. we need different flags in PTEs for
zeta.. yay.. not.
|
|
|
|
|
|
|
