| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
these are never USCALED, always UINT in reality.
taken from some work by Christoph Bumiller
v2: fixup formatting of table + tabs
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=34199
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was getting set in draw_set_mapped_constant_buffer() but
if there were no shader constants, that function wasn't called. So the
pt.user.planes field was null and we died when we tried to access the
clip planes in the LLVM-generated code.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41663
Note: This is a candidate for the 7.11 branch.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
Instead of 12 use DRAW_TOTAL_CLIP_PLANES. The max number of user-defined
clip planes was increased to 8 so the total number of planes is 14.
This doesn't fix any specific bug, but clearly the old code was wrong.
Reviewed-by: José Fonseca <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
now that we have integer texture types I can drop this workaround so that
copies of values is done properly (as floats would fail on some corner cases).
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
with these I can drop the force int type hack.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
as per Brian's suggestion, drop the pointless loops.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
Not 100% sure these are correct yet
|
|
|
|
|
|
|
| |
Will get to adding r600/r700/cayman support, have it mostly written on
another PC.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Should fix https://bugs.freedesktop.org/show_bug.cgi?id=41613
We don't want to create these vertex elements unless the pipe driver
vertex stage can handle integers.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
They were already implemented, but not advertised.
|
|
|
|
|
| |
They spam console, but are not very useful - hide them behind
NOUVEAU_MESA_DEBUG environment variable.
|
|
|
|
|
| |
Relocations don't consume pushbuffer space, so there is no need to
ensure there is any space in pushbuffer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is not enough space in pushbuffer for fence emission
(nouveau_fence_emit -> nv50_screen_fence_emit -> MARK_RING),
the pushbuffer is flushed, which through flush_notify ->
nv50_default_flush_notify -> nouveau_fence_update marks currently
emitting fence as flushed. But actual emission is done after this mark.
So later when there is a need to wait on this fence and pushbuffer
was not flushed in between, fence wait will never finish causing
application to hang.
To fix this, introduce new fence state between AVAILABLE and EMITTED,
set it before emission and handle it everywhere.
Additionally obtain fence sequence numbers after possible flush in
MARK_RING, because we want to emit fences in correct order.
Reviewed-by: Christoph Bumiller <[email protected]>
Note: This is a candidate for the 7.11 branch.
|
|
|
|
|
|
|
|
| |
adds handling for int texture/vertices to evergreen.
TODO r600/700 support.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We need add a new set of fragment shader variants, along with new vertex
elements for signed and unsigned clears.
The new fragment shader variants are due to the integers values requiring
CONSTANT interpolation. The new vertex element descriptions are for passing
the clear color as an unsigned or signed integer value.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
NOTE: This is a candidate for the stable branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This add support for unsigned/signed integer types via adding a 'pure' bit
in the format description table. It adds 4 new u_format get/put hooks,
for get/put uint and get/put sint so that accessors can get native access
to the integer bits. This is used to avoid precision loss via float converting
paths.
It doesn't add any float fetchers for these types at the moment, GL doesn't
require float fetching from these types and I expect we'll introduce a lot
of hidden bugs if we start allowing such conversions without an API mandating
it.
It adds all formats from EXT_texture_integer and EXT_texture_rg.
0 regressions on llvmpipe here with this.
(there is some more follow on code in my gallium-int-work branch, bringing
softpipe and mesa to a pretty integer clean state)
v2: fixup python generator to get signed->unsigned and unsigned->signed
fetches working.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
This is used in a few places in drivers as well, also the integer support
can use it as well.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
Unimplemented and not so useful for this driver.
|
| |
|
|
|
|
| |
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
... with the right value.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
|
|
| |
Do it in two passes in that case.
v2: Don't forget to handle stencil clears.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
Docs say this is obeyed.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
4bit palette ftw!
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Docs say that default shader input color input need to be spec
as ARGB8888. And a clear rect prim essentially uses this value
instead of default diffuse. Depth on the other hands is an ieee
32 bit float. Clear stencil is U8.
Completely different are the clear values for zone init prims.
These are speced in the actual output pixel layout (and need
to be repeated for 16 bit formats).
Clear up the confusion by adding some comments.
v2: Retain the target swizzling support added by Stephan Marchesin.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
This way it can be reused in the fastclear path.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
| |
We leave the debug code in place to troubleshoot issues while we complete the transition. That code might be removed after that.
|
|
|
|
| |
We still need to investigate LIS7 though.
|
| |
|
|
|
|
| |
If you want to access it, you should use the Drawable in xlib_drawable instead.
|
|
|
|
|
|
|
|
| |
The previous change was not effective for lines, because there is no
4 planes 4x4 block rasterization path: it is handled by the 16x16 block
case too, and the 16x16 block was not being budged as it should.
This fixes assertion failures on line rasterization.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the tile.
llvmpipe has a few special rasterization paths for triangles contained in
16x16 blocks, but it allows the 16x16 block to be aligned only to a 4x4
grid.
Some 16x16 blocks could actually intersect the tile
if the triangle is 16 pixels in one dimension but 4 in the other, causing
a buffer overflow.
The fix consists of budging the 16x16 blocks back inside the tile.
|