| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
It seems line loop stipple in hardware needs something I don't know, it might
need a proper geometry shader who knows.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
>= 0x0301
LLVM change r143502
Signed-off-by: José Fonseca <[email protected]>
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
Signed-off-by: Alex Deucher <[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]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
This reverts commit c15f8569fddac5f8aee77863922fd5bb992cfe8a.
This breaks r6xx.
|
|
|
|
|
|
| |
This reverts commit 9804cf3118ae7249098af2a9c78b36f4fb576ee4.
This breaks r6xx.
|
|
|
|
|
|
|
|
| |
If the VS has outputs that aren't consumed by the FS we were mapping
them all to one unused VS output index, but that's illegal. Instead,
map unused VS outputs to unique indexes.
Reviewed-by: José Fonseca <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
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]>
|