| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
The code expects the geometry shader to be NULL.
We don't have geometry shaders now, but it's good to be prepared.
v2: check for support in the cso context
|
|
|
|
|
| |
st_translate_program's data was taking 51K off the stack, causing stack
overflow on Windows.
|
|
|
|
| |
To smooth minor diff between dri_util & drisw_util
|
| |
|
| |
|
| |
|
|
|
|
| |
This is to reorder as screen/context/drawable similar to drisw_util
|
| |
|
|
|
|
| |
__driUtilMessage seems to have fallen out of favor and is only used by xmlconfig.c now
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also drop DriverAPI field, this is a static symbol and I don't see why it
should be accessed through __DRIscreenRec
|
|
|
|
| |
I dropped the comments because they don't add much.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SPI semantic indices for PS/VS are now static, so we don't
need to update spi config for every shaders combination. We can move
the functionality of r600_spi_update to r600(evergreen)_pipe_shader_ps.
Flatshade state is now controlled by the global FLAT_SHADE_ENA flag
instead of updating FLAT_SHADE for all inputs.
Sprite coord still requires the update of spi setup when
sprite_coord_enable is first changed from zero (enabled), and then
only when it's changed to other non-zero value (enabled for other input).
Change to zero (disabling) and back to the same value is handled via
global SPRITE_COORD_ENA.
New field "sprite_coord_enable" added to "struct r600_pipe_shader"
to track current state for the pixel shader. It's checked in the
r600_update_derived_state.
Signed-off-by: Vadim Girlin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
There is no need to duplicate semantic mapping which is done in hw, so get
rid of r600_find_vs_semantic_index.
TGSI name/sid pair is mapped to the 8-bit semantic index for SPI.
Signed-off-by: Vadim Girlin <[email protected]>
|
|
|
|
| |
Untested. But should fix fdo 42576.
|
|
|
|
| |
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This is needed to do proper renderbuffer operation on mipmaps.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This just uses the base class copies.
Signed-off-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
| |
An error with MSVC.
|
|
|
|
|
|
|
| |
The readpixels microbenchmark in mesa-demos goes from 47Mpix/sec at
1000x1000 to 450Mpix/sec. The 10x10 sizes stay about the same.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
Renderbuffer mapping handles flushing the batchbuffer if required, so
all we need to do is make sure any pending rendering has reached the
batchbuffer.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
There doesn't appear to be any particular reason for this -- it's not
like the width is changing between the deref and the use.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
In all of piglit, only two tests hit it (reading to RGBA float, where
GetRow would drop floats into place from R, RG, or RGB). Mostly this
is because _ColorReadClamp has been causing transferOps to always be
set, skipping any fast-paths anyway.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
All the code using it is converted to MapRenderbuffer and the core
unpack functions.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This may be a bit slower than before because we're switching from
per-format compiled loops in GetRow to
_mesa_unpack_rgba_block_unpack's loop around a callback to unpack a
pixel. The solution there would be to make _mesa_unpack_rgba_block
fold the span loop into the format handlers.
(On the other hand, function call overhead will hardly matter if
MapRenderbuffer means the driver gets the data into cacheable memory
instead of uncached).
The adjust_colors code should no longer be required, since the unpack
function does the 565 to float conversion in a single pass instead of
converting it (poorly) through 8888 as apparently happened in the
past.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
None of the callgraph below this uses derived state (almost nothing
even dereferences the swrast context).
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
v2: Move _mesa_get_format_bytes out of the loop.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This should be useful in making more generic fast paths in the pixel
paths.
v2: Add note about PACK_SWAP_BYTES, and fix up for endianness by
synchronizing with memcpy_texture paths in texstore.c.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
This avoids the wrapper, which should improve performance on packed
depth/stencil drivers.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces two new span helper functions we'll want to use in
several places as we move to MapRenderbuffer, which pull out integer
depth and stencil values from a renderbuffer mapping based on the
renderbuffer format.
v2: Use format_unpack helper for stencil read.
v3: Clean up comment after conversion to format_unpack.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
The fast and slow paths were doing these separately before.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This also makes it handle 24/8 vs 8/24, fixing piglit
depthstencil-default_fb-readpixels-24_8 on i965. While here, avoid
incorrectly fast-pathing if packing->SwapBytes is set.
v2: Move the unpack code to format_unpack.c, fix BUFFER_DEPTH typo
v3: Fix signed/unsigned comparison.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids going through the wrapper that has to rewrite the data for
packed depth/stencil. This isn't done in _swrast_read_stencil_span
because we don't want to map/unmap for each span.
v2: Move the unpack code to format_unpack.c.
v3: Fix signed/unsigned comparison.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Fixes Coverity uninitialized scalar variable defect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i965's MUL instruction can't take an immediate value as its first
argument. So normally, if constant propagation wants to propagate a
constant into the first argument of a MUL instruction, it swaps the
order of the two arguments.
This doesn't work for 32-bit integer (and unsigned integer)
multiplies, because the MUL operation is asymmetric in that case (it
multiplies 16 bits of one operand by 32 bits of the other).
Fixes piglit tests {vs,fs}-multiply-const-{ivec4,uvec4}.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
If we're drawing sprites and the fragment shader needs both auto-
generated texcoords and user-defined varying vars we need to use
this fallback path.
The reason is when we enable auto texcoord generation, it gets
enabled for all texcoord sets. And that clobbers the user-defined
varying vars.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
If we use the draw-module for wide point/line/etc drawing we'll need
a fragment shader too (like we pass in the vertex shader).
This fixes sprite point rendering when forcing the swtnl path.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The state tracker may generate shaders that use generic vs outputs /
fs inputs like:
DCL IN[0], GENERIC[0]
DCL IN[1], GENERIC[10]
DCL IN[2], GENERIC[11]
This patch remaps 0, 10, 11 to small integers like 1, 2, 3 so that we
stay inside the SVGA3D limit (8).
The remapping is done to both the vertex shader outputs and the
fragment shader inputs. The same mapping must be used for a vs/fs
pair.
Note that 'union svga_compile_key' is now 'struct svga_compile_key'
because we needed to add the register remapping table. The change in
size isn't really significant though (it's not a search key).
Also, add assertions when building up SVGA3D src/dst registers to we
don't try to store too large of value for the bitfield size.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Instead of just segfaulting. Recently ran into this.
|
|
|
|
|
|
|
|
|
|
| |
Missed this back in the arb_robustness branch
<6b329b9274b18c50f4177eef7ee087d50ebc1525>.
NOTE: This is a candidate for the 7.11 branch.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|