| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This will throw a compile warning if there's an unhandled CAP.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation behind this is to add some self-documentation in the code
about how each CAP can be used.
The idea is:
- enum pipe_cap is only valid in get_param
- enum pipe_capf is only valid in get_paramf
Which CAPs are floating-point have been determined based on how everybody
except svga implemented the functions. svga have been modified to match all
the other drivers.
Besides that, the floating-point CAPs are now prefixed with PIPE_CAPF_.
|
|
|
|
|
| |
Only i965g does not enable GLSL, but that driver has been unmaintained and
bitrotting for quite a while anyway.
|
| |
|
|
|
|
|
|
|
|
| |
And update r300g.
This is different from util_draw_max_index in how it obtains vertex elements
and that it doesn't have to call util_format_description due to additional
precomputed data in vertex elements.
|
| |
|
|
|
|
| |
It's not really useful to have non-zero there.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Corbin Simpson <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We weren't setting TEX_SEM_WAIT on instructions that read the value of a
TEX instruction and also wrote the same register as the TEX instruction.
This is the sequence we were miscompiling:
1: TEX temp[0], input[2].xy__, 2D[0]
...
16: src0.xyz = temp[22], src1.xyz = temp[0], src2.xyz = temp[19]
MAD temp[0].xyz, src0.xxx, src1.xyz, src2.xxx
https://bugs.freedesktop.org/show_bug.cgi?id=42090
|
| |
|
|
|
|
| |
This was dead code anyway.
|
|
|
|
|
|
|
|
|
| |
The DDX may allocate a buffer with a too small size.
Instead of failing, let's pretend everything's alright.
Such bugs should be fixed in the DDX, of course.
NOTE: This is a candidate for the stable branches.
|
|
|
|
|
|
|
| |
Scalar instruction that need to write to the xyz components of a
register must reserve the RGB instruction slot for a REPL_ALPHA
instruction. With this commit, the scheduler will attempt to free
the RGB slot by moving the write to the w component of a register.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
draw_elements_immediate"
This reverts commit 5506f6ef966b8883e575a3f60ce96ad42ee6ffd2.
It breaks more things than it fixes.
|
|
|
|
|
| |
The scheduler and the register allocator are now smart enough to handle
it.
|
|
|
|
|
|
|
|
|
|
|
| |
The texture semaphore allows for prefetching of texture data. On my
RV515, this increases the FPS of Lightsmark by 33% (This is with the
reg_rename pass enabled, which is enabled in the next commit).
There is a new env variable now called RADEON_TEX_GROUP, which allows
you to specify the maximum number of texture lookups to do at once.
The default is 8, but different values could produce better results
for various application / card combinations.
|
| |
|
| |
|
|
|
|
|
|
| |
We no longer emit full instructions immediately after they have been
merged. Instead merged instructions are added to the ready list and
the scheduler can commit them whenever it wants.
|
|
|
|
|
|
|
| |
This should fix a bug added by f5bfe54a.
Might also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=41715
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
| |
Unimplemented and not so useful for this driver.
|
|
|
|
| |
NOTE: This is a candidate for the stable branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Classic compiler mistake. In the example below, the OMOD optimization
was combining instructions 4 and 10, but since there was an instruction
(#8) in between them that wrote to the same registers as instruction 10,
instruction 11 was reading the wrong value.
Example of the mistake:
Before OMOD:
4: MAD temp[0].y, temp[3]._y__, const[0]._x__, const[0]._y__;
...
8: ADD temp[2].x, temp[1].x___, -temp[4].x___;
...
10: MUL temp[2].x, const[1].y___, temp[0].y___;
11: FRC temp[5].x, temp[2].x___;
After OMOD:
4: MAD temp[2].x / 8, temp[3]._y__, const[0]._x__, const[0]._y__;
...
8: ADD temp[2].x, temp[1].x___, -temp[4].x___;
...
11: FRC temp[5].x, temp[2].x___;
https://bugs.freedesktop.org/show_bug.cgi?id=41367
|
| |
|
|
|
|
| |
This function had not been updated to use conversion swizzles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Source swizzles for transcendent instructions were being stored in the X
channel regardless of what channel the instruction was writing.
This was causing problems for some helper functions that were expecting
source swizzles to occupy channels corresponding to the instruction's
writemask. This commit makes transcendent instructions follow the same
convention as normal instructions for representing source swizzles.
Previous behavior:
LG2 temp[0].y, input[0].x___;
Current behavior:
LG2 temp[0].y, input[0]._x__;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The drivers don't need to care about the domains. All they need to set
are the bind and usage flags. This simplifies the winsys too.
This also fixes on r600g:
- fbo-depth-GL_DEPTH_COMPONENT32F-copypixels
- fbo-depth-GL_DEPTH_COMPONENT16-copypixels
- fbo-depth-GL_DEPTH_COMPONENT24-copypixels
- fbo-depth-GL_DEPTH_COMPONENT32-copypixels
- fbo-depth-GL_DEPTH24_STENCIL8-copypixels
I can't explain it.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
It's part of pb_buffer already.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
Same issue as with conditional_render.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
We were checking whether render_condition is set. That was not reliable,
because it's always set with trace and noop regardless of driver support.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This removes:
- PIPE_CAP_MAX_TEXTURE_IMAGE_UNITS
- PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS
in favor of the that new per-shader cap.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All drivers support it (well, except Cell). The boolean option is going away
from core Mesa too.
This is a follow-up to Ian Romanick's patch
"mesa: Remove ARB_texture_mirrored_repeat extension enable flag".
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
EXT_texture_integer also specifies border color should be a color
union, the values are used according to the texture sampler format.
(update docs)
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
| |
It can now override both buffer offsets and strides in additions to resources.
Overriding buffer offsets was kinda hackish and could cause issues with
non-native vertex formats.
|
|
|
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=40062
https://bugs.freedesktop.org/show_bug.cgi?id=36939
Note: This is a candidate for the 7.11 branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the gallium interface for clears from using a pointer to 4 floats to a pointer to a union of float/unsigned/int values.
Notes:
1. the value is opaque.
2. only when the value is used should it be interpretered according to
the surface format it is going to be used with.
3. float clears on integer buffers and vice-versa are undefined.
v2: fixed up vega and graw, dropped hunks that shouldn't have been in
patch.
Signed-off-by: Dave Airlie <[email protected]>
|