| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
v2: Move {RED,RG,RGB,RGBA}_SNORM changes from the previous commit to
this commit. Based on suggestions from Ken.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OpenGL 3.2 core profile spec says:
"The following base internal formats from table 3.11 are
color-renderable: RED, RG, RGB, and RGBA. The sized internal formats
from table 3.12 that have a color-renderable base internal format
are also color-renderable. No other formats, including compressed
internal formats, are color-renderable."
The OpenGL 3.2 compatibility profile spec says (only ALPHA is added):
"The following base internal formats from table 3.16 are
color-renderable: ALPHA, RED, RG, RGB, and RGBA. The sized internal formats
from table 3.17 that have a color-renderable base internal format
are also color-renderable. No other formats, including compressed
internal formats, are color-renderable."
Table 3.12 in the core profile spec and table 3.17 in the compatibility
profile spec list SNORM formats as having a base internal format of RED,
RG, RGB, or RGBA. From this we infer that they should also be color
renderable.
The OpenGL ES 3.0 spec says:
"An internal format is color-renderable if it is one of the formats
from table 3.12 noted as color-renderable or if it is unsized format
RGBA or RGB. No other formats, including compressed internal
formats, are color-renderable."
In the OpenGL ES 3.0 spec, none of the SNORM formats have "color-
renderable" marked in table 3.12. The RGB I and UI formats also are not
color-renderable in ES3, but we'll save that change for another patch.
Both NVIDIA's closed-source driver (version 304.64) and AMD's
closed-source driver (Catalyst 12.6 on HD 3650) reject *all* SNORM
formats for renderbuffers in OpenGL 3.3 compatibility profiles.
v2: Move {RED,RG,RGB,RGBA}_SNORM changes from the this commit to the
next commit. Based on suggestions from Ken.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes piglit glx-dont-care-mask test.
Note: This is a candidate for the stable branches.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes intel_miptree_unmap_etc() (which decompresses ETC
textures to linear) to pay attention to map->x and map->y when writing
to the destination image. Previously these values were ignored,
causing the xoffset and yoffset parameters passed to
glCompressedTexSubImage2D() to be ignored.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
- We should use a 3D transfer of size Width x 1 x NumLayers.
- We should use layer_stride instead of stride.
(even though they are likely to be equal with 1D array textures)
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
This uses a 3D blit to decompress the texture and then a 3D transfer
to read it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was the fast path based on _mesa_format_matches_format_and_type
for GetTexImage, but it never worked, because the Mesa format we were testing
there was always compressed. Further testing showed that the fast path
had been completely broken.
In this commit, the somewhat limited helper util_create_rgba_texture is
no longer used and instead, custom code for the texture creation is added,
which tries to find the best matching RGBA8 format, so that we can hit
the fast path *always* if the read format is a variant of RGBA8 and supported
by the driver.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
I'll deal with 2D arrays later.
NOTE: This is a candidate for the stable branches.
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usage with pipe_context:
pipe->flush(pipe, NULL, PIPE_FLUSH_END_OF_FRAME);
Usage with st_context_iface:
st->flush(st, ST_FLUSH_END_OF_FRAME, NULL);
The flag is only a hint for drivers. Radeon will use it for buffer eviction
heuristics in the kernel (e.g. for queries like how many frames have passed
since a buffer was used).
The flag is currently only generated by st/dri on SwapBuffers.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every generation except Gen7 creates SURFACE_STATE entries via a
uint32_t array. Only Gen7 uses the older bitfield structure, which we
moved away from because it was less efficient. Convert it for
consistency.
This reduces the compiled size of gen7_wm_surface_state.o by 2.86% in a
release build.
v2: Fix accidental use of BRW_SURFACE_WIDTH/HEIGHT in brw_state_dump.c;
switch back to gen7_set_surface_mcs_info setting surf[6] directly
(both per Eric's review comments).
Acked-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57842
|
|
|
|
|
|
|
|
| |
Fixes missing break in switch defect reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Commit f22d49de added the SamplerParamter* functions but only used
ASSERT_OUTSIDE_BEGIN_END inside the -f and -fv versions.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds functionality to Mesa to upload compressed
2-dimensional array textures, using the glCompressedTexImage3D and
glCompressedTexSubImage3D calls.
Fixes piglit tests "EXT_texture_array/compressed *" and "!OpenGL ES
3.0/ext_texture_array-compressed_gles3 *". Also partially fixes GLES3
conformance test "CoverageES30.test".
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The old error reporting was completely bogus, passing _mesa_error() a
format string that didn't even match the remaining arguments. Also,
in many cases the number of dimensions in the TexImage call was not
preserved in the error message (e.g. an error in glTexImage2D was
reported simply as an error in glTexImage).
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
| |
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=58844
|
| |
|
|
|
|
|
|
|
|
|
| |
If the call fails, we should return NULL from XMesaCreateVisual().
This was found when Waffle tried to create a visual with depth/stencil
bits = -1. That's an illegal value for glXChooseFBConfig() and we should
return NULL in that situation.
Note: This is a candidate for the stable branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dungeon Defenders hits TexImage()'s try_pbo_upload() path where
image->Width == 2, which doesn't meet intelEmitCopyBlit's requirement
that the pitch needs to be a multiple of 4.
Since intelEmitCopyBlit can already fail for a myriad of other reasons,
and it's not clear that other callers are immune to this failure mode,
simply make it return false rather than assert.
Fixes Dungeon Defenders on i965/Ivybridge. Now playable (aside from
having to work around the EXT_bindable_uniform issue).
NOTE: This is probably a candidate for the 9.0 branch.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
| |
Improves GLBenchmark 2.1 offscreen performance by 3.2% +/- 1.5% (n=52).
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
We don't need them now that our set of parameter pointers points at the
GL core storage for them. This should save memory/bandwidth/overhead in
uniform updates.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
NumParameters used to be an upper bound on the number of vec4s to be
uploaded, which was basically safe (unless your buffer was bound near
the top of address space *and* you array indexed outside the buffer, in
which case I think you might GPU hang). As I migrate the driver away
from ParameterValues[], this is no longer true.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Like in the FS, there's no reason to use an external copy if the
ParameterValues[] relayout of it isn't the layout we need.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
There's no reason to use an external copy if the relayout in the
external copy isn't serving us.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Now that ParameterValues doesn't change across the visitor, we don't
need to go through this.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Things are even more restrictive than they used to be, so I've made
mistakes in this area.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If adding scale parameters during program compile caused a realloc of
ParameterValues, then the driver uniform storage set up by
_mesa_associate_uniform_storage() would point to potentially freed
memory.
Note that this uses TexturesUsed, which may change at runtime for GLSL
when sampler uniforms change. This is a flaw in our handling of texrect
in general, and not one I'm fixing currently.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=58548
|
|
|
|
|
|
|
|
|
|
| |
We don't have native hardware support for these, so they get promoted to
RGBA, in which case we don't have hardware dealing with the channel
swizzling for us.
Fixes piglit EXT_texture_snorm/texwrap formats bordercolor (-swizzled).
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
I had left this out for a long time because it regressed some
depthstencil-render-miplevels cases when it was enabled. Now that the
bugs causing those are fixed, there's nothing stopping us.
Improves glbenchmark 2.1 offscreen performance by 7.3% +/- 2.8% (n=10).
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This worked out before because the parent was always 4 bytes so it
didn't affect the layout, but now we want to support Z16 too.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixing these rendering bugs has been implicated in performance
regressions (which may be unfixable), but at least knowing that it's
happening should help diagnose those regressions.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
The ETC1 changes failed at this, so let's make sure it will be caught in
testing next time.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This was caught by the assertion in the next commit. It fixes the
remaining piglit depthstencil-render-miplevels cases, probably by
avoiding broken stencil copies in the validation path.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When comparing to the teximage's format, we have to look at the
format-the-mt-was-created-for not the format-actually-stored-in-the-mt.
Improves glbenchmark 2.1 offscreen test performance 159% +/- 17% (n=3).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54582
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Relayout is expensive, so it's something developers (both us and others)
should know about when it happens.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
Fixes all the remaining non-Z32F_S8 depthstencil-render-miplevels tests
in piglit.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename existing _Used flag to EverBound.
The GL 4.3 and ES 3.0 specs say
These names are marked as used, for the purposes of GenVertexArrays
only, but they do not acquire array state until they are first bound.
This also affects Apple VAOs, which is fine since the
APPLE_vertex_array_object spec says
A vertex array object is created by binding an unused name. This
binding is accomplished by calling BindVertexArrayAPPLE with id set
to the name of the new vertex array object.
Fixes arb_vertex_array_object_isvertexarray.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GL 4.3 an ES 3.0 specs say
A transform feedback object is created by binding a name returned by
GenTransformFeedbacks with the command
void BindTransformFeedback( enum target, uint id );
Fixes arb_transform_feedback2-istransformfeedback and part of
es3conform's CoverageES30.test.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No piglit regressions and now passes glsl-uniform-out-of-bounds-2.
validate_uniform_parameters now checks that the array index is
valid. This means if an index is out of bounds, glGetUniform* now
fails with GL_INVALID_OPERATION, as it should.
_mesa_uniform and _mesa_uniform_matrix also call
validate_uniform_parameters so the bounds checks there became
redundant and were removed.
The test in glGetUniformLocation is modified to check array bounds
so it now returns GL_INVALID_INDEX (-1) if you ask for the location
of a non-existent array element, as it should.
Signed-off-by: Frank Henigman <[email protected]>
Reviewed-by: Stéphane Marchesin <[email protected]>
|