| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This state is needed for deciding whether or not to log
application messages with IDs that haven't been specifically
passed to glDebugMessageControlARB yet.
State for each individual ID number ever passed to
glDebugMessageControlARB (per-context) still needs to be added.
|
| |
|
|
|
|
|
| |
Controlling the output of client-provided messages
isn't done yet.
|
| |
|
| |
|
|
|
|
| |
Marek v2: don't add the extension to extensions.c yet
|
| |
|
|
|
|
| |
Also add _mesa_vsnprintf.
|
|
|
|
|
|
|
|
|
| |
Unfortunately, Unigine Heaven 3.0 still needs this.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several cases in which we need to explicity "rebase" colors
(ex: set G=B=0) when getting GL_LUMINANCE textures:
1. If the luminance texture is actually stored as rgba
2. If getting a luminance texture, but returning rgba
3. If getting an rgba texture, but returning luminance
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679
Also fixes the new piglit getteximage-luminance test.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
| |
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
See the comments for _mesa_rebase_rgba_float() for details.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=46679
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
These will be used by glReadPixels() and glGetTexImage() to fix issues
with reading GL_LUMINANCE and other formats.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
If the texture is a 1D array, don't remove the border pixel from the
height. Similarly for 2D array textures and the depth direction.
Simplify the function by assuming the border is always one pixel.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch add the support of gl_PointCoord gl builtin variable for
platform gen4 and gen5(ILK).
Unlike gen6+, we don't have a hardware support of gl_PointCoord, means
hardware will not calculate the interpolation coefficient for you.
Instead, you should handle it yourself in sf shader stage.
But badly, gl_PointCoord is a FS instead of VS builtin variable, thus
it's not included in c.vue_map generated in VS stage. Thus the current
code doesn't aware of this attribute. And to handle it correctly, we
need add it to c.vue_map manually to let SF shader generate the needed
interpolation coefficient for FS shader. SF stage has it's own copy of
vue_map, thus I think it's safe to do it manually.
Since handling gl_PointCoord for gen4 and gen5 platforms is somehow a
little special, I added a lot of comments and hope I didn't overdo it ;)
v2: add a /* _NEW_BUFFERS */ comment to note the state flag dependency
and also add the _NEW_BUFFERS dirty mask (Eric).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45975
Piglit: glsl-fs-pointcoord and fbo-gl_pointcoord
NOTE: This is a candidate for stable release branches.
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to do fallback when the 'Clipped Drawing Rectangle X/Y Max'
exceed the hardware's limit no matter the drawing rectangle offset
changed or not.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46665
NOTE: This is a candidate for stable release branches.
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's a GNU extension that isn't supported by clang right now:
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Nested-Functions.html
http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc
With this, clang now compiles the nouveau classic driver.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44061
(Types changed from e.g. 'unsigned char' to 'GLubyte' so that the types can
be concatenated to form a unique function name without any whitespace
interfering.)
[ Francisco Jerez: give meaningful names to the dispatch functions. ]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_mesa_max_texture_levels() is also used to test valid texture target
in _mesa_GetTexLevelParameteriv(). GL_TEXTURE_CUBE_MAP is not allowed
as texture target in glGetTexLevelParameter(). So, this should throw
GL_INVALID_ENUM error.
Few other functions which use _mesa_max_texture_levels() like
getcompressedteximage_error_check() and getteximage_error_check()
also don't accept GL_TEXTURE_CUBE_MAP.
Above fix makes piglit fbo-cubemap test to fail. This is because of
incorrect texture target passed to _mesa_max_texture_levels() in
framebuffer_texture(). Fixing that as well
Note: This is a candidate for the stable branches
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's even a comment in the code containing the right swizzling
computations!
Previously this has not been noticed because we need to manually
enabled swizzling on snb/ivb (kernel 3.4 will do that) and we
don't use the separate stencil on ilk (where the bios enables
swizzling). This fixes
piglit ./bin/fbo-stencil readpixels GL_DEPTH32F_STENCIL8 -auto
on recent drm-intel-next kernels.
Also remove the comment about ivb, it's stale now.
Swizzling detection is done by allocating a temporary x-tiled
buffer object. Unfortunately kernels before v3.2 lie on snb/ivb
because they claim that swizzling is enable, but it isn't. The
kernel commit that fixes this for backport to pre-v3.2 is
commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Author: Daniel Vetter <[email protected]>
Date: Mon Sep 12 20:49:16 2011 +0200
drm/i915: fix swizzling on gen6+
But if the kernel doesn't lie, this now works on swizzling and
not swizzling machines.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
That is when building with --disable-opengl.
Fix for commit cb045880b113b0042d8dfb7e4cdf76e6cc76c1d1.
CC: Paul Berry <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
That is when building with --disable-opengl.
Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
CC: Chad Versace <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current code would ignore the point size specified by gl_PointSize
builtin variable in vertex shader on Pineview. This patch servers as
fixing that.
This patch fixes the following issues on Pineview:
webglc: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/rendering/point-size.html
piglit: glsl-vs-point-size
NOTE: This is a candidate for stable release branches.
v2: pick Eric's nice tip for fixing this issue in hardware rendering.
v3: the last arg of EMIT_ATTR specify the size in _byte_. (Eric)
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may specify the point size in a glsl vertex shader.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46311
piglit: glsl-vs-point-size
NOTE: This is a candidate for stable release branches.
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This is a direct port of the i915 patch in
a856da63247a4b403f6350914f732e14d1530ed1.
Fixes glean's pbo test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41372
Reviewed-by: Eric Anholt <[email protected]>
NOTE: This is a candidate for release branches.
|
|
|
|
|
|
|
|
|
|
|
| |
We were looking at the size of batch.map for how big the batchbuffer
was, but on 865 we just use a single-page batchbuffer due to hardware
limits.
v2: Removed check for sizeof map < bo->size, since that's always false.
[change by anholt]
NOTE: This is a candidate for release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to prevent an overflow of the batch buffer when emitting
triangles, we need to limit the initial primitive to fit within the
current batch. To do we need to measure the remaining space and thence
compute the maximum number of vertices that fit into that space.
Reported-by: Kurt Roeckx <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
NOTE: This is a candidate for release branches.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hardware, like i915, uses an inclusive bounds on min and max for
the drawing rectangle, but we were providing a number for exclusive.
The number of bits used by the hardware only covers this value going
up to the maximum size, so when we programmed 2048 as the maximum
inclusive X, it saw a maximum X of 0 and clipped all rendering. This
caused rendering failures in gnome-shell.
Fixes piglit fbo-maxsize.
v2: dropped changes to the blitter, which does use an exclusive x2, y2.
[change by anholt]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45558
Reviewed-by: Eric Anholt <[email protected]>
NOTE: This is a candidate for release branches.
|
|
|
|
| |
swtnl doesn't handle this extension.
|
|
|
|
|
|
|
|
|
| |
This is a direct port of fc4fba52cf7e9616c70dd76b4d6bdba6582e157b from
i915, and fixes GPU hangs when running piglit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41372
Reviewed-by: Eric Anholt <[email protected]>
NOTE: This is a candidate for release branches.
|
|
|
|
|
|
|
| |
This reverts commit 72931ca4b9fb1002f5b62b74f7f7f32e94e80fde.
This commit caused a few piglit regressions (quad-invariance, draw-batch,
etc) with the vmware svga driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the ARB_map_buffer_range extension spec says nothing about these
queries -- they were added in GL 3.0 --, it seems like this could be an
error in the extension spec. This is one of the extensions, like
ARB_framebuffer_object, that "back ports" OpenGL 3.0 functionality to
previous versions. These extensions are supposed to provide identical
functionality to OpenGL 3.0. The other cases of mismatches have been
determined to be bugs in the extension specs.
And tools like apitrace rely on such queries to function properly.
Signed-off-by: Yuanhan Liu <[email protected]>
Signed-off-by: José Fonseca <[email protected]>
Acked-by: Brian Paul <[email protected]>
Acked-by: Ian Romanick <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We currently don't support gl_PrimitiveID, and I believe asking the
hardware to generate it results in vertex cache invalidations.
This could result in slowdowns for applications that use gl_InstanceID,
which would be counter-productive. Just turn it off for now.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
visit(ir_variable *) sets dst_reg::writemask to the appropriate channel
for system values. Unfortunately, visit(ir_dereference_variable *) then
calls swizzle_for_size, which for a float, sets the swizzle to .x.
This works for gl_VertexID, since we store it in the .x component (see
brw_draw_upload.c:732 - VID), but fails for gl_InstanceID (IID) since we
store it in the .y channel.
To fix this, avoid calling swizzle_for_size on ir_var_system_values.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
Fixes piglit GL_ARB_draw_instanced/negative-arrays-first-negative.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Fixes piglit GL_ARB_draw_elements_base_vertex/dlist-arb_draw_instanced
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
When you called them in a display list compile before, you would just
end up calling through NULL.
Fixes piglit GL_ARB_draw_instanced/dlist.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kernels prior to 271d81b84171d84723357ae6d172ec16b0d8139c (March 2011)
don't support relocations outside of the target buffer object. Rather
than guarding this with a I915_PARAM_HAS_RELAXED_DELTA check, just
smash the bound to 0xfffff001 like we do on Ironlake.
This effectively gives us no upper bound check, just like we did prior
to commit 271d81b84171d84723357ae6d172ec16b0d8139c.
Daniel Vetter would also like to mention that this relies on the guard
page at the end of the GTT.
NOTE: This is a candidate for release branches.
Fixes a regression since 271d81b84171d84723357ae6d172ec16b0d8139c.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46766
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All users of the shine table outside of the tnl module
are gone. Move the implementation into the tnl module and
prefix the public functions with _tnl.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the shine tables are now only used in the tnl lighting stage, where
they are validated through the tnl driver function NotifyMaterialChange
called in tnl/t_vb_light.c, we can not omit calling
_mesa_validate_all_lighting_tables (which only validates the shine tables)
in main/light.c.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Now that _tnl_RasterPos no longer uses the shine tables, avoid
revalidating them.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use direct computation of pow for computing the shininess
in _tnl_RasterPos. Since the _tnl_RasterPos function is still
used by plenty drivers that do only need the shine table for
_tnl_RasterPos but do not make use of swtnl computations, this
enables pushing down the shine table computation and validation
into the tnl module, which will happen in a followup change.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Since the shine tables are implicitly invalidated by having
a different shininess value than the current one, we can
omit the explicit invalidation of the shine table.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
| |
This variable is only used locally in _mesa_update_lighting.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
|
|
|
|
|
|
|
|
| |
It is only used as a temporary variable during computation of
_CosCutoff. So, don't store it.
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Signed-off-by: Mathias Froehlich <[email protected]>
|
| |
|
|
|
|
|
| |
For 1D array textures, there is no border on the height dimension.
For 2D array textures, there is no border on the depth dimension.
|