| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This patch modifies intel_region_get_aligned_offset() to make the
appropriate calculation when the blorp engine sets up a W-tiled
stencil buffer using a Y-tiled SURFACE_STATE.
NOTE: This is a candidate for stable release branches.
Acked-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When the blorp engine is performing a blit from one stencil buffer to
another, it sets up the surface state for these buffers as Y-tiled, so
it needs to be able to force intel_region_get_tile_masks() to return
the appropriate masks for a Y-tiled region.
NOTE: This is a candidate for stable release branches.
Acked-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes piglit tests "framebuffer-blit-levels {read,draw} depth".
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when performing a blit using the blorp engine, we failed
to account for the level and layer of the source and destination. As
a result, all blits would occur between miplevel 0 and layer 0 of the
corresponding textures, regardless of which level/layer was bound to
the framebuffer.
This patch passes the correct level and layer through
brw_blorp_miptrees() into the brw_blorp_blit_params data structure.
Further patches in the series will adapt
gen{6,7}_blorp_emit_surface_state to make use of these parameters.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
This is unnecessary--the image offsets can be read directly out of the
miptree using intel_miptree_get_image_offset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, gen{6,7}_blorp_emit_surface_state assumes that the src and
dst surfaces are mapped to miplevel 0 and layer 0 (thus no surface
offset is required). This is a bug, since the user might try to blit
to and from levels/layers other than 0.
To fix this bug, it will not be sufficient to have
gen6_{6,7}_blorp_emit_surface_state look up the surface offset at the
time they set up the surface state, since these offsets will need to
be tweaked when blitting stencil buffers (due to the fact that stencil
buffer blits have to swizzle between W and Y tiling formats).
So, to pave the way for the bug fix, this patch causes the x and y
offsets to be computed during blit setup and stored in
brw_blorp_mip_info.
As a result of this change, brw_blorp_mip_info doesn't need to store
the level and layer anymore.
For consistency, this patch makes a similar change to the handling of
depth buffers when doing HiZ operations.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, gen{6,7}_blorp_emit_surface_state would look up the width
and height of the surface at the time they set up the surface state,
and then tweak it if necessary (it's necessary when a W-tiled surface
is being mapped as Y-tiled). With this patch, we look up the width
and height when setting up the blit, and store them in
brw_blorp_mip_info. This allows us to do the necessary tweak in the
brw_blorp_blit_params constructor (where it makes more sense). It
also reduces the need to keep track of level and layer in
brw_blorp_mip_info, so that a future patch can eliminate them
entirely.
For consistency, this patch makes a similar change to the handling of
depth buffers when doing HiZ operations.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This makes it more convenient for blorp functions to get access to
Intel-specific data inside the renderbuffer objects.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Also add a clarifying comment for why the width/height doesn't need
adjustment for Gen7.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Gen6+ stencil buffers use W-tiling (a tiling arrangement which
drm and the kernel are not aware of) we need to round up the width and
height of a stencil buffer to multiples of the W-tile size (64x64)
before allocating a stencil buffer. Previously, we rounded up the
size of the base miplevel, and then computed the miptree layout based
on the rounded up size. This was incorrect, because it meant that the
total size of the miptree would not be properly W-tile aligned, and
therefore we would not always allocate enough pages.
(Note: even though the GL API doesn't allow creation of mipmapped
stencil textures, it does allow mipmapping of a combined depth/stencil
texture, and on Gen6+, a combined depth/stencil texture is internally
implemented as a pair of separate depth and stencil buffers.)
For example, on Sandy Bridge, when allocating a mipmapped stencil
texture of size 128x128, we would first round up to the nearest
multiple of 64x64 (causing no change to the size), and then compute
the miptree layout (whose size worked out to 128x196). Then we would
request an allocation of 128*196 bytes (6.125 pages), causing 7 pages
to be allocated to the texture. However, the texture needs 8 pages,
since each W-tile occupies a page, and it takes 2 W-tiles to cover a
width of 128 and 4 W-tiles to cover a height of 196.
This patch changes the order of operations so that the miptree layout
is computed first and then the total size of the miptree is rounded up
to be W-tile aligned.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
No files provided by glproto or dri2proto are needed for building
something with Mesa.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=342393
Reviewed-by: Dan Nicholson <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Fixes piglit shaders/glsl-fs-uniform-sampler-array and many other similar
tests.
In fact, I just completed a piglit quick-driver.tests run without any GPU
lockups or even VM protection faults. Yay!
Signed-off-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The value was too small by 1 in some cases (non-first of several vertex
elements interleaved in a single buffer).
Fixes intermittent incorrect geometry in many apps, e.g. piglit
spec/EXT_texture_snorm/fbo-generatemipmap-formats.
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
|
| |
These enums are valid only in ES1 and ES2. So far they were marked valid
incorrectly, depending on the previous API mask in the enum list.
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
No functional change.
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
No functional change.
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
No functional change.
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is basically a follow-on to 1f5b1f98468d5e80be39e619ed15c422fbede8d3.
Basically, generate GL errors for ordinary invalid parameters for proxy
targets the same as for non-proxy targets. Only texture size and OOM
errors should be handled specially for proxies.
Note: This is a candidate for the stable branches.
|
|
|
|
|
|
| |
Needed for the next patch.
Note: This is a candidate for the stable branches.
|
|
|
|
|
|
|
|
| |
Turns out we weren't doing any format checking before. Now check
the internal format and, in particular, make sure that unsized internal
formats aren't accepted.
Note: This is a candidate for the stable branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the GL 4.3 spec, section 18.3.1 "Blitting Pixel Rectangles":
If SAMPLE_BUFFERS for either the read framebuffer or draw
framebuffer is greater than zero, no copy is performed and an
INVALID_OPERATION error is generated if the dimensions of the
source and destination rectangles provided to BlitFramebuffer are
not identical, or if the formats of the read and draw framebuffers
are not identical.
It is not clear from the spec whether "dimensions" should mean both
sign and magnitude, or just magnitude.
Previously, Mesa interpreted "dimensions" as meaning both sign and
magnitude, so any multisampled blit that attempted to flip the image
in the X and/or Y direction would fail.
However, Y flips are likely to be commonplace in OpenGL applications
that have been ported from DirectX applications, as a result of the
fact that DirectX and OpenGL differ in their orientation of the Y
axis. Furthermore, at least one commercial driver (nVidia) permits Y
filps, and L4D2 relies on them being permitted. So it seems prudent
for Mesa to permit them.
This patch changes Mesa to allow both X and Y flips, since there is no
language in the spec to indicate that X and Y flips should be treated
differently.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
| |
v2:
- Don't increment ninterp or set any of the have_* flags for
TGSI_SEMANTIC_POSITION
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
The compiler needs to know which interpolation modes are enabled, so
it knows which values will be preloaded into the VGPRs.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
At least one interpolation mode must be enable, but the code that checks
this was not checking for perspective center.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
| |
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
This allows the program to specify the type of shader being compiled
(e.g. PXEL, VERTEX, etc.)
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Previous command stream might have set any of the constant buffer
and the previous address might no longer be valid thus GPU might
preload constant from random invalid address and possibly triggering
lockup.
Signed-off-by: Jerome Glisse <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
* Handle arbitrary border colours.
* Use correct packing format for detecting special border colours.
Fixes piglit tex-border-1 and probably many other tests using border colours.
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
| |
The comment was cut-and-pasted from propagate_constants(), and had no
relation at all to opt_algebraic().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the GLSL 4.30 specification, this is a compile time error.
Earlier specifications don't specify a behavior, but since 0 and 1 are
the only valid indices for dual source blending, it makes sense to
generate the error.
Fixes (the fixed version of) piglit's layout-12.frag.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
| |
Now that branch 9.0 is created, bump the minor version in
master.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
VERSION_NUMBER is not required anymore. So it will be removed.
Reviewed-by: Adam Jackson <[email protected]>
|
| |
|
|
|
|
|
|
| |
Fixes piglit spec/ARB_texture_float/fbo-generatemipmap-formats.
Signed-off-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
Fixes piglit spec/EXT_texture_snorm/fbo-generatemipmap-formats (except for
what seems like a random fluke).
Signed-off-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
| |
This fixes the blue zombies bug in l4d2.
NOTE: This is a candidate for the 9.0 branch.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Saves 96MB of wasted memory in the l4d2 demo.
v2: Rebase on compare func change, change brace style.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Saves 26.5MB of wasted memory allocation in the l4d2 demo.
v2: Rebase on compare func change, fix comments.
Reviewed-by: Ian Romanick <[email protected]> (v1)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, this just avoids comparing all unused parts of param[] and
pull_param[], but it's a step toward getting rid of those giant statically
sized arrays.
v2: Actually use the new function instead of just looking at its
address. This required changing the args to const pointers.
(review by Kenneth)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
We don't fully process the builtin uniforms, but at least
num_uniform_components reflects reality now.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Fixes exponential fog. The pixel shaders for linear fog seem to get
miscompiled still somehow.
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Tom Stellard <[email protected]>
|