Age | Commit message (Collapse) | Author |
|
|
|
|
|
Added a conditional to spi_update per Dave's comment.
|
|
|
|
I can't see a performance difference with this code, which means all
the driver-specific code removed in this commit was unnecessary.
Now we use u_upload_mgr in a slightly different way than we did before it got
dropped. I am not restoring the original code "as is" due to latest
u_upload_mgr changes that r300g performance benefits from.
This also fixes:
- piglit/fp-kil
|
|
|
|
|
|
User buffers may be the fastest way to upload data.
|
|
|
|
|
|
Don't use height for 1D array textures or depth for 2D array textures.
|
|
|
|
|
|
|
|
|
|
|
|
Also cleanup the whole thing.
|
|
|
|
|
|
|
|
So that 'foo' can be found in: OPTION=prefixfoosuffix,foo
Also allow that debug options can be separated by a non-alphanumeric characters
instead of just commas.
|
|
This drops the memblock manager for ZMASK. Instead, only one zbuffer can be
compressed at a time. Note that this does not necessarily have to be slower.
When there is a large number of zbuffers, compression might be used more often
than it was before. It's also easier to debug.
How it works:
1) 'clear' turns the compression on.
2) If some other zbuffer is set or the currently-bound zbuffer is used
for texturing, the driver decompresses it and then turns the compression off.
Notes:
- The ZMASK clear has been refactored, so that only one packet3 is used to clear
ZMASK.
- The 8x8 compression mode is disabled. I couldn't make it work without issues.
- Also removed driver-specific stuff from u_blitter.
Driver status:
- RV530 and R580 appear to just work (finally).
- RV570 should work, but there may be an issue that we don't correctly
calculate the number of dwords to clear, resulting in a partially
uninitialized zbuffer.
- RS690 misrenders as if no ZMASK clear happened. No idea what's going on.
- RV350 may even hardlock. This issue was already present and this patch doesn't
fix it.
I think we are still missing some hardware info we need to make the zbuffer
compression work fully.
Note that there is also an issue with HiZ, resulting in a sort of blocky
zigzagged corruption around some objects.
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=33555
|
|
We try to load a DRI driver if this fails so don't confuse users.
|
|
Let's assume there are two options with names such that one is a substring
of another. Previously, if we only specified the longer one as a debug option,
the shorter one would be considered specified as well (because of strstr).
This commit fixes it by checking that each option is surrounded by commas.
(a regexp would be nicer, but this is not a performance critical code)
|
|
as specified in the arb_occlusion_query2. just the interface.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
==5547== Conditional jump or move depends on uninitialised value(s)
==5547== at 0x8FE745D: r600_drm_winsys_create (r600_drm.c:86)
|
|
If we invert Y, need to subtract one from the surface height.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=26795
for softpipe.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
|
|
The module uses the 3D engine, so it can blit non-compatible formats.
|
|
|
|
Fixes nvc0 SCons build.
|
|
|
|
|
|
Before, we were just casting between 32-bit VGHandles and 64-bit pointers.
|
|
|
|
Per the spec, all OpenVG handles are 32-bit. We can't just cast them
to/from integers on 64-bit systems.
Start fixing that mess by introducing a set of handle/pointer conversion
functions in handle.h. The next step is to implement a handle/pointer
hash table...
|
|
|
|
|
|
|
|
FLT_TO_INT is a vector instruction, despite what the (current) documentation
says. FLT_TO_INT_FLOOR and FLT_TO_INT_RPI aren't explicitly mentioned in the
documentation, but those are vector instructions too.
|
|
|
|
largely a merge of the previously discussed origin/gallium-resource-sampling
but updated.
the idea is to allow arbitrary binding of resources, the way opencl, new gl
versions and dx10+ require, i.e.
DCL RES[0], 2D, FLOAT
LOAD DST[0], SRC[0], RES[0]
SAMPLE DST[0], SRC[0], RES[0], SAMP[0]
|
|
Contrary what the name may suggest, LLVM's opaque types are used for
recursive types -- types whose definition refers itself -- so opaque
types correspond to pre-declaring a structure in C. E.g.:
struct node;
struct link {
....
struct node *next;
};
struct node {
struct link link;
}
Void pointers are also disallowed by LLVM. So the suggested way of creating
what's commonly referred as "opaque pointers" is using byte pointer (i.e.,
uint8_t * ).
|