| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an awful hack and will hurt performance on Ironlake, but we're
at a loss as to what's going wrong otherwise. This is the only common
variable we've found that avoids the problem on 4 applications
(CelShading, gnome-shell, Pill Popper, and my GLSL demo), while other
variables we've tried appear to only be confounding. Neither the
specifications nor the hardware team have been able to provide any
enlightenment, despite much searching.
https://bugs.freedesktop.org/show_bug.cgi?id=29172
Tested by: Chris Lord <[email protected]> (Pill Popper)
Tested by: Ryan Lortie <[email protected]> (gnome-shell)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Blending is now fully supported with:
- R8_UNORM
- R8G8_UNORM
- B8G8R8A8_UNORM
- R16G16B16A16_FLOAT (r500-only)
Blending is partially supported (DST_ALPHA not working) with:
- L8A8_UNORM
- I8_UNORM
- B5G5R5A1_UNORM
- B10G10R10A2_UNORM
The other formats can't do blending.
|
| |
|
|
|
|
|
|
| |
It's broken now that tgsi_exec_machine::Inputs/Ouputs are pointers.
Temporary if anybody still cares about tgsi_sse2.c. Permanent otherwise.
|
| |
|
|
|
|
|
|
|
|
| |
Because the format can be changed to UNORM in a surface.
This fixes:
state_tracker/st_atom_framebuffer.c:163:update_framebuffer_state:
Assertion `framebuffer->cbufs[i]->texture->bind & (1 << 1)' failed.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| | |
512 KiB should be quite enough, but dynamic resize might be nicer.
|
| |
| |
| |
| |
| |
| |
| | |
PIPE_BIND_CONSTANT_BUFFER alone was OK for nv50/nvc0, but nv30 will need
to be able to set others on certain chipsets.
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Add missing VERTEX_END and treat unaligned offsets correctly.
|
| |
| |
| |
| | |
Introduced in 223d98bb8d49c9e52e498a12980722467ae2bf87.
|
| |
| |
| |
| |
| | |
Also, on nv50 the VERTEX_BEGIN method doesn't follow VERTEX_END,
which was erroneously taken over from nvc0 and is fixed now.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Wasn't updated if the FP didn't change, and coordinate replacement
wasn't disabled anymore.
|
| |
| |
| |
| | |
Must have sneaked in from debugging.
|
| |
| |
| |
| |
| | |
On nv50, branches are absolute, so we need to adjust them according
to the shader's position in the code buffer.
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| |
| |
| | |
This introduces a shared nouveau_context struct to track such things.
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| |
| |
| | |
Port of the nvc0 commit doing the same.
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
nv50_resource is being called nv04_resource now temporarily, to avoid
a naming conflict with nouveau_resource from libdrm.
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
Modified from original to remove chipset-specific code, and to be decoupled
from the mm present in said drivers.
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Ben Skeggs <[email protected]>
|
| |
| |
| |
| | |
We'll have to do some unification now to reduce code duplication.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Computation of the delta of this array from the last had a silly little
bug and ignored any initial delta==0 causing grief in Nexuiz and
friends.
Signed-off-by: Chris Wilson <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a silicon bug which causes unpredictable behaviour if the
URB_FENCE command should cross a cache-line boundary. Pad before the
command to avoid such occurrences. As this command only applies to
gen4/5, do the fixup unconditionally as the specs do not actually state
for which chip it was fixed (and the cost is negligible)...
Signed-off-by: Chris Wilson <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Chris Wilson <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Chris Wilson <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Chris Wilson <[email protected]>
|
| |
| |
| |
| |
| |
| | |
we still have a lot of corner cases that aren't working.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
| |
| |
| |
| | |
Elements(mach->Inputs) is wrong now that mach->Inputs is dynamically
allocated.
|