| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Acked-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Acked-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
This fixes piglit/depth-level-clamp.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
| |
The only case a depth buffer can be set as a color buffer is when flushing.
That wasn't always the case, but now this code isn't required anymore.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
A flush depth texture is never set as a depth buffer and never flushed.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
This was missing/broken. There are also minor code cleanups.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
| |
- maintain a mask of which mipmap levels are dirty (instead of one big flag)
- only flush what was requested at a given point and not the whole resource
(most often only one level and one layer has to be flushed)
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
| |
we can just update the state when decompressing, there's no need to add
additional info into the DSA state
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
this will be useful for in-place DB decompression, otherwise should be harmless
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
to remove some overhead from draw_vbo. This is a derived state.
BTW, I've got no idea how compute interacts with 3D here, but it should
use cb_misc_state, so that 3D and compute don't conflict.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
the structure is calloc'd.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
just rename it to util_blit_pixels
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Because u_blit couldn't sample a 1D, 3D, CUBE and ARRAY texture, we created
a 2D texture holding a copy of one slice of the source texture (even for 1D).
Let's just do it right.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
This doesn't seem to be used by anything yet, but better safe than sorry.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
This fixes stencil buffer write transfers on r600g.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
used for stencil sampler views.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
| |
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the blorp engine to properly handle the case where
the surface being textured from uses Gen7's CMS MSAA layout. The
following changes were necessary:
- Before reading color values from the surface, we need to read from
the MCS buffer using the ld_mcs sampler message. This is done by
the mcs_fetch() function, and the result is stored in the mcs_data
register. This only needs to be done once per pixel, since the MCS
value is shared between all samples belonging to a pixel.
- When reading color values from the surface, we need to use the
ld2dms sampler message instead of the ld2dss message, and we need to
provide the value read from the MCS buffer as an argument.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
When a buffer using Gen7's CMS MSAA layout is bound to a texture or a
render target, the SURFACE_STATE structure needs to point to the MCS
buffer and to indicate its pitch. This patch updates the functions
that emit SURFACE_STATE to handle CMS layout properly.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
| |
Previously the DWORD used to control the CMS MSAA layout was just a
pad value, because we didn't use it.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
To implement Gen7's CMS MSAA layout, we need an extra buffer, the MCS
(Multisample Control Surface) buffer. This patch introduces code for
allocating and deallocating the buffer, and storing a pointer to it in
the intel_mipmap_tree struct.
No functional change, since the CMS layout is not enabled yet.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the Ivy Bridge PRM, Vol 1 Part 1, p112:
There are three types of multisampled surface layouts designated
as follows:
- IMS Interleaved Multisampled Surface
- CMS Compressed Mulitsampled Surface
- UMS Uncompressed Multisampled Surface
Previously, the i965 driver only used IMS and UMS formats, and
distinguished beetween them using the boolean
intel_mipmap_tree::msaa_is_interleaved. To facilitate adding support
for the CMS format, this patch replaces that boolean (and other
booleans derived from it) with an enum
INTEL_MSAA_LAYOUT_{IMS,CMS,UMS}. It also updates the terminology used
in comments throughout the driver to match the IMS/CMS/UMS terminology
used in the PRM. CMS layout is not yet used.
The enum has a fourth possible value, INTEL_MSAA_LAYOUT_NONE, which is
used for non-multisampled surfaces.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Gen6, MSAA buffers always use an interleaved layout and non-MSAA
buffers always use a non-interleaved layout, so it is not strictly
necessary to keep track of the layout of the texture and render target
surfaces in the blorp program key. However, it is cleaner to do so,
since (a) it makes the blorp compiler less dependent on implicit
knowledge about how the GPU pipeline is configured, and (b) it paves
the way for implementing compressed multisampled surfaces in Gen7.
This patch won't cause any redundant compiles, because the layout of
the texture and render target surfaces depends on other parameters
that are already in the blorp program key.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't generate public entrypoints for GLES extensions, so move the
GL_NV_draw_buffers definition from ARB_draw_buffers.xml to es_EXT.xml.
When the extension is defined in ARB_draw_buffers.xml, we end up with a
public entry point for it, but no prototype, which gives an error when
compiled with --disable-asm and --disable-shared-glapi.
Instead, just move the GLES extension to es_EXT.xml so this doesn't happen.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
| |
This lets us specify the plane to create the image for for multiplanar
wl_buffers.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
| |
|
|
|
|
|
| |
We're going to extend this to support multi-plane buffers, so pass this
to the driver so it can access the details.
|
|
|
|
|
|
|
| |
We use the new miptree offset to pick out the sub-image when we bind
the EGLImage to a texture.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
| |
This lets us specify an offset into the bo where the miptree starts,
which will let us set up a texture for a single plane in a planar buffer.
Signed-off-by: Kristian Høgsberg <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The additions in version 5 enables creating EGLImages for different planes
of a YUV buffer. createImageFromName is still used to create the containing
__DRIimage, and createSubImage can then be used no that __DRIimage to create
__DRIimages that correspond to the y, u, and v planes (__DRI_IMAGE_FORMAT_R8)
or the uv planes (__DRI_IMAGE_FORMAT_RG88) for formats such as NV12 where
the u and v components are interleaved. Packed formats such as YUYV etc
doesn't require any special treatment, we just sample those as a regular
ARGB texture.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code for growing the memory pool (which is used for storing all of
the global buffers) wasn't working. There seem to be two separate issues
with the memory pool code. The first was the way it was growing the pool.
When the memory pool needed more space, it would:
1. Copy the data from the memory pool's backing texture to system memory.
2. Delete the memory pool's texture
3. Create a bigger backing texture for the memory pool.
4. Copy the data from system memory into the bigger texture.
The copy operations didn't seem to be working, and I suspect that since
they were using fragment shaders to do the copy, that there might have
been a problem with the mixing of compute and 3D state.
The other issue is that the size of 1D textures is limited, and I was
having trouble getting 2D textures to work.
I think these problems will be easier to solve once more code is shared
between 3D and compute, which is why I decided to disable it for now
rather than continue searching for a fix.
|
|
|
|
|
|
|
| |
The original strategy for handling floating point loads, which was to
lower (f32 load) to (f32 bitcast (i32 load)) wasn't really working. The
main problem was that the DAG legalizer couldn't handle replacing a node
with two results (load) with a node with only one result (bitcast).
|
|
|
|
| |
The IMM bit is already being set in SICodeEmitter.
|
| |
|
|
|
|
|
|
|
|
| |
It didn't change performance on Lightsmark or Nexuiz, which both used
DYNAMIC_DRAW buffers, but it was killing performance (40% CPU wasted pwriting
buffers) on a closed-source app we're looking at.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the infrastructure required for this extension. There is no
xserver support and no driver support yet. Drivers can enable this be
advertising DRI2 version 4 and accepting the
__DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS flag and the
__DRI_CTX_ATTRIB_RESET_STRATEGY attribute in create context.
Some additional Mesa infrastructure is needed before drivers can do
this. The GL_ARB_robustness spec, which all Mesa drivers already
advertise, requires:
"If the behavior is LOSE_CONTEXT_ON_RESET_ARB, a graphics reset
will result in the loss of all context state, requiring the
recreation of all associated objects."
It is necessary to land this infrastructure now so that the related
infrastructure can land in the xserver. The xserver has very long
release schedules, and the remaining Mesa parts should land long, long
before the next xserver merge window opens.
v2: Expose robustness as a DRI2 extension rather than bumping
__DRI_DRI2_VERSION.
v3: Add a comment explaining why dri2->base.version >= 3 is also
required for GLX_ARB_create_context_robustness.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
This allows revising the dri_interface.h separately from adding driver
support.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We neglected to list the deprecation model/forward compatible context
support.
inverse() has been done for a while.
None of us know what "highp change" means; GLSL 1.30 already added the
ability to recognize precision keywords, and it doesn't look like 1.40
has any new requirements there (precision keywords still have no meaning).
Signed-off-by: Kenneth Graunke <[email protected]>
|