The GLSL 1.40 spec says:
"Uniform block names and variable names declared within uniform
blocks are scoped at the program level."
Track the block name in the symbol table and emit errors when conflicts
exist.
Fixes es3conform's uniform_buffer_object_block_name_conflict test, and
fixes the piglit block-name-clashes-with-{variable,function,struct}.vert
tests.
NOTE: This is a candidate for the 9.0 branch.
v2: Fix bad constructor initialization. Noticed by Topi Pohjolainen.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
About both row_major and column_major layout qualifiers, the GLSL spec
says:
"It only affects the layout of matrices."
However, the OpenGL ES 3.0 conformance tests have taken this to mean it
is an error use it elsewhere. This seems logical given that
'layout(row_major) vec4 foo' is probably not what the programmer meant.
The only catch is dealing with structures that contain matrices. Layout
qualifiers cannot be applied directly to fields of structures, so the
only way to affect the layout of the fields is to apply a qualifier to
the structure declaration itself. There is ongoing debate about this
within Khronos, and it seems to be settling in favor of allowing the
qualifiers on structures. I light of this, I have chosen to allow the
qualifiers on structures but emit a warning since the usage may not be
portable.
Fixes gles3conform test
uniform_buffer_object_layouts_not_for_matrix_type and causes no
regressions.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Between the previous commit and this one, improves GLBenchmark 2.1
offscreen performance by 0.48% +/- 0.24% (n=22, throttling outliers
removed).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is for GL_ARB_texture_buffer_object_rgb32 support, but it also
causes the format to get used for float32 rgb textures as well on
Ironlake and later. Since that came with some surprises, separate
the change from the enable commit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We almost never want a stride in pixels -- if you're doing anything with
a stride, you're specifying an offset or incrementing a pointer, and in
both cases you had to multiply by cpp to get the bytes value you wanted.
But worse, on the way to creating a region from a new tiled BO, we
divided by cpp to get pitch in pixels, and for an RGB32 buffer (an
upcoming change) the pitch wouldn't divide exactly, and we'd end up with
a wrong stride in our region.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Vincent Lejeune:
- tgsi to llvm now emits pointers for constants
Tom Stellard:
- Only use texture cache for vtx fetch with compute shaders
- Change address space used for constant loads to match LLVM
backend.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
According to the OpenGL 3.2 Core Profile specification, section 3.8.12:
"For one-, two-, and three-dimensional and one-and two-dimensional array
textures, a texture is mipmap complete if all of the following
conditions hold true:
- [...]
- levelbase <= levelmax [...]
Using the preceding definitions, a texture is complete unless any of
the following conditions hold true:
- [...]
- The minification filter requires a mipmap (is neither NEAREST nor
LINEAR), and the texture is not mipmap complete."
(This text also appears in all GL >= 3.2 specs and the ES 3.0 spec.)
From this, we see that levelbase <= levelmax should only affect mipmap
completeness, not base-level completeness.
Prior versions of GL did not have the notion of mipmap completeness,
simply calling the texture incomplete in this case. But I don't think
we really care.
Fixes es3conform's sgis_texture_lod_basic_completeness test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
The sampler appears to ignore writemasks (even when correcting the
WRITEMASK_XYZW in brw_vec4_emit.cpp to the proper writemask) and just
always writes all four values.
To cope with this, just texture into a temporary, then MOV out into a
register that has the proper number of components.
NOTE: This is a candidate for stable branches.
Fixes es3conform's shadow_execution_vert.test.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Previously it was left undefined, causing us to select a random LOD.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
This is purely a refactor. However, in a moment, we'll want to set
lod_type to float for ir_tex, where ir->lod_info.lod is NULL.
NOTE: This is a candidate for stable branches (for the next patch).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Fixes regressions since commit 899017fc54
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Fri Jan 4 07:53:09 2013 -0800
i965: Use Haswell's sample_d_c for textureGrad with shadow samplers.
That patch assumed that all instances were lowered. However, we weren't
lowering textureGrad() with samplerCubeShadow because I couldn't figure
out the LOD calculations. It turns out they're easy: you just have to
use 1 for the depth. This causes it to pass oglconform's four tests.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Ian Romanick <idr@freedesktop.org>
Now that things mostly seem to work enable those formats.
Some formats cause crashes (notably RGB8 variants) so switch these off
(these crashes are not specific to INT/UINT variants but the state tracker
doesn't use them for UNORM etc. formats so it went unnoticed so far).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Cast back the fake floats to ints, and make sure we don't try to do scaling
in format conversion (which only makes sense with normalized values).
Also need to disable blending and alpha test (as per spec) for such buffers.
This makes fbo-blending from the piglit ext_texture_integer tests work for most
formats (some crash, and the luminance and intensity variants have the GB or
GBA channels respectively wrong).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We were passing in the rt index however this was always 0 for non-independent
blend case. (The format was only actually used to decide if the color mask
covered all channels so this went unnoticed and was discovered by accident.)
Additionally, there was a second problem because we do fixups in the key based
on color buffer format we cannot use non-independent blend anyway as the fixed
up values would never get used.
So always turn non-independent blending into independent.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Filtering of DEPTH_COMPONENT and DEPTH_STENCIL for TEXTURE_3D is already
done in texture_error_check because these combinations aren't allowed on
desktop GL either.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Just like DEPTH_COMPONENT.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
1. The loop over dest buffers in blit_linear() needed a null pointer
check. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=59499
2. The code to grab the drawRb's format needs to be inside the drawing loop.
3. An equality test was using = instead of == thus messing up a
renderbuffer attachment texture pointer. This lead to memory
corruption and a crash at exit.
Finally, fix a capitalization error NumDrawBuffers -> numDrawBuffers
and change type to unsigned to fix signed/unsigned comparison warnings.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Instead of deriving it from the colour buffer formats only.
Fixes a number of piglit tests which export depth from the pixel shader.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes piglit 'spec/ARB_depth_buffer_float/fbo-clear-formats stencil' crash.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Enabling it for all resources still seems to cause problems, but depth/stencil
buffers are always accessed with tiling by the DB block.
Also, stick to 1D tiling for now. Getting 2D tiling to work properly will
require substantial changes in libdrm_radeon and possibly the kernel as well.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Apart from the obvious cleanup, this makes sure all blocks use the same tiling
mode for accessing the resource.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Currently the use of external firmware is required, with kernel and
userspace firmware needed for all Fermi cards except nvd9. Kepler and nvd9
should only require kernel firmware.
1. Loop over multiple destination color buffers. If we set
glDrawBuffers(GL_FRONT_AND_BACK) we need to loop over multiple color
buffers, blitting to each.
2. Add checks for null src/dst surface pointers. This fixes a crash
in the piglit fbo-missing-attachment-blit test.
See bug http://bugs.freedesktop.org/show_bug.cgi?id=59450
Reviewed-by: Reviewed-by: Marek Olšák <maraeo@gmail.com>
Use os.path.join() rather than hand-rolling it, so path is correct if
sys.argv[0] returns an absolute path.
(According to the python documentation, it's platform dependent whether
sys.argv[0] is a full pathname or not. It probably also depends on how
the process was started...)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It seems the other code expects surface[0..1] to be the luma field in interlaced case.
See for example vdpau/surface.c vlVdpVideoSurfaceClear and vlVdpVideoSurfacePutBitsYCbCr.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Writemask was XY instead of YZ (thanks to calim for spotting it).
The pixel calculation resulted in the pixel always being off by one.
If y was .5:
y' = round(y) + 0.5 = 1.5
Fixing this also means the LRP function has to swap the pixels it, since
it's now the other way around for top/bottom.
WIth these fixes only chroma for top and bottom pixel rows are wrongly interpolated
in my test program:
--- nvidia
+++ nouveau
@@ -1,4 +1,4 @@
-YCbCr[0] = 00c080
+YCbCr[0] = 00b070
YCbCr[1] = 00b070
YCbCr[2] = 029050
YCbCr[3] = 207050
@@ -61,4 +61,4 @@
YCbCr[60] = 0c5070
YCbCr[61] = c05090
YCbCr[62] = 0e70b0
-YCbCr[63] = e080c0
+YCbCr[63] = e070b0
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Added with automake conversion, but makes no sense at all.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
