The layersize calculation is slightly different on +evergreen.
This makes mpeg2 video decoding and piglits texture-packed-formats
test work correctly on this hardware.
As explained in the thread starting at [0], the internal include style
should be »#include "path/to/header.h"« for non-system includes.
[0]
<http://news.gmane.org/find-root.php?message_id=%3c4E5802BE.6020206%40vmware.com%3e>
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Signed-off-by: Brian Paul <brianp@vmware.com>
If the state tracker tries to map the resource directly but we can't or don't
want to do that, fail to create a transfer.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The state tracker expects depth and stencil pixels interleaved.
Evergreen can bind an interleaved depth-stencil resource as a colorbuffer,
but not as a zbuffer.
The hardware can do the interleaving for us when decompressing.
Such that it actually works in apps which use both.
A separate buffer is allocated for stencil. The only exception is
the window-system-provided depth-stencil buffer, where depth and stencil
share the same buffer.
This fixes:
- fbo-depthstencil-GL_DEPTH24_STENCIL8-clear
- fbo-depthstencil-GL_DEPTH24_STENCIL8-drawpixels-FLOAT-and-USHORT
- fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-24_8
- fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-FLOAT-and-USHORT
These happen to work because their values are the same as the equivalent
PIPE_TRANSFER_* flags, but it's still misleading.
Signed-off-by: Henri Verbeet <hverbeet@gmail.com>
evergreen+ stores depth and stencil separately so when we
allocate a depth/stencil fbo, make sure we allocate enough
memory for both depth and stencil buffers.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
The drivers have been changed so that they behave as if all of the flags
were set. This is already implicit in most hardware drivers and required
for multiple contexts.
Some state trackers were also abusing the PIPE_FLUSH_RENDER_CACHE flag
to decide whether flush_frontbuffer should be called.
New flag ST_FLUSH_FRONT has been added to st_api.h as a replacement.
If the drm minor version is > 9 (i.e. whats in drm-next),
we enable s3tc + texture tiling by default now.
this changes R600_FORCE_TILING to R600_TILING which can
be set to false to disable tiling on working drm.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds EXT_texture_array support to r600g, it passes the piglit
array-texture test but I suspect may not be complete.
It currently requires a kernel patch to fix the CS checker to allow
these, so you need to use R600_ARRAY_TEXTURE=true for now
to enable them.
Signed-off-by: Dave Airlie <airlied@redhat.com>
On r600, s3tc formats require a 1D tiled texture format,
so we have to do uploads using a blit, via the 64-bit and 128-bit formats
Based on the r600c code we use a 64 and 128-bit type to do the
blits.
Still requires R600_ENABLE_S3TC until the kernel fixes are in,
this has only been tested on evergreen where the kernel doesn't
yet get in the way.
the miptree setup and pitch storing didn't work so well for block
based things like compressed textures. The CB takes blocks, where
the texture sampler takes pixels, and transfers need bytes,
So now we store blocks/bytes and translate to pixels in the sampler.
This is necessary for s3tc to work properly.
add support for the 32-bit types, also fixup the
export setting to handle types with channels > 11 bits properly
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just adds a flag to create the texture without doing any
flushing to it. Flushing occurs in the draw function. This avoids
unnecessary flushes when we end up rebinding a CB/DB/texture due
to the blitter just restoring state.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Christian König
Kai Wasserbäch
Michel Dänzer
Marek Olšák
Henri Verbeet
Michel Dänzer
Alex Deucher
Dave Airlie