Almost all of the functions between the ARB and the EXT share the same
GLX protocol because the functionality is, essentially, identical.
However, there are some differences between the extensions:
- In the ARB extension, names must come from glGenBuffers.
- In the ARB extension, framebuffer objects are not shared (but they are
in the EXT).
For these reasons, glBindFramebuffer and glBindRenderbuffer have
different GLX protocol opcodes than their EXT counterparts. Currently
these functions alias each other in the dispatch table. This makes it
impossible to be truly spec conformant.
This patch enables fixing the conformance issue by splitting
glBindFramebuffer / glBindFramebufferEXT and glBindRenderbuffer /
glBindRenderbufferEXT into separate dispatch table entries.
Patches will be available shortly to:
- Fix the conformance issue.
- Stop advertising the EXT in OpenGL 3.1 (or core profiles).
HOWEVER, this does represent a compatibility break between the loader
(libGL or the Xserver GLX module) and the driver. Mesa drivers compiled
without this change will request a single dispatch table entry for
glBindFramebuffer and glBindFramebufferEXT. Since the updated loader
has different entries for each, the request will fail, and the driver
will die in a fire.
Drivers built with the change should continue to load fine on loaders
without the change. In this case, the driver will separately ask for
entries for glBindFramebuffer and glBindFramebufferEXT, and the loader
will tell it the same location. Since the loader in the server's GLX
module is not (yet) updated, this should not be a problem. We also do
not advertise the ARB extension from the server, so, again, this should
not be a problem for the server.
HOWEVER, this means that DRI1 drivers (remember mga_dri.so?) will no
longer load with libGL build hereafter. That means this patch will need
to be back ported to the 8.0 branch.
v2 (idr): Added missing GLX protocol opcodes for the EXT functions and
corrected the opcodes for the ARB functions. Updated GLX indirect_api
unit test and dispatch sanity unit test.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Bartosz Zawistowski <bartosz.l.zawistowski@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Any driver that supports GLSL 1.30 should be able to handle this
extension, as it's entirely implemented in the GLSL compiler.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
While all the work is in the shared GLSL compiler, this extension
requires GLSL 1.30, which is currently only supported on Gen6+.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
layout(binding = N) is equivalent to calling glUniformBlockBinding(_,N).
This currently only handles the GLSL 1.40 case - no interface names, no
arrays of uniform blocks. This is okay since we don't yet support GLSL
1.50, and don't expose ARB_shading_language_420pack in ES 3.0.
v2: Move into the other function; use binding, not constant_value.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Without an instance name, there is no ir_variable representing the
actual uniform block declaration. When the linker goes to set uniform
initializers, it only sees the members as ir_variables; never the block.
So, unfortunately, the members need to know about the binding.
There has to be a better way to do this.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Normally, uniform array variables are initialized by array literals.
That is, val->type->array_elements >= storage->array_elements.
However, samplers are different. Consider a declaration such as:
layout(binding = 5) uniform sampler2D[3];
The initializer value is a single integer (5), while the storage has 3
array elements. The proper behavior here is to increment one for each
element; they should be initialized to 5, 6, and 7.
This patch introduces new code for sampler types which handles both
arrays of samplers and single samplers correctly.
v2: Move into the other function; use binding, not constant_value.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Sampler uniforms and uniform blocks do not have a var->constant_value.
Instead, they have an integer var->binding value.
This makes extending set_uniform_initializer() somewhat problematic: it
assumes that there is an ir_constant * which represents the initializer,
and that it's safe to dereference that without any NULL checks.
Instead, this patch creates an analogous function for binding
qualifiers, and calls one or the other as appropriate.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
There is existing code to handle sampler uniform initializers. Prior to
GLSL 4.20's "binding" keyword, sampler uniforms don't have initializers
at all, so this is somewhat surprising.
The existing code is broken into two cases: one where both the variable and
initializer are arrays, and a second where the variable and initializer are
scalars.
The first case should never occur, since array-typed initializers do not
exist for sampler uniforms. Even with the binding keyword, the
initializer is a single integer which represents the texture unit to use
for the first array element.
The second is apparently used for some fixed-function code.
v2: Rewrite the commit message - suggested by Paul.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
All compilation units need to agree on the binding point, if they
specify one at all.
v2: Use binding, not constant_value.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Rather than creating a new "binding" field in ir_variable, we reuse
constant_value since the linker code for handling uniform initializers
uses that.
Since UBOs and samplers can't otherwise have initializers/constant
values, there shouldn't be a conflict.
v2: Propagate the new binding variable around too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These are not used yet, but they exist and are copied appropriately.
v2: Add an explicit "int binding" variable rather than reusing
constant_value, as suggested by Paul Berry.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The "binding" qualifier only applies to UBO blocks and samplers, along
with arrays of those types. (It would also apply to images and atomic
counters, but we don't support those yet.)
This also validates sampler bindings against the maximum number of
texture units, and UBO bindings against the number of uniform buffer
binding points.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Nothing actually uses this yet.
v2: Remove >= 0 checks. They'll be handled in later validation.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The idea of this code is to disallow layout(...) sections with the
deprecated "varying" or "attribute" keywords, unless a few select
extensions are enabled which allow a more relaxed check.
In order to detect a layout(...) section, the code checks for a number
of layout qualifiers. However, it failed to check for all of them,
which could lead to layout(...) not being detected when it should.
By replacing this with has_layout(), we properly check for all layout
qualifiers, and also guarantees that new qualifiers added in the future
will not be forgotten.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These were already semi-relaxed, since the storage qualifier rule
already skipped when 420pack was enabled.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The GL_ARB_shading_language_420pack extension/GLSL 4.20 split centroid
off into a new category, "auxiliary storage qualifiers," and allow these
to be placed anywhere in the series. So we have to stop recognizing
"centroid in"/"centroid out"/"centroid varying" in the grammar and get
more creative.
The same approach used before works here, too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is necessary for the parser to be able to accept precision
qualifiers not immediately adjacent to the type, such as "const highp
inout float foo".
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Currently, we store precision in ast_type_specifier, rather than
ast_type_qualifier. This works because precision is the last qualifier,
and immediately adjacent to the type.
Default precision statements (such as "precision highp float") are
represented as ast_type_specifier objects, with a boolean to indicate
that it's a default precision statement rather than an ordinary type.
ast_type_specifier::precision will be moving to ast_type_qualifier soon,
in order to support arbitrary qualifier ordering. However, we still
need to store a "this is a precision statement" flag /and/ the default
precision in ast_type_specifier.
This patch changes the boolean into a new field, default_precision.
If default_precision != ast_precision_none, it's a precision statement
with the specified precision. Otherwise, it's an ordinary type.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This makes the complier accept both "const in" and "in const".
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This will make it easy to support both "const in" and "in const", as
required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
"Parameter direction qualifier" is a new term I invented just now; it's
not part of any GLSL specification.
This paves the way handling multiple parameter qualifiers, in any order,
as required by GLSL 4.20/ARB_shading_language_420pack.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Most of ast_type_qualifier is simply a bitfield (represented as a
structure of unsigned:1 bits in a union with an unsigned). However, it
also contains ARB_explicit_attrib_location's location/index fields.
In the past, this has worked by simply returning the layout qualifier's
ast_type_qualifier and merging the other bits into it. However, that's
not obvious until you break it by switching $1 and $2.
Using merge_qualifier() copies them appropriately, and also properly
overrides layout qualifiers. It also checks for duplicate qualifiers,
which renders some of the checks in the previous patch unnecessary.
However, those checks provide better error messages, such as "Duplicate
interpolation qualifier", rather than just "duplicate qualifier".
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This makes the compiler accept invariant, storage, layout, and
interpolation qualifiers in any order when ARB_shading_language_420pack
is enabled.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The GL_ARB_shading_language_420pack extension/GLSL 4.20 allow qualifiers
to be specified in (basically) any order. In order to support this, we
can't hardcode the ordering restrictions in the grammar.
This patch alters the grammar to accept invariant, storage, layout, and
interpolation qualifiers in any order, but adds C code to enforce the
ordering requirements. In the 420pack case, we should be able to simply
skip the error checks.
As a bonus, this also lets us generate decent error messages, rather
than Bison's awful "unexpected TOKEN" errors.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
"Auxiliary storage qualifiers" is the new term given to "centroid",
"patch", and "sample" by GLSL 4.20/GL_ARB_shading_language_420pack.
Even though we only support "centroid", it's useful to add this now
so that all auxiliary storage qualifiers get handled in the right places
once they're eventually supported.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This makes it easy to check if any storage qualifiers are set.
"centroid" is not considered a storage qualifier. In the old language
rules, you can't specify "centroid" by itself; it's always "centroid
in", "centroid out", or "centroid varying." So one of the other storage
qualifiers will always be set; there's no need to specifically check for
centroid.
In the new 4.20 rules, centroid is an auxiliary storage qualifier, not a
storage qualifier.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This makes it easy to check if any layout qualifiers are set.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
All four URB packets need to be programmed together in order for the GPU
state to be valid. Putting them in separate BEGIN..ADVANCE blocks is
risky: if we're nearing the end of a batch, the batch could be flushed
inbetween two of the commands, causing the URB programming to be split
into two batchbuffers.
This -might- be okay with hardware contexts, but it offers no advantages
over keeping them together, and has a potential for hangs.
Putting them into a single BEGIN..ADVANCE block ensures they'll be kept
in the same batch, which seems wise.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
In blorp, change only the PS packet, because the VS packet is disabled.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Some render types, such as floating-point, aren't valid with EGL.
Return NULL in those cases to drop them.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Mark __DRI_ATTRIB_FLOAT_MODE as deprecated, and introduce new flags to
__DRI_ATTRIB_RENDER_TYPE for float modes. Both signed float
(fbconfig_float) and unsigned (packed_float) are introduced. The old
attribute should be set for both float modes.
v2 (idr): Require that the render mode from the DRI attributes matches the
render mode of the config exactly. This is the behavior of the old code.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Make sure that init_fbconfig_for_chooser sets correct value of
drawableType for visual configs and fbconfigs.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Correctly handle the value of renderType in GLX context. In case of the
value being incorrect, context creation fails.
v2 (idr): indirect_create_context is just a memory allocator, so don't
validate the GLX_RENDER_TYPE there. Fixes regressions in several
GLX_ARB_create_context piglit tests.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
v2 (idr): Open-code the check for GLX_RENDER_TYPE.
dri2_convert_glx_attribs can't be called from here because that function
only exists in direct-rendering builds. Also add a stub version of
indirect_create_context_attribs to tests/fake_glx_screen.cpp to prevent
'make check' regressions.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Set the correct values of renderType in glXCreateContext and
init_fbconfig_for_chooser.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Correctly handle the value of renderType and drawableType in
fbconfig. Modify glXInitializeVisualConfigFromTags to read the parameter
value, or detect it if it's not there.
v2 (idr): If there was no GLX_RENDER_TYPE property, set the type based
purely on the rgbMode as the previous code did. It is impossible for
floatMode to be set at this point, so we can't have a float config. The
previous code regressed a large number of piglit GLX tests because those
tests don't set GLX_RENDER_TYPE in the glXChooseConfig call. Restoring
the old behavior for that case fixes those regressions.
Also fix handling of GLX_DONT_CARE for GLX_RENDER_TYPE. Fixes a
regression in glx-dont-care-mask.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Make sure that context creation routines are provided with the value of
RENDER_TYPE retrieved from GLX attribs.
v2 (idr): Minor formatting changes. Change type of
dri2_convert_glx_attribs render_type parameter to uint32_t to silence
some GCC warnings.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Make sure that renderType property value is stored in GLX context while
it's being created. Further patches will be provided to make the value
correspond to fbconfig's renderType.
v2 (idr): Move a hunk from the next patch to this patch to prevent a
build break.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The L3 controls are identical on all platforms, but LLC differs:
- Ivybridge has a "cache in LLC" flag
- Baytrail has no LLC, but instead has a snoop bit:
"data accesses in this page must be snooped in the CPU caches."
- Haswell has writeback/uncached flags for LLC and eLLC (eDRAM).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The current gen_matypes logic assumes that the host compiler will produce
information that is useful for the target compiler. Unfortunately, this
is not the case whenever cross-compiling.
When we detect that we're cross-compiling and using GCC, use the target
compiler to produce assembly from the gen_matypes.c source, then process
it with a shell script to create a usable header. This is similar to how
the linux kernel creates its asm-offsets.c file.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is required in case a wrapper or symlink is used. This patch
has also been sent upstream, awaiting moderation.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andreas Oberritter <obi@saftware.de>
Adds the dependencies of builtin_compiler as sources when cross
compiling instead of using libtool to share compilation with src/glsl.
The builtin_compiler executable is built for the host when cross
compiling so it doesn't make sense to share compilation with src/glsl
built for the target in this case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44618
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Jonathan Liu <net147@gmail.com>
Usually with fixed point renderbuffers clamping is done as part of conversion.
However, since we blend in float format, we essentially skip all conversion
steps pre-blend but since this is still a fixed point renderbuffer we must
still clamp the inputs in this case. Makes no difference for piglit though.
Obviously we could skip this if fragment color clamping is enabled, but a)
this is deprecated in OpenGL (d3d never had it) and b) we don't support it
natively so it gets baked into the shader.
Also add some comment about logic ops being broken for srgb, luckily no test
tries to do that as there's no easy fix...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
We were fixing up the blend factor to ZERO, however this only works correctly
with fixed point render buffers where the input values are clamped to 0/1
(because src_alpha_saturate is min(As, 1-Ad) so can be negative with unclamped
inputs). Haven't seen any failure anywhere due to that with fixed point SNORM
buffers (which clamp inputs to -1/1) but it should apply there as well (snorm
blending is rare, even opengl 4.3 doesn't require snorm rendertargets at all,
d3d10 requires them but they are not blendable).
Doesn't look like piglit hits this though (some internal testing hits the
float case at least). (With legacy OpenGL we could theoretically still use the
fixup to zero if the fragment color clamp is enabled, but we can't detect that
easily since we don't support native clamping hence it gets baked into the
shader.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Adds H.264 and MPEG2 codec support via VP2, using firmware from the
blob. Acceleration is supported at the bitstream level for H.264 and
IDCT level for MPEG2.
Known issues:
- H.264 interlaced doesn't render properly
- H.264 shows very occasional artifacts on a small fraction of videos
- MPEG2 + VDPAU shows frequent but small artifacts, which aren't there
when using XvMC on the same videos
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Use grep -w instead of the empty string escape sequences
which are less portable. Makes the grep tests
function as intended on OpenBSD.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Fixes this build error on OpenBSD 5.3.
In file included from ../../src/mesa/main/ff_fragment_shader.cpp:53:
./../glsl/ir_optimization.h:64: error: comma at end of enumerator list
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Fixes these build errors on OpenBSD 5.3.
In file included from ../../src/mesa/main/errors.h:47,
from ../../src/mesa/main/imports.h:41,
from ../../src/mesa/main/ff_fragment_shader.cpp:32:
../../src/mesa/main/mtypes.h:3286: error: comma at end of enumerator list
../../src/mesa/main/mtypes.h:3296: error: comma at end of enumerator list
../../src/mesa/main/mtypes.h:3303: error: comma at end of enumerator list
../../src/mesa/main/mtypes.h:3356: error: comma at end of enumerator list
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Use "or" instead of "add" (this is a classic select sequence, which at
least newer llvm versions can actually recognize (3.2+?), and the "add"
might prevent that - and we really don't want an add instead of an or with
avx if it isn't recognized (even without avx logic ops might be cheaper)).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Instead of just ignoring the srgb/linear conversions, simply call the
corresponding conversion functions, for all of pack/unpack/fetch,
both for float and unorm8 versions (though some don't make a whole
lot of sense, i.e. unorm8/unorm8 srgb/linear combinations).
Refactored some functions a bit so don't have to duplicate all the code
(there's a slight change for packing dxt1_rgb, as there will now be
always 4 components initialized and sent to the external compression
function so the same code can be used for all, the quite horrid and
ad-hoc interface (by now) should always have worked with that).
Fixes llvmpipe/softpipe piglit texwrap GL_EXT_texture_sRGB-s3tc.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Scheduler/register allocator in r600-sb was developed and optimized
on evergreen (VLIW-5) hardware, so currently it's not optimal for
VLIW-4 chips.
This patch should improve performance on cayman gpus due to better alu
packing, but also it tends to increase register usage, so overall positive
effect on performance has to be proven by real benchmarks yet.
Some results with bfgminer kernel on cayman:
source bytecode: 60 gprs, 3905 alu groups,
sbcl before the patch: 45 gprs, 4088 alu groups,
sbcl with this patch: 55 gprs, 3474 alu groups.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Ex-scalar instructions that became multislot on cayman do replicate result
to all channels - handle them similar to DOT4.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Actually PS doesn't make sense for cayman and isn't even mentioned in
cayman docs, but llvm backend currently uses it in bytecode and, assuming
that hw seems to be mostly ok with it, this will allow sb to parse such
source bytecode correctly.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Every function but the above four uses explicitly sized types for their
src and dst arguments. Even fetch_rgba_{s,u}int follows the convention.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Marek Olšák <maraeo@gmail.com>
MCJIT is the only supported LLVM JIT on AArch64 and ARM (the regular
JIT has bit-rotted badly on ARM and doesn't exist on AArch64.)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Historically, we indented grammar production rules with a single 8-space
tab, but code inside of blocks used Mesa's 3-space indents.
This meant when editing code, you had to use an 8-space tab for the
first level of indentation, and 3-spaces after that. Unless you
specifically configure your editor to understand this, it will get the
indentation wrong on every single line you touch, which quickly devolves
into a colossal waste of time.
It's also inconsistent with every other file in the entire project.
This patch removes all tabs and moves to a consistent 3-space indent.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
When working on a parser, it's very easy to accidentally introduce
new shift/reduce conflicts. Failing the build guarantees they'll
be noticed and fixed.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
The single remaining shift/reduce conflict was the classic ELSE problem:
292 selection_rest_statement: statement . ELSE statement
293 | statement .
ELSE shift, and go to state 479
ELSE [reduce using rule 293 (selection_rest_statement)]
$default reduce using rule 293 (selection_rest_statement)
The correct behavior here is to shift, which is what happens by default.
However, resolving it explicitly will make it possible to fail the build
on new errors, making them much easier to detect.
The classic way to solve this is to use right associativity:
http://www.gnu.org/software/bison/manual/html_node/Non-Operators.html
Since there is no THEN token in GLSL, we need to fake one. %right THEN
creates a new terminal symbol; the %prec directive says to use the
precedence of that terminal.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
opt_return_value was not initialized if mode != ast_return.
Fixes "Uninitialized pointer field" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This should fix missing symbols in a osmesa built against shared glapi
osmesa build. All opengl exports were missing that are defined in the
static glapi, so link against both to fix this.
This is a candidate for the stable series.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47824
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
We always emit U,V,R coordinates for this message, but the sampler gets
very angry if we pass garbage in the R coordinate for at least some
texture formats.
Fill the remaining coordinates with zero instead.
Fixes broken rendering on GM45 in Source games, and in VDrift.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65236
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
brw_tex_layout.c sets up the align_w/h fields, and has all the
appropriate spec references already.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The Sandybridge code had a citation for the range of the "Maximum Number
of Threads" field, and the Ivybridge code just mentioned the "BSpec" in
general. That's documented in the obvious place, so people can find it
without a spec reference.
The real value of the comment is to say "we tried zero, and it exploded,
so program it to a valid number even if pixel shading is off."
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Unfortunately, the workaround text never made it into the Sandybridge
PRM, so we still have to refer to the BSpec.
It also wasn't obvious why we needed this workaround at all, since we
don't currently do VS passthrough - but BLORP can turn off the VS.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Sadly, the Ivybridge PRM can't be cited, as it is missing the relevant
text for some reason. However, the Sandybridge PRM has the text Chad
originally quoted, and the modern BSpec has the same text.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
I cut and pasted these comments from the Gen4 code during Ivybridge
enabling, and didn't understand what they meant at the time.
The data cache is NOT the same as the sampler cache on Ivybridge.
The sampler cache has L1 and L2 caches in addition to the L3 cache,
while data port messages to the "data cache" hit L3 directly.
This means that the sampler domain is technically wrong, but we stopped
caring about read/write domains quite a while ago. The kernel just
flushes all the caches at the end of each batchbuffer, and our render to
texture code flushes the sampler caches when necessary.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Presumably, this comment exists to justify the usage of
I915_GEM_DOMAIN_SAMPLER for this relocation. At one point, this was
necessary to ensure that the right flushing was done to keep caches
coherent. These days, the kernel just flushes everything, so I don't
think it matters.
Still, the comment is interesting, so leave it in place.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The Ivybridge PRM adds new SFIDs and lists them in a different volume
than Sandybridge, so it's worth adding a reference.
I also removed the BSpec reference, as the section it referred to
was moved somewhere, and I couldn't find it. This leaves one Haswell
SFID without a citation, but we can add one once the PRMs are out.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Just use the new conversion functions to do the work. The way it's plugged
in into the blend code is quite hacktastic but follows all the same hacks
as used by packed float format already.
Only support 4x8bit srgb formats (rgba/rgbx plus swizzle), 24bit formats never
worked anyway in the blend code and are thus disabled, and I don't think anyone
is interested in L8/L8A8. Would need even more hacks otherwise.
Unless I'm missing something, this is the last feature except MSAA needed for
OpenGL 3.0, and for OpenGL 3.1 as well I believe.
v2: prettify a bit, use separate function for packing.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The splitting of a draw call into several draw commands was broken, because
the split sometimes took place in the middle of a primitive. The splitting
was supposed to be dealing with the case when there are more indices than
the maximum size of a CS.
This commit throws that code away and uses a real index buffer instead.
https://bugs.freedesktop.org/show_bug.cgi?id=66558
Cc: mesa-stable@lists.freedesktop.org
_mesa_ast_set_aggregate_type walks through declarations initialized with
C-style aggregate initializers and stops when it runs out of LHS
declarations or RHS expressions.
In the example
vec4 v = {{{1, 2, 3, 4}}};
_mesa_ast_set_aggregate_type would not recurse into the subexpressions
(since vec4s do not contain types that can be initialized with an
aggregate initializer) to set their <constructor_type>s. Later in ::hir
we would dereference the NULL pointer and segfault.
If <constructor_type> is NULL in ::hir we know that the LHS and RHS
were unbalanced and the code is illegal.
Arrays, structs, and matrices were unaffected.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders). The functions called each other in ad-hoc
ways, leading to unexpected inconsistencies (for example,
generate_120_fs_variables was called for GLSL versions 1.20 and above,
but generate_130_fs_variables was called only for GLSL version 1.30).
In addition, it led to a lot of code duplication, since many varyings
had to be duplicated in both the FS and VS code paths. With the
advent of geometry shaders (and later, tessellation control and
tessellation evaluation shaders), this code duplication was going to
get a lot worse.
So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type.
In addition, we use a class, builtin_variable_generator, to keep track
of the instruction exec_list, the GLSL parse state, commonly-used
types, and a few other variables, so that we don't have to pass them
around as function arguments. This makes the code a lot more compact.
Where it was feasible to do so without introducing compilation errors,
I've also gone ahead and introduced the variables needed for
{ARB,EXT}_geometry_shader4 style geometry shaders. This patch takes
care of everything except the GS variable gl_VerticesIn, the FS
variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
(using the gl_in interface block). Those remaining features will be
added later.
I've also made a slight nomenclature change: previously we used the
word "deprecated" to refer to variables which are marked in GLSL 1.40
as requiring the ARB_compatibility extension, and are marked in GLSL
1.50 onward as requiring the compatibilty profile. This was
misleading, since not all deprecated variables require the
compatibility profile (for example gl_FragData and gl_FragColor, which
have been deprecated since GLSL 1.30, but do not require the
compatibility profile until GLSL 4.20). We now consistently use the
word "compatibility" to refer to these variables.
This patch doesn't introduce any functional changes (since geometry
shaders haven't been enabled yet).
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Rename "typ" -> "type". Add blank line between inline functions
and declarations in builtin_variable_generator class. Use the
standard comment "/* FALLTHROUGH */" for compatibility with static
code analysis tools.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In certain rare cases (such as those involving dereference of a
literal constant array of structs),
flatten_named_interface_blocks_declarations's rvalue visitor may be
invoked on an ir_dereference_record whose variable_referenced() method
returns NULL.
Check for this case to avoid a segfault.
Prevents crashes in piglit tests
{vs,fs}-deref-literal-array-of-structs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Vertex shader inputs are not allowed to be arrays until GLSL 1.50. We
were accidentally enabling them for GLSL 1.40 (although we haven't
written any tests for them, so it's not clear whether they actually
work).
NOTE: although this is a simple bug fix, it probably isn't sensible to
cherry-pick it to stable release branches, since its only effect is to
cause incorrectly-written shaders to fail to compile.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes undefined results if a back color is written, but the
corresponding front color is not, and only backfacing primitives are
drawn. Results are still undefined if a frontfacing primitive is drawn,
but that's OK.
The other reasonable way to fix this would have been to just pick
the one color slot that was populated, but that dilutes the value of
the tests.
On Gen6+, the fixed function clipper and triangle setup already take
care of this.
Fixes 11 piglits:
spec/glsl-1.10/execution/interpolation/interpolation-none-gl_Back*Color-*
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Some lame compilers can't do exp2f() and as far as I can tell they can't do
exp2() (with doubles) neither so instead of providing some workaround for
that (wouldn't actually be too bad just replace with pow) and since it is
used with a constant only just use the precalculated constant.
When only the offset to the index buffer is changed, we can skip the
3DSTATE_INDEX_BUFFER if we always use 0 for the offset, and add
(offset / index_size) to Start Vertex Location in 3DPRIMITIVE.
srgb-to-linear is using 3rd degree polynomial for now which should be _just_
good enough. Reverse is using some rational polynomials and is quite accurate,
though not hooked into llvmpipe's blend code yet and hence unused (untested).
Using a table might also be an option (for srgb-to-linear especially).
This does not enable any new features yet because EXT_texture_srgb was already
supported via util_format fallbacks, but performance was lacking probably due
to the external function call (the table used by the util_format_srgb code may
not be all that much slower on its own).
Some performance figures (taken from modified gloss, replaced both base and
sphere texture to use GL_SRGB instead of GL_RGB, measured on 1Ghz Sandy Bridge,
the numbers aren't terribly accurate):
normal gloss, aos, 8-wide: 47 fps
normal gloss, aos, 4-wide: 48 fps
normal gloss, forced to soa, 8-wide: 48 fps
normal gloss, forced to soa, 4-wide: 47 fps
patched gloss, old code, soa, 8-wide: 21 fps
patched gloss, old code, soa, 4-wide: 24 fps
patched gloss, new code, soa, 8-wide: 41 fps
patched gloss, new code, soa, 4-wide: 38 fps
So there's a performance hit but it seems acceptable, certainly better
than using the fallback.
Note the new code only works for 4x8bit srgb formats, others (L8/L8A8) will
continue to use the old util_format fallback, because I can't be bothered
to write code for formats noone uses anyway (as decoding is done as part of
lp_build_unpack_rgba_soa which can only handle block type width of 32).
Compressed srgb formats should get their own path though eventually (it is
going to be expensive in any case, first decompress, then convert).
No piglit regressions.
v2: use lp_build_polynomial instead of ad-hoc polynomial construction, also
since keeping both linear to srgb functions for now make sure both are
compiled (since they share quite some code just integrate into the same
function).
v3: formatting fixes and bugfix in the complicated (disabled) linear-to-srgb
path.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We had to disable fast rsqrt before because it wasn't precise enough etc.
However in situations when we know we're not going to need more precision
we can still use a fast rsqrt (which can be several times faster than
the quite expensive sqrt). Hence introduce a new helper which does exactly
that - it is probably not useful calling it in some situations if there's
no fast rsqrt available so make it queryable if it's available too.
v2: use fast_rsqrt consistently instead of rsqrt_fast, fix indentation,
let rsqrt use fast_rsqrt.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
gl_TexCoord was deprecated in GLSL 1.30. In GLSL 1.40 it was marked
as ARB_compatibility-only, and in GLSL 1.50 and above it was marked as
only appearing in the compatibility profile. It has never appeared in
GLSL ES.
However, Mesa erroneously included it in all desktop versions of GLSL,
even versions 1.40 and 1.50 (which do not currently support the
compatibility profile). This patch makes gl_TexCoord available in the
compatibility profile (and GLSL versions 1.30 and prior) only.
NOTE: although this is a simple bug fix, it probably isn't sensible to
cherry-pick it to stable release branches, since its only effect is to
cause incorrectly-written shaders to fail to compile.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The compiler does not know that ilo_3d_pipeline_estimate_size() is pure and
can be eliminated in a release build in gen6_pipeline_end(). Move the call
into the assert().
The AC_CHECK_FILE macro can't be used for cross compiling as it will
result in "error: cannot check for file existence when cross compiling".
Replace it with the AS_IF macro.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jonathan Liu <net147@gmail.com>
GLSL spec says that rsq is undefined for src<=0, but the D3D10
spec says it needs to be a NaN, so lets stop taking an absolute
value of the source which completely breaks that behavior. For
the gl program we can simply insert an extra abs instrunction
which produces the desired behavior there.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
TGSI_OPCODE_KIL and KILP had confusing names. The former was conditional
kill (if any src component < 0). The later was unconditional kill.
At one time KILP was supposed to work with NV-style condition
codes/predicates but we never had that in TGSI.
This patch renames both opcodes:
TGSI_OPCODE_KIL -> KILL_IF (kill if src.xyzw < 0)
TGSI_OPCODE_KILP -> KILL (unconditional kill)
Note: I didn't just transpose the opcode names to help ensure that I
didn't miss updating any code anywhere.
I believe I've updated all the relevant code and comments but I'm
not 100% sure that some drivers had this right in the first place.
For example, the radeon driver might have llvm.AMDGPU.kill and
llvm.AMDGPU.kilp mixed up. Driver authors should review their code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
KILP is really unconditional fragment kill.
We've had KIL and KILP transposed forever. I'll fix that next.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The code happened to work in the past since the (scalar) src args
effectively always have a swizzle of .xxxx, .yyyy, .zzzz, or .wwww so
whether you grab the X or Y component doesn't really matter. Just
fixing the code to make it look right.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This update fixes the problem with duplicated typedefs for
GLclampf and GLclampd in the previous version.
It also changes some parameter types for glDebugMessageCallbackARB()
and glTransformFeedbackVaryingsEXT().
Note we should someday update the glapi-gen code so that it
understands void pointer parameters. Currently, the Python code
only understands "GLvoid *" but not "void *". Luckily, the
compilers don't seem to complain about mixing GLvoid and void.
If the size argument isn't a multiple of four, we would have read/
copied uninitialized memory.
Fixes an issue reported by Myles C. Maxfield <myles.maxfield@gmail.com>
They are a non-standard GCC extension that's not widely supported by
other C/C++ compilers.
Use a dynamic array instead.
Trivial. Should fix the MSVC build.
Required by GL_ARB_shading_language_420pack.
Parts based on work done by Todd Previte and Ken Graunke, implementing
basic support for C-style initializers of arrays.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Will be used in a later commit to differentiate between a structure type
declaration and a variable declaration of a struct type. I.e., the
difference between
struct S { float x; }; (is_declaration = true)
and
S s; (is_declaration = false)
Also note that is_declaration = true for
struct S { float x; } s;
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Will be used in a future commit. An ast_type_specifier is stored (rather
than an ast_struct_specifier) with the idea that we may have more
general uses for this in the future. struct names are prefixed with
'#ast.' to avoid collisions with the glsl_types in the symbol table.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The code float a[2] = float[2]( 3.4, 4.2, 5.0 ); previously generated
this:
error: array constructor must have at least 2 parameters
when in fact it requires exactly two.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romainck@intel.com>
libglslcore.la and libglcpp.la that are built with builtin_compiler are also
linked to by drivers not using libdricore. Since there is no public symbol in
them, it is better to mark all symbols hidden.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We mark ARB_uniform_buffer_object as enabled under ES 3 since it
contains that functionality, which tricked the compiler into tokenizing
"row_major".
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch adds support for some math optimizations that are generally
considered unsafe, that's why they are currently disabled for compute
shaders.
GL requirements are less strict, so they are enabled for
for GL shaders by default. In case of any issues with
applications that rely on higher precision than guaranteed by GL,
'sbsafemath' option in R600_DEBUG allows to disable them.
v2 - always set proper src vector size for transformed instructions
- check for clamp modifier in the expr_handler::fold_assoc
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel >
Pixel Backend > MCS Buffer for Render Target(s) [DevIVB+]:
[DevHSW:GT3]: Clear rectangle must be aligned to two times
the number of pixels in the table shown below...
Observed no piglit, gles3conform regressions with this patch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65744
It seems __builtin_ia32_ldmxcsr is only available on gcc and only when
-msse is used. xmmintrin.h/pmmintrin.h provide portable intrinsics, but
these too are only available with gcc when -msse/-msse3 are set.
scons build always sets -msse on x86 builds, but autotools doesn't seem
to.
We could try to get this working on gcc x86 without -msse by emitting
assembly, but I believe that in this day and age we really should be
building Mesa with -msse and -msse2.
The D3D10 spec is very explicit about treatment of denorm floats and
the behavior is exactly the same for them as it would be for -0 or
+0. This makes our shading code match that behavior, since OpenGL
doesn't care and on a few cpu's it's faster (worst case the same).
Float16 conversions will likely break but we'll fix them in a follow
up commit.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Most functions no longer use intel_context, so this patch additionally
removes the local "intel" variables to avoid compiler warnings.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Things worked out in the past because both brw and intel share the same
memory address (by virtue of intel being the first member of brw).
However, brw is what actually gets rzalloc'd (brw_context.c:285), so
freeing that seems safer and more obvious.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
This makes brw_context available in every function that used
intel_context. This makes it possible to start migrating fields from
intel_context to brw_context.
Surprisingly, this actually removes some code, as functions that use
OUT_BATCH don't need to declare "intel"; they just use "brw."
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
These files have forward declarations for intel_context. This makes
brw_context available in the same places without further #include
monkeying.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
brw_context.h includes intel_context.h, but additionally makes the
brw_context structure available. Switching this allows us to start
using brw_context in more places.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
brwCreateContext() has a lot of random things to do. Factoring out the
part that initializes ctx->Const values and shader compiler options
makes the main function a bit easier to read.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Technically, needs_ff_sync was set on Gen5+, but it was only consulted
in the clipper threads and quad/lineloop decomposition code, which are
both Gen4-5 only. So in reality it only identified Ironlake.
The named flag doesn't really clarify things, and seems like overkill.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Acked-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
perf_debug() doesn't add a newline for you; without this, all the
INTEL_DEBUG=perf output was jumbled together.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Resolves the following gcc warning
opt_flip_matrices.cpp:84:32: warning: unused variable 'deref'
v2: keep the variable, but wrap it in a ifndef NDEBUG block
(suggested by Ian)
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Resolves the following gcc warnings
warning: 'iface_type_name' may be used uninitialized in this function
warning: 'var_mode' may be used uninitialized in this function
Note: The variables are initialised to UNKNOWN and ir_var_auto
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
driver->ProgramStringNotify is only called for ARB programs, fixed
function vertex programs, and ir_to_mesa (which isn't used by the i965
back-end). Therefore, even after geometry shaders are added,
brwProgramStringNotify should only ever be called with a target of
GL_VERTEX_PROGRAM_ARB or GL_FRAGMENT_PROGRAM_ARB.
This patch adds an assertion to clarify that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's done automatically for vertex buffers, but not for constant buffers,
textures, and colorbuffers.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This should increase performance if constant uploads are done with the CP DMA,
because only the cache that needs to be flushed is flushed.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
also flushing any cache in evergreen_emit_cs_shader seems to be superfluous
(we don't flush caches when changing the other shaders either)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
1. flush SH with read caches
2. add flag for DB flushes
3. add flag for CB flushes
v2: flush all CBs, remove redundant emit_state variable.
v3: Marek: also set the new flags in r600_context_flush, the CP dma functions,
and texture_barrier, and rename them
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The winsys should do this, because it measures how much time we spend
in buffer_map doing synchronization, which can be viewed with the gallium
HUD.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
It was wrong, because the offset shouldn't be applied to MSAA depth buffers.
This small cleanup should prevent such issues in the future.
This fixes a lockup in "piglit/fbo-depthstencil default_fb -samples=n".
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Include src0 alpha in the RT write message when using MRT, so it is used
for the alpha test instead of the normal per-RT alpha value.
Fixes broken rendering in Dota2 under Wine [FDO #62647].
No Piglit regressions on Ivybridge.
V2: reuse (and simplify) existing sample_alpha_to_coverage flag in
the FS key, rather than adding another redundant one.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewd-by: Paul Berry <stereotype441@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62647
NOTE: This is a candidate for the stable branches.
The logic for choosing number of lods was bogus.
(The code should ultimately handle the case of only one lod even with multiple
quads but currently can't.)
It is perfectly valid for the swizzle to be bigger than 2. For example the
texel offsets could be
SAMPLE ..., IMM[0].zzz
What is not correct is for chan_index to be bigger than 2.
Trivial.
Shaders need a lot of work still. Basic stuff generally works, so this
is basically just fine for gnome-shell, OA etc at this point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The assertion was always broken but the code unused until enabling the
per-element lod code. Fixes piglit texelFetch vs isampler1D and similar
tests (only run with GL 3.0 version override).
d3d10 requires per-pixel lod calculations for explicit lod, lod bias and
explicit derivatives, and we should probably do it for OpenGL too - at least
if they are used from vertex or geometry shaders (so doesn't apply to lod
bias) this doesn't just affect neighboring pixels.
Some code was already there to handle this so fix it up and enable it.
There will no doubt be a performance hit unfortunately, we could do better
if we'd knew we had a real vector shift instruction (with variable shift
count) but this requires AVX2 on x86 (or a AMD Bulldozer family cpu).
Don't do anything for lod bias and explicit derivatives yet, though
no special magic should be needed for them neither.
Likewise, the size query is still broken just the same.
v2: Use information if lod is a (broadcast) scalar or not. The idea would be
to base this on the actual value, for now just pretend it's a scalar in fs
and not a scalar otherwise (so, per-pixel lod is only used in gs/vs but same
code is generated for fs as before).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The semantics for overflow detection are a bit tricky with
indexed rendering. If the base index in the elements array
overflows, then the index of the first element should be used,
if the index with bias overflows then it should be treated
like a normal overflow. Also overflows need to be checked for
in all paths that either the bias, or the starting index location.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The comparison, incorrectly, was greater-than-or-equal to
elt max.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The texture alignment unit functions are called from brw_tex_layout.c,
so it makes sense to put them there. Since the only caller of
intel_get_texture_alignment_unit() is in brw_tex_layout.c, it could be
made into a static function. However, this patch instead simply folds
it into the caller, as it's only two lines anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
intel_miptree_create_layout() calls intel_get_texture_alignment_unit()
and then immediately calls brw_miptree_layout(). There are no other
callers.
intel_get_texture_alignment_unit() populates the miptree's alignment
unit fields, which are used by brw_miptree_layout() to determine where
to place each miplevel. Since brw_miptree_layout() needs those to be
present, it makes sense to have it initialize them as the first step.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The driver is compiled in C99 mode, so this is not a problem. It's
slighlty tidier.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This uses Doxygen style for the file comments, and generally makes it
more consistent with the rest of the driver.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Now that both 2DArray and Cube layouts are taken care of by helper
functions, it's easy to just call the right function for each
generation. This is a little cleaner than falling through.
This also reworks the comments. Referencing "Volume 1" of the BSpec
isn't very helpful, since that's only available inside Intel, and it
doesn't even use volume numbers. Also, "Ironlake...finally" sounds a
bit strange considering that almost all hardware uses the 2D array
approach. At this point, Gen4 is the only special case.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
maxBatchSize was only ever initialized to BATCH_SZ, and a few places
used BATCH_SZ directly anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
brw_annotate_aub() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
brw_debug_batch() is the only implementation of this function, so it
makes sense to just call it directly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
brw_render_target_supported() is the only implementation of this
function, so it makes sense to just call it directly.
Rather than adding an #include of brw_wm.h, this patch moves the
prototype to brw_context.h. Prototypes seem to be in rather arbitrary
places at the moment, and either place seems as good as the other.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
brw_is_hiz_depth_format() is the only implementation of this function,
so it makes sense to just call it directly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
These functions translate GLenum comparison operations into the hardware
enumerations. They should never be passed something other than a GL
comparison operator, or something is very broken.
Assertions seem more appropriate than fprintf.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Both intel_context.h and brw_defines.h have #defines for comparison
functions, stencil ops, blending logic ops, and blending factors.
They're exactly the same values, so it makes sense to pick one.
brw_defines.h is the logical place for this kind of stuff, so this patch
converts intel_state.c to use the set defined there.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
4258e3a2e1. At this point, it's unlikely that anyone's using the
right mix of new and old components to hit this path. Deleting it
removes an untested code path and cleans up the driver a bit.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Keith Packard <keithp@keithp.com>
This wasn't called from anywhere; presumably it was used to examine
brw_regs when debugging shader assembly. However, it prints registers
in a different notation than brw_disasm.c which everyone is used
to...which means I doubt anyone will want to use it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Having a header file for a single prototype seems rather excessive.
Plus, the actual function is in brw_clear.c, not intel_clear.c, so
there isn't even the .c/.h filename symmetry one might expect.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This was only used for BOs backed by system memory on i915. With that
gone, there's nothing that even sets source to non-zero, so this is
purely dead code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Commit cf31a19300 removed support for BOs
backed by system memory, as it was only useful for i915. However, it
removed a little too much code: intel_bufferobj_buffer() used to call
intel_bufferobj_alloc_buffer(), and after that commit, it didn't.
This led to NULL pointer dereferences in several test cases, such as
es3conform's transform_feedback_state_variables test.
This commit restores the allocation, preserving the original behavior.
It may not be the cleanest approach, but tidying should come later.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66432
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This eliminates built-in varyings such as gl_Color, gl_SecondaryColor,
gl_TexCoord, and gl_FogFragCoord if they are unused by the next stage or
not written at all (e.g. gl_TexCoord elements). The gl_TexCoord array is
broken down into separate vec4s if needed.
v2: - use a switch statement in varying_info_visitor::visit(ir_variable*)
- use snprintf
- disable the optimization for GLES2
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This ensures that inter-shader outputs and inputs are properly eliminated
across 3 or more shader stages. The behavior is unchanged with 2 or less
shader stages.
For example, elimination of unused FS inputs causes elimination of matching
GS outputs, which causes elimination of the GS inputs that were needed for
evaluation of the eliminated GS outputs, which causes elimination of
matching VS outputs. An unused FS input is all that's needed to trigger
this chain reaction.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
See my explanation in mtypes.h.
v2: don't do this in gallium
v3: also updated the comment at the gl_shader_type definition
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch adds texture() for isamplerCubeArray and usamplerCubeArray,
which were entirely missing.
It also makes texture() with a LOD bias fragment shader specific. The
main GLSL specification explicitly says that texturing with LOD bias
should not be allowed for vertex shaders.
Affects Piglit's ARB_texture_cube_map_array/compiler/tex_bias-01.vert.
which tries to use bias in a vertex shader. Currently, it expects this
to pass (so this patch regresses the test), but I've sent a patch to
reverse the expected behavior (so this patch would fix the updated test):
http://lists.freedesktop.org/archives/piglit/2013-June/006123.html
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
If reg->Register.Indirect is true then the immediate is not truly a
constant LLVM expression.
There is no performance regression in using LLVMBuildBitCast, as it will
fallback to LLVMConstBitCast internally when the argument is a constant.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Current implementation of ext_framebuffer_multisample_blit_scaled in
i965/blorp uses nearest filtering for multisample scaled blits. Using
nearest filtering produces blocky artifacts and negates the benefits
of MSAA. That is the reason why extension was not enabled on i965.
This patch implements the bilinear filtering of samples in blorp engine.
Images generated with this patch are free from blocky artifacts and show
big improvement in visual quality.
Observed no piglit and gles3 regressions.
V3:
- Algorithm used for filtering assumes a rectangular grid of samples
roughly corresponding to sample locations.
- Test the boundary conditions on the edges of texture.
V4:
- Clip texcoords and use conditional MOVs.
- Send texture dimensions as push constants.
- Remove the optimization in case of scaled multisample blits.
V5:
- Move mcs_fetch() inside the 'for' loop after computing pixel coordinates.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Acked-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We were incorrectly computing the buffer offset when using the
instances. The buffer offset is always equal to:
start_instance * stride + (instance_num / instance_divisor) *
stride
We were completely ignoring the start instance quite
often producing instances that completely wrong, e.g. if
start instance = 5, instance divisor = 2, then on the first
iteration it should be:
5 * stride, not (5/2) * stride as we'd have currently, and if
start instance = 1, instance divisor = 3, then on the first
iteration it should be:
1 * stride, not 0 as we'd have.
This fixes it and adjusts all the code to the changes.
Signed-off-by: Zack Rusin <zackr@vmware.com>
clipper invocations are computed earlier (of course
before the emittion) so this code was adding bogus
numbers to already computed clipper invocations.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Integers could easily overflow is the starting instance
was large enough. Instead of letting bogus counts through
set the instance to max if it overflown and let our
regular buffer overflow computation handle it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Our buffer overflow arithmetic was susceptible to integer
overflows which was the buffer overflow logic to break.
Lets use the llvm overflow intrinsics to check for integer
overflows while computing the stride/needed buffer size.
Signed-off-by: Zack Rusin <zackr@vmware.com>
We weren't taking into account the size of element
that is to be fetched, which meant that it was possible
to overflow the buffer reads if the stride was very
close to the end of the buffer, e.g. stride = 3, buffer
size = 4, and the element to be read = 4. This should
be properly detected as an overflow.
Signed-off-by: Zack Rusin <zackr@vmware.com>
In the generic Unix case use the "unsigned long" type instead of 32-bit
integers so that the type sizes are consistant on 64-bit machines between X11
and not-X11.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
eglplatform.h defaults to X11 on Unix unless told otherwise, so if we're doing a
build without any X11 support tell it so that we don't try including headers
that don't exist.
Also set GL_PC_FLAGS so that the definition is in egl.pc, so that applications
using EGL don't try to pull in X11 headers on systems where EGL was configured
without X11 support.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64959
Signed-off-by: Ross Burton <ross.burton@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The only reason the checks existed were paranoia, when I first
wrote the code I wasn't sure it was correct. Now that I am,
the asserts triggered when XBMC was dropping frames, so remove it.
NOTE: This is a candidate for the 9.1 branch.
The assembly parser can be used to load r300 assembly dumps
and run them through any of the r300 compiler passes.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound colorbuffers fulfill certain
conditions: a CMASK is required, we have to be able to create a clear
color value for the format and the texture mustn't contain multiple
images. Technically, it should be possible to support array textures
and cubemaps if all images are attached to the framebuffer,
but this does not appear to be common.
v2: fix fast clear check
v3: Marek: - disable fast clear with 128-bit formats, which are unsupported
- set tex->dirty_level_mask in r600_clear, so that the driver knows
the resource must be decompressed/expanded
- return early from r600_clear if there's nothing else to do
Signed-off-by: Marek Olšák <maraeo@gmail.com>
b04a295a4a removed seemingly unnecessary
code in get_query. Turns out this code could in fact be reached - while
timestamps are always binned, if there are no bins (which happens if fb
size is 0) then the rasterization query code filling this in is still
never executed.
So fix this up by filling in some timestamp, but do it at EndQuery time
not GetQuery time which should be more appropriate.
Makes piglit arb_timer_query-timestamp-get happy again.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
While i915 does have hardware contexts in hardware, we don't expect there
to ever be SW support for it (given that support hasn't even made it back
to gen5 or gen4).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Every driver left in Mesa that enables one also enables the other.
There's no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
In Mesa, this extension is implemented purely in software. Drivers may
*optionally* provide optimized paths. If a driver enables,
GL_ARB_texture_multisample, it gets GL_ARB_texture_storage_multisample
for free.
NOTE: This has the side effect of enabling the extension in Gallium
drivers that enable GL_ARB_texture_multisample.
v2 (Ken): Still prevent multisample texture targets in TexParameter for
implementations that don't support multisampling.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
In Mesa, this extension is implemented purely in software. Drivers may
*optionally* provide optimized paths.
NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
v2: Minor whitespace tidying (suggested by Brian).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This extension just provides some of the most basic software framework
for GLSL. Without GL_ARB_vertex_shader or GL_ARB_fragment_shader,
applications still cannot use GLSL. There's no value in
conditionalizing support for this extension.
NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This extension just provides some of the most basic software framework
for GLSL. Without GL_ARB_vertex_shader or GL_ARB_fragment_shader,
applications still cannot use GLSL. There's no value in
conditionalizing support for this extension.
NOTE: This has the side effect of enabling the extension in the radeon,
r200, and nouveau drivers.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver left in Mesa enables this extension all the time. There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver left in Mesa enables this extension all the time. There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver left in Mesa enables this extension all the time. There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Every driver left in Mesa enables this extension all the time. There's
no reason to let it be optional.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Commit bab755a made the implementation a no-op, and it was only ever
enabled by software rasterizers.
v2: Move the spec into docs/specs/OLD since it's now obsolete
(squashed patch from Andreas Boll)
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
_mesa_enable_sw_extensions enables all the extensions (and more) that
the others enable. Also, don't duplicate the DXTn checks.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This copy of the source file is only used for GEN >= 4, so extensions
that are enabled for GEN >= 4 are always enabled.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This copy of the source file is only used for GEN >= 4, so extensions
that are enabled for GEN >= 3 are always enabled.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This copy of the source file is only used for GEN <= 3, so remove the
dead code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
brw_wm_surface_state.c has gotten rather large and unwieldy. At this
point, it consists of two separate portions:
1. Surface format code
This includes the giant table of surface formats and what features
they support on each generation, as well as the code to translate
between Mesa formats and hardware formats.
This is used across all generations.
2. Binding table (SURFACE_STATE) related code.
This is the code to generate SURFACE_STATE entries for renderbuffers,
textures, transform feedback buffers, constant buffers, and so on, as
well as the code to assemble them into binding tables.
This is only used on Gen4-6; gen7_surface_state.c has Gen7+ code.
Since the two are logically separate, and one is reused on every
generation while the other is not, it makes a lot of sense to split
them out. It should also make finding code easier.
No code is changed by this patch. I simply copied the file then deleted
portions of both.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
On CIK, DB switches back to using per-surface tiling
parameters rather than the tile index used on SI.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Assertions are not sufficient to check for null pointers as they don't
show up in release builds. So, return ZeroVec/dummyReg instead of NULL
pointer in get_{src,dst}_register_pointer(). This should calm down the
warnings from static analysis tool.
Note: This is a candidate for the 9.1 branch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
If allocation fails in intel_miptree_create_layout(), don't proceed to
dereference the miptree. Return an early NULL.
Fixes static analysis error reported by Klocwork.
Note: This is a candidate for the 9.1 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This was just ignored (unless for some reason like unfilled polys draw was
handling this).
I'm not convinced of that code, putting the float for the clamp in the key
isn't really a good idea. Then again the other floats for depth bias are
already in there too anyway (should probably have a jit_context for the
setup function), so this is just a quick fix.
Also, the "minimum resolvable depth difference" used isn't really right as it
should be calculated according to the z values of the current primitive
and not be a constant (of course, this only makes a difference for float
depth buffers), at least for d3d10, so depth biasing is still not quite right.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
If there are queries active the opaque optimization reseting the bin needs to
be disabled.
(Not really tested since the bug was discovered by code inspection not
an actual test failure.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This patch fixes segfaults observed when enabling the post processing
features. When the format is not supported, or a texture cannot be
created, the code must gracefully handle failure and report the error to
the calling code for proper failure handling.
To accomplish this the following changes were made to the filters.h
prototypes:
- bool return for pp_init_func
- Added pp_free_func for filter specific resource destruction
Fixes segfaults from backtraces:
* util_destroy_blit
pp_free
* u_transfer_inline_write_vtbl
pp_jimenezmlaa_init_run
pp_init
This patch also uses tgsi_alloc_tokens to allocate temporary tokens in
pp_tgsi_to_state, instead of allocating the array on the stack. This
fixes the following stack corruption segfault in pp_run.c:
* _int_free
aaline_delete_fs_state
pp_free
Bug Number: 1021843
Reviewed-by: Brian Paul <brianp@vmware.com>
OpenGL doesn't support this but d3d10 does.
It is a bit of a pain as it is necessary to keep track of queries
still active at the end of a scene, which is also why I cheat a bit
and limit the amount of simultaneously active queries to (arbitrary)
16 (simplifies things because don't have to deal with a real list
that way). I can't think of a reason why you'd really want large
numbers of overlapping/nested queries so it is hopefully fine.
(This only affects queries which need to be binned.)
v2: don't copy remainder of array when deleting an entry simply replace
the deleted entry with the last one (order doesn't matter).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Previously lp_rast_begin_query commands were always inserted into each bin,
and re-issued if the scene was restarted, while lp_rast_end_query commands
were executed for each still active query at the end of tile rasterization.
Also, the ps_invocations and vis_counter were set to zero when the respective
command was encountered.
This however cannot work for multiple queries of the same type (note that
occlusion counter and occlusion predicate while different type were also
affected).
So, change the logic to always set the ps_invocations and vis_counter to zero
at the start of tile rasterization, and then use "start" and "end" per-thread
query values when encountering the begin/end query commands instead, which
should work for multiple queries of the same type. This also means queries do
not have to be reissued in a new scene, however they still need to be finished
at end of tile rasterization, so a list of queries still active at the end of
a scene needs to be maintained.
Also while here don't bin the queries which don't do anything in rasterization.
(This change does not actually handle multiple queries of the same type yet,
as the list of active queries is just a simple fixed array and setup can still
only have one query active per type.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Now that i915's forked off, they don't need to live in a shared directory.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
Acked-by: Adam Jackson <ajax@redhat.com>
(and I hear second hand that idr is OK with it, too)
Of this 15000 lines of code in intel/, we've identified 4000 lines that
are trivially unnecessary for i915, and another 1000 that are pointless for
i965, and expect to find more as time goes on. Split the i915 driver off,
so that we can continue active development on i965 without worrying about
breaking i915.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
Acked-by: Adam Jackson <ajax@redhat.com>
(and I hear second hand that idr is OK with it, too)
This has the (intended!) side effect that vertex shader inputs and
fragment shader outputs will appear in the IR in the same order that
they appeared in the shader code. This results in the locations being
assigned in the declared order. Many (arguably buggy) applications
depend on this behavior, and it matches what nearly all other drivers
do.
Fixes the (new) piglit test attrib-assignments.
NOTE: This is a candidate for stable release branches (and requires the
previous commit to prevent a regression in OpenGL ES 2.0 conformance
test stencil_plane_operation).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The checks to determine when the data can be uploaded in an interleaved
fashion can be tricked by certain data layouts. For example,
float data[...];
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 16, &data[0]);
glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 16, &data[4]);
glDrawArrays(GL_POINTS, 0, 1);
will hit the interleaved path with an incorrect size (16 bytes instead
of 32 bytes). As a result, the data for attribute 1 never gets
uploaded. The single element draw case is the only sensible case I can
think of for non-interleaved-that-looks-like-interleaved data, but there
may be others as well.
To fix this, make sure that the end of the element in the array being
checked is within the stride "window." Previously the code would check
that the begining of the element was within the window.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
The 20130624 version of glext.h changed this to match the
glMultiDrawElements() function which already had the extra const
qualifier.
Fixes warnings/errors that seem to vary from one compiler to the next.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
vec4_visitor::generate_code() switches on vec4_instruction::opcode and
calls into the brw_eu_emit.c layer to generate code for some of them.
It then has a default case which calls generate_vec4_instruction() to
handle the rest...which switches on opcode and handles the rest of the
cases.
The split apparently is that generate_code() handles the actual hardware
opcodes (BRW_OPCODE_*) while generate_vec4_instruction() handles the
virtual opcodes (SHADER_OPCODE_* and VS_OPCODE_*). But this looks
fairly arbitrary, and it makes more sense to combine the two switches.
This patch moves the cases from generate_code() into the helper function
so that generate_code() isn't as large.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Commit 526ffdfc03 attempted to generalize
the source register type assertions to allow D and UD. However, the
src1 and src2 assertions actually checked src0.type against D and UD due
to a copy and paste bug.
It also began setting the source and destination register types based on
dest.type, ignoring src0/src1/src2.type completely. BFE and BFI2 may
actually pass mixed D/UD types and expect them to be ignored, which is
arguably a bit sloppy, but not too crazy either.
This patch simply removes the source register assertions as those values
aren't used anyway. It also clarifies the comment above the block that
sets the register types.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Commit 526ffdfc03 relaxed the type
assertions in brw_alu3 to allow D/UD types (required by BFE and BFI2).
This lost us the strict type checking for MAD and LRP, which require
all four types to be float.
This patch adds a new ALU3F wrapper which checks these once again.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Over the last few years, the compiler has grown to support 7 different
language versions and 6 extensions that add new built-in types. With
more and more features being added, some of our core code has devolved
into an unmaintainable spaghetti of sorts.
A few problems with the old code:
1. Built-in types are declared...where exactly?
The types in builtin_types.h were organized in arrays by the language
version or extension they were introduced in. It's factored out to
avoid duplicates---every type only exists in one array. But that
means that sampler1D is declared in 110, sampler2D is in core types,
sampler3D is a unique global not in a list...and so on.
2. Spaghetti call-chains with weird parameters:
generate_300ES_types calls generate_130_types which calls
generate_120_types and generate_EXT_texture_array_types, which calls
generate_110_types, which calls generate_100ES_types...and more
Except that ES doesn't want 1D types, so we have a skip_1d parameter.
add_deprecated also falls into this category.
3. Missing type accessors.
Common types have convenience pointers (like glsl_type::vec4_type),
but others may not be accessible at all without a symbol table (for
example, sampler types).
4. Global variable declarations in a header file?
#include "builtin_types.h" in two C++ files would break the build.
The new code addresses these problems. All built-in types are declared
together in a single table, independent of when they were introduced.
The macro that declares a new built-in type also creates a convenience
pointer, so every type is available and it won't get out of sync.
The code to populate a symbol table with the appropriate types for a
particular language version and set of extensions is now a single
table-driven function. The table lists the type name and GL/ES versions
when it was introduced (similar to how the lexer handles reserved
words). A single loop adds types based on the language version.
Explicit extension checks then add additional types. If they were
already added based on the language version, glsl_symbol_table simply
ignores the request to add them a second time, meaning we don't need
to worry about duplicates and can simply list types where they belong.
v2: Mark uvecs and shadow samplers as ES3 only, and 1DArrayShadow as
unsupported in ES entirely. Add a touch more doxygen.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Using a random glsl_type convenience pointer as an array is a really bad
idea, for all the reasons mentioned in the previous commit.
The new glsl_type::bvec() function is simpler anyway.
Prevents breakage in the next commit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Currently, vector types are linked together closely: the glsl_type
objects for float, vec2, vec3, and vec4 are all elements of the same
array, in that exact order. This makes it possible to obtain vector
types via pointer arithmetic on the scalar type's convenience pointer.
For example, float_type + (3 - 1) = vec3.
However, relying on this is extremely fragile. There's no particular
reason the underlying type objects need to be stored in an array. They
could be individual class members, possibly with padding between them.
Then the pointer arithmetic would break, and we'd get bad pointers to
non-heap allocated data, causing subtle breakage that can't be detected
by valgrind. Cue insanity.
Or someone could simply reorder the type variables, causing us to get
the wrong type entirely. Also cue insanity.
Writing this explicitly is much safer. With the new helper functions,
it's a bit less code even.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch introduces new functions to quickly grab a pointer to a
vector type. For example:
glsl_type::bvec(4) returns glsl_type::bvec4_type
glsl_type::ivec(3) returns glsl_type::ivec3_type
glsl_type::uvec(2) returns glsl_type::uvec2_type
glsl_type::vec(1) returns glsl_type::float_type
This is less wordy than glsl_type::get_instance(GLSL_TYPE_BOOL, 4, 1),
which can help avoid extra word wrapping.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In glapi_priv.h we always need the typedef for the GLclampx type
since GL_OES_fixed_point is now defined in glext.h but the
GLclampx type is not. GLclampx is not used by anything in glext.h
but we need it for GL ES dispatch.
This is a huge patch because the structure of the file has been
changed.
The following extensions are new, however:
GL_AMD_interleaved_elements
GL_AMD_shader_trinary_minmax
GL_IBM_static_data
GL_INTEL_map_texture
GL_NV_compute_program5
GL_NV_deep_texture3D
GL_NV_draw_texture
GL_NV_shader_atomic_counters
GL_NV_shader_storage_buffer_object
GL_NVX_conditional_render
GL_OES_byte_coordinates
GL_OES_compressed_paletted_texture
GL_OES_fixed_point
GL_OES_query_matrix
GL_OES_single_precision
And these extensions were removed:
GL_FfdMaskSGIX
GL_INGR_palette_buffer
GL_INTEL_texture_scissor
GL_SGI_depth_pass_instrument
GL_SGIX_fog_scale
GL_SGIX_impact_pixel_texture
GL_SGIX_texture_select
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This prevents trampling beyond the end of the command stream during flushes.
NOTE: This is a candidate for the stable branches.
Reported-by: Christoph Bumiller <christoph.bumiller@speed.at>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
max_threads cannot be greater than 28. It is either 21 or 28.
Fixes "Logically dead code" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
We want to access the user buffer, if available, when primitive restart is
enabled and the restart index/primitive type is not natively supported.
And since we are handling index buffer uploads in the driver with this change,
we can also work around misalignment of index buffer offsets.
Rename ilo_finalize_states() to ilo_finalize_3d_states(), and bind
pipe_draw_info to the context when it is called. This saves us from having to
pass pipe_draw_info around in several places.
The polygon offset math used for triangles by the WM is "OffsetUnits * 2 *
MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference
for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated
slope from the GL spec, and '2' is this magic number from the original
i965 code dump that we deviate from the GL spec by because "it makes glean
work" (except that it doesn't, because of some hilarity with 0.5 *
approximately 2.0 != 1.0. go glean!).
This clipper code for unfilled polygons, on the other hand, was doing
"OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the
case of 16-bit depth visual (regardless the FBO's depth resolution), or
128 * MRD for 24-bit depth visual.
This change just makes the unfilled polygons behavior match the WM's
filled polygons behavior.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no reason to care about the window system visual's depth for
handling polygon offset in an FBO, and it could only lead to pain.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The separate function for the fallback checks wasn't particularly
clarifying things, so I put the improved checks in the caller. (Note that
the dropped _mesa_update_state() had already happened once at the start of
the caller)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I think we've all added instrumentation at one point or another to see
what's being called in blorp. Now you can quickly get output like:
Testing glCopyPixels(depth).
intel_hiz_exec depth clear to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
intel_hiz_exec hiz ambiguate to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit 551c991606 tried to avoid spilling
registers that were trivially colorable. But since we do optimistic
coloring, the top of the stack also contains nodes that are not trivially
colorable, so we need to consider them for spilling (since they are some
of our best candidates).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58384
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63674
NOTE: This is a candidate for the 9.1 branch.
It should never happen, but it does, and at this point, you're going to
_mesa_problem() and abort() (unless it's just in precompile). Give the
developer something to look at.
Some shells does not set variables sequentially in a statement i.e. "a=X
b=${a}" won't set "b" to "X" but empty value.
This patch introduce ";" to make sure "mo" is set properly before "lang"
assignment.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=471302
The last piece of code with an effect was flagging _NEW_BUFFERS. Only,
that is already flagged from everything that calls this function: Mesa GL
state updates flag it before even calling down into the driver, and the
calls from the DRI2 window system framebuffer update path end up flagging
it as part of the ResizeBuffers() hook.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The computed fields are updated appropriately as part of the normal draw
call path due to _NEW_BUFFERS being set.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For winsys FBOs, the bounds are appropriately updated immediately upon
_mesa_resize_framebuffer(). For user FBOs, they're updated as part of the
normal draw path state update due to _NEW_BUFFERS having been flagged.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Of the places noting a _NEW_DEPTH dependency, all were already checking
for _NEW_BUFFERS if appropriate.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2/3 packets depending on Stencil._Enabled already checked for
_NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The viewport (ctx->Viewport._WindowMap) doesn't change with drawable size
changes, and we update scissor (ctx->DrawBuffer->_Xmin and friends) on
_NEW_BUFFERS in things like brw_sf_state.c.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Things like brw_sf.c that need to know about orientation are already
recomputing on _NEW_BUFFERS.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
_mesa_resize_framebuffer(), the default value of the ResizeBuffers hook,
already checks for a window system framebuffer and walks the renderbuffers
calling AllocStorage().
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
_mesa_resize_framebuffer(), the default value of the ResizeBuffers hook,
already checks for a window system framebuffer and walks the renderbuffers
calling AllocStorage().
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This existed to tell the core not to call GetBufferSize, except that even
if you didn't set it nothing happened because nobody had a GetBufferSize.
v2: Remove two more instances of setting the field (from Brian)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Only the GDI driver set it to non-NULL any more, and that driver has a
Viewport hook that should keep it limping along as well as it ever has.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
commit 26d86d26f9 added
gl_shader_program::UniformLocationBaseScale. According to the code
comments in that commit, UniformLocationBaseScale "must be >=1".
UniformLocationBaseScale is of type unsigned. Coverity reported a "Macro
compares unsigned to 0" defect as well.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The function does array bounds checking. Note, this exposes a
bug in the svga_mark_surface_dirty() function: we're calling
svga_age_texture_view() with a texture slice instead of mipmap
level. This can lead to a failed assertion. That'll be fixed next.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
- use mgwhelp -- the successor for bfdhelp which does not have a hard
dependency on BFD, and works on 64bits.
- use a macro instead of hand-typing to dispatch DbgHelp functions
- dump line numbers
- dump module names when symbols are not available
- support 64bits.
- add comments
Reviewed-by: Brian Paul <brianp@vmware.com>
Because our code couldn't handle it we were skipping rendering
if we detected overflows. According to the spec we should
still render but with all 0 vertices, which is what the llvm
code already does. So for the llvm paths lets enable processing
even if an overflow condition has been detected.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Before we could easily overflow if start+count>max integer. To
avoid it we can just iterate over the count. This makes sure
that we never crash, since most of the overflow conditions
is already handled.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Make pass_render_condition() available for blitter, and check for render
condition in (and only in) clear(), clear_render_target(), and
clear_depth_stencil().
Add ilo_shader_select_kernel_routing() to construct 3DSTATE_SBE. It is called
in ilo_finalize_states(), rather than in create_fs_state(), as it depends on
VS/GS and rasterizer states.
With this change, ilo_shader_internal.h is no longer needed for
ilo_gpe_gen6.c.
This allows us to remove ilo_shader_internal.h from ilo_gpe_gen7.c. The
unfinished code in 3DSTATE_DS, 3DSTATE_HS, and INTERFACE_DESCRIPTOR_DATA are
partly or entirely removed.
The unmodified pipe_stream_output_info describes its outputs as if they are in
TGSI_FILE_OUTPUT. Remap the register indices to where they appear in the VUE.
TGSI_SEMANTIC_PSIZE needs a little care because it is at the W channel.
When a new VS kernel is generated, a newly added function,
ilo_gpe_init_vs_cso(), is called to construct 3DSTATE_VS command in
ilo_shader_cso. When the command needs to be emitted later, we copy the
command from the CSO instead of constructing it dynamically.
Add ilo_shader_get_type() to query the type (PIPE_SHADER_x) of the shader.
Add ilo_shader_get_kernel_offset() and ilo_shader_get_kernel_param() to query
the cache offset and various kernel parameters of the selected kernel.
Add ilo_shader_select_kernel() to replace the dependency table,
ilo_shader_variant_init(), and ilo_shader_state_use_variant().
With the changes, we no longer need to include ilo_shader_internal.h in
ilo_state.c.
Replace ilo_shader_state_create() by
ilo_shader_create_vs()
ilo_shader_create_gs()
ilo_shader_create_fs()
ilo_shader_create_cs()
Rename ilo_shader_state_destroy() to ilo_shader_destroy(). The old
ilo_shader_destroy() is renamed to ilo_shader_destroy_kernel().
To prevent segfaults in the AA line module, the code will check for a
valid pointer to the aaline_stage in the draw context.
Fixes segfault from backtrace:
* aaline_stage_from_pipe
aaline_delete_fs_state
Reviewed-by: Brian Paul <brianp@vmware.com>
swrastGetImage rounds the pitch up to 4 bytes for compatibility reasons
that are explained in drisw_glx.c:bytes_per_line, so drisw_update_tex_buffer
must do the same.
Fixes window skew seen while running firefox over vnc on a 16-bit screen.
NOTE: This is a candidate for the stable branches.
[ajax: fixed typo in comment]
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Squashed commit of the following:
commit 0857a7e105bfcbc4d1431b2cc56612094c747ca3
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:07 2013 -0400
gallivm: Fix lp_build_rgba8_to_fi32_soa for big endian
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 0d65131649a8aa140e2db228ba779d685c4333e3
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:07 2013 -0400
gallivm: Fix big-endian machines
This adds a bit-shift count to the format table, and adds the concept of
vector or bitwise alignment on gathers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 9740bda9b7dc894b629ed38be9b51059ce90818f
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:07 2013 -0400
llvmpipe: Fix convert_to_blend_type on big-endian
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit ae037c2de0f029e4e99371c0de25560484f0d8df
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
util: Convert color pack to packed formats
This fixes them on big-endian.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 5b05ac0c89ae092ea8ba5bba9f739708d7396b5c
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
graw-xlib: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 51396e7d098cb6ff794391cf11afe4dbf86dbea0
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
format: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 417b60bc66eb450e68a92ab0e47f76e292b385e6
Author: Adam Jackson <ajax@redhat.com>
Date: Tue Jun 18 12:25:06 2013 -0400
st/dri: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 0934b2e022a5e0847d312c40734e2b44cac52fd8
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
st/xlib: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit a307ea3c3716a706963acce7966b5e405ba11db9
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
gbm: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 53eebdd253e1960a645ea278f31d7ef6a6cf4aeb
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
tests: Convert to packed formats
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 2f77fe3ee524945eacd546efcac34f7799fb3124
Author: Adam Jackson <ajax@redhat.com>
Date: Tue Jun 18 13:07:37 2013 -0400
gallium: Document packed formats
Signed-off-by: Adam Jackson <ajax@redhat.com>
commit 1f1017159ce951f922210a430de9229f91f62714
Author: Richard Sandiford <r.sandiford@uk.ibm.com>
Date: Tue Jun 18 12:25:06 2013 -0400
gallium: Introduce 32-bit packed format names
These are for interacting with buffers natively described in terms of
bit shifts, like X11 visuals:
uint32_t xyzw8888 = (x << 0) | (y << 8) | (z << 16) | (w << 24);
Define these in terms of (endian-dependent) aliases to the array-style
format names.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <r.sandiford@uk.ibm.com>
commit 6cc7ab1ee66ed668da78c1d951dfd7782b4e786a
Author: Adam Jackson <ajax@redhat.com>
Date: Mon Jun 3 12:10:32 2013 -0400
gallium: Document format name conventions
v2:
- Fix a channel name thinko (Michel Dänzer)
- Elaborate on SCALED versus INT
- Add links to DirectX and FOURCC docs
Signed-off-by: Adam Jackson <ajax@redhat.com>
commit df4d269e7fb62051a3c029b84147465001e5776e
Author: Adam Jackson <ajax@redhat.com>
Date: Tue Jun 18 12:25:06 2013 -0400
gallivm: Remove all notion of byte-swapping
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The result isn't always 0 in this case (depends on query type),
so instead of special casing this just use the ordinary path (should result
in correct values thanks to initialization in query_begin/end), just
skipping the fence wait.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This fixes the bytestream parsing of mpeg-1 stream, but still leaves
open a number of issues with the interpretation:
- IDCT mismatch control is not correct for MPEG-1.
- Slices do not have to start and end on the same horizontal row of macroblocks.
- picture_coding_type = 4 (D-pictures) is not handled.
- full_pel_*_vector is not handled.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
The results of a bary.f do not appear to be immediatley available, but
there is no explicit sync bit. Instead the compiler must just ensure
that there are a minimum number of instructions following the bary
before use of the result of the bary. We aren't clever enough for that
so just throw in some nop's.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
If we are accumulating result into tmp.x, and need a mov to final
destination, we want to move the .x component into all of the components
enabled from the read dest's writemask, ie. we want:
MOV dst.xyzw tmp.xxxx
rather than:
MOV dst.xyzw tmp.xyzw
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This code had no relation to ir_to_mesa.cpp, since it was also used by
intel and state_tracker, and most of it was duplicated with the standalone
compiler (which has periodically drifted from the Mesa copy).
v2: Split from the ir_to_mesa to shaderapi.c changes.
Acked-by: Paul Berry <stereotype441@gmail.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There was nothing ir_to_mesa-specific about this code, but it's not
exactly part of the compiler's core turning-source-into-IR job either.
v2: Split from the ir_to_mesa to glsl/ commit, avoid renaming the sh
variable.
Acked-by: Paul Berry <stereotype441@gmail.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I noticed this while trying to merge code with the builtin compiler, which
does set it.
Note that this causes two regressions in piglit in
default-precision-sampler.* which try to link without a vertex or fragment
shader, due to being run under the desktop glslparsertest binary (using
ARB_ES3_compatibility) that doesn't know about this requirement.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We were duplicating this code all over the place, and they all would need
updating for the next set of shader targets.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We have ir->print() to do the old declaration of a visitor and having the
IR accept the visitor (yuck!). And now you can call _mesa_print_ir()
safely anywhere that you know what an ir_instruction is.
A couple of missing printf("\n")s are added in error paths -- when an
expression is handed to the visitor, it doesn't print '\n' (since it might
be a step in printing a whole expression tree).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
No more forgetting to #include "ir_print_visitor.h" when doing temporary
debug code, or forgetting and leaving it in after removing your temporary
debug code. Also, available from C code so you don't need to move the
caller to C++ just to call it (see also: ir_to_mesa.cpp).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Based from the code from the good old python state tracker.
Extremely handy to diagnose regressions in state trackers.
Reviewed-by: Brian Paul <brianp@vmware.com>
Not used yet but there's a couple of places in llvmpipe which should use this
(occlusion count is currently very inefficent if there's no cpu popcnt
instruction).
Handle PIPE_QUERY_GPU_FINISHED and PIPE_QUERY_TIMESTAMP_DISJOINT, and
also fill out the ps_invocations and c_primitives from the
PIPE_QUERY_PIPELINE_STATISTICS (the others in there should already
be handled). Note that ps_invocations isn't pixel exact, just 16 pixel
exact but I guess it's better than nothing.
Doesn't really seem to work correctly but there's probably bugs elsewhere.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The driver can do render_condition but wasn't handling the occlusion
and so_overflow predicates (though the latter might not work yet due
to gs support).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The semantics didn't really make sense, not really matching neither d3d9
(though the docs are all broken there) nor d3d10. So make it match d3d10
semantics, which actually gives meaning to the "disjoint" part.
Drivers are fixed up in a very primitive way, I have no idea what could
actually cause the counter to become unreliable so just always return
FALSE for the disjoint part.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Move some functions from the svga_tgsi_insn.h header into the
svga_tgsi_insn.c file since they're only used there. Plus, add
comments and fix formatting.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The new code makes the shader cache manages all shaders and be able to upload
all of them to a caller-provided bo as a whole.
Previously, we uploaded only the bound shaders. When a different set of
shaders is bound, we had to allocate a new kernel bo to upload if the current
one is busy.
When doing blit using the 3D engine, the rasterizer cso may be NULL.
Ported from nvc0 commit 8aa8b0539.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We need to set up a handler for the global_remove event that gets sent
out when a global gets removed. Without the handler we end up calling
a NULL pointer.
https://bugs.freedesktop.org/show_bug.cgi?id=65910
NOTE: This is a candidate for the stable branches.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
When rendering to a texture with BaseLevel set, the miptree may be laid
out such that BaseLevel is in level 0 of the miptree (to avoid wasting
memory on unused levels between 0 and BaseLevel-1). In that case, we
have to shift our render target's level down to the appropriate level of
the smaller miptree.
The WebGL test in combination with a meta code relating to
glGenerateMipmap also triggered a similar failure scenario.
This GPU hang regression was introduced by c754f7a8.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65324
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This reverts commit 41966fdb3b.
While it's a lot cleaner it causes regressions because
the draw interface is always called from the draw functions
of the drivers (because the buffers need to be mapped) which
means that the stream output buffers endup being cleared on
every draw rather than on setting.
Signed-off-by: Zack Rusin <zackr@vmware.com>
honor render_condition for clear_render_target and clear_depth_stencil.
Also add minimal support for occlusion predicate, though it can't be active
at the same time as an occlusion query yet.
While here also switchify some large if-else (actually just mutually
exclusive if-if-if...) constructs.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For conditional rendering this makes it possible to skip rendering
if either the predicate is true or false, as supported by d3d10
(in fact previously it was sort of implied skip rendering if predicate
is false for occlusion predicate, and true for so_overflow predicate).
There's no cap bit for this as presumably all drivers could do it trivially
(but this patch does not implement it for the drivers using true
hw predicates, nvxx, r600, radeonsi, no change is expected for OpenGL
functionality).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Add ilo_gpe_init_zs_surface() to construct
3DSTATE_DEPTH_BUFFER
3DSTATE_STENCIL_BUFFER
3DSTATE_HIER_DEPTH_BUFFER
at surface creation time. This allows fast state emission in draw_vbo().
This gets us support for blitting to attachment types other than
textures.
v2: fix up comments from review by Kenneth.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Now any caller (such as glCopyPixels()) can benefit from it, and it only
changes the correct subset of the destination instead of a whole teximage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Apparently we don't have any piglit tests for this, because it would have
assertion failed in a debug build, or just rendered wrong in a non-debug
build if the destination wasn't covering whole tiles.
v2: Use the new macros.
Reviewed-by: Paul Berry <stereotype441@gmail.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
We're going to add more BCS_SWCTRL setup instances soon, and you have to
be careful to have the set and restore atomic with the rendering that's
done, so that our state doesn't leak out to other rendering processes.
v2: Rewrite the patch to have batch begin/advance macros so that magic
numbers don't get sprinkled around (and so you don't mix up your
do-I-need-to-reset vs what-do-I-reset-to logic, which I nearly did in
the next patch when first writing it)
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Intel had brokenness here, and I'd like to continue moving Mesa toward
hiding 1D_ARRAY's ridiculousness inside of the core, like we did with
MapTextureImage. Fixes copyteximage 1D_ARRAY on intel.
There's still an impedance mismatch in meta when falling back to read and
texsubimage, since texsubimage expects coordinates into 1D_ARRAY as
(width, slice, 0) instead of (width, 0, slice).
v2: Fix offset of scanline reads from the source. (Thanks Brian!), replace
dd.h comment with Paul's text and replace early exit with an assert.
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Paul Berry <stereotype441@gmail.com> (v1)
I noticed this code didn't work as advertised while doing some passing around
of TGSI shaders and trying to reparse them, and things failing.
This seems to fix it here for at least the small test case I hacked into a
graw test.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 1f82bf12ed inadvertently broke it, checking for __IEEE_FLOAT on all
Alpha machines instead of only on VMS as before.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
Signed-off-by: Sven Joachim <svenjoac@gmx.de>
Fixes window skew seen while running gnome on a 16-bit screen over vnc.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Fixes a crash seen while running gnome on a 16-bit screen over vnc.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
byteswap.h and bswap_32 aren't portable, replace them with calls to
gallium's util_bswap32 as suggested by Mark Kettenis. Lets these files
build on OpenBSD.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
gl can use elts without setting indices, in which case
our eltMax was set to 0 and always invoking the overflow
condition. So by default set eltMax to maximum, it will
be curbed by draw_set_indexes (if it ever comes) and if
not then it will let gl's glVertexPointer/glDrawArrays
work correctly. Fixes piglit's
triangle-rasterization-overdraw test.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Moves clearing of the draw so target buffers to the draw
module. They had to be cleared in the drivers before
which was quite messy.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Port BLT code in ilo_blit.c to BLT-based blitting methods of ilo_blitter. Add
BLT-based clears. The latter is verifed with util_clear(), but it is not in
use yet.
Primitive restart with an arbitrary cut index was first supported as of
Haswell. It's very doubtful that they'd take that away in future
hardware, so we may as well alter the check now.
The PRM suggests a larger layout, mostly to support having
gl_ClipDistance[] somewhere predictable for the fixed-function clipper
-- but it didn't actually arrive in Gen5.
Just use the same layout for both Gen4 and Gen5.
No Piglit regressions.
Improves performance in CS:S Video Stress Test by ~3%.
V2: - Remove now-useless function for determining the SF URB read offset
- Remove now-unused BRW_VARYING_SLOT_POS_DUPLICATE
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Required by ARB_shading_language_420pack. Note that the 420pack spec
incorrectly specifies their values as (Min, Max) = (-7, 8) when they
should be (-8, 7) as listed in the GLSL 4.30 and ESSL 3.0 specs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Assert that we do not support user vertex/index/constant buffers. Issue a
warning when a sampler view is created for a resource without
PIPE_BIND_SAMPLER_VIEW.
The temporary texture should have either PIPE_BIND_RENDER_TARGET or
PIPE_BIND_DEPTH_STENCIL set in addition to PIPE_BIND_SAMPLER_VIEW.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
There are strict limits on those registers. Define the maximums
and use them instead of magic numbers. Also allows us to add
some extra sanity checks.
Suggested by Brian.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We don't need the clamped variable, because we can just
return early. We should also do the regular culling after
the distance culling passes.
All spotted by Brian.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
When a resource is busy and is mapped with
PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE, the underlying bo is replaced. We need
to mark states affected by the resource dirty.
With this change, we no longer have to emit vertex buffers and index buffer
unconditionally.
Even with hardware contexts, since we do not pin resources, we have to re-emit
the states so that the resources are referenced (by cp->bo) and their offsets
are updated in case they are moved. This also allows us to elimiate cp flush
in is_bo_busy().
Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE
in macros.h computed incorrect results for inputs in the range
0x3f7f0000 (=0.99609375) to 0x3f7f7f80 (=0.99803924560546875)
inclusive. 0x3f7f7f80 is the IEEE float value that results in 254.5
when multiplied by 255. With rounding mode "round to closest even
integer", this is the largest float in the range 0.0-1.0 that is
converted to 254 by the generic implementation of
UNCLAMPED_FLOAT_TO_UBYTE. The IEEE float optimized version
incorrectly defined the cut-off for mapping to 255 as 0x3f7f0000
(=255.0/256.0). The same bug was present in the function
float_to_ubyte in u_math.h.
Fix: The proposed fix replaces the incorrect cut-off value by
0x3f800000, which is the IEEE float representation of 1.0f. 0x3f7f7f81
(or any value in between) would also work, but 1.0f is probably
cleaner.
The patch does not regress piglit on llvmpipe and on i965 on sandy
bridge.
Tested-by Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Page flipping generates an invalidate event every frame, causing reallocations
of all private resources (MSAA and depth-stencil).
Reusing the resources may improve performance (especially under memory
pressure).
Reviewed-by: Brian Paul <brianp@vmware.com>
We have to use pipe->blit, not resource_copy_region, so that the read buffer
is resolved if it's multisampled. I also removed the CPU-based copying,
which just did format conversion (obsoleted by the blit).
Also, the layer/slice/face of the read buffer is taken into account (this was
ignored).
Last but not least, the format choosing is improved to take float and integer
read buffers into account.
Reviewed-by: Brian Paul <brianp@vmware.com>
There were 2 issues with it:
- resource_copy_region doesn't allow different sample counts of both src
and dst, which can occur if we blit between a window and a FBO, and
the window has an MSAA colorbuffer and the FBO doesn't.
(this was the main motivation for using pipe->blit)
- blitting from or to a non-zero layer/slice/face was broken, because
rtt_face and rtt_slice were ignored.
blit_copy_pixels is now used even if the formats and orientation of
framebuffers don't match.
Reviewed-by: Brian Paul <brianp@vmware.com>
We did downsample (=resolve) MSAA resources to make ReadPixels work with MSAA
GLX visuals, which was enough for read-only color-only transfers.
This commit makes write color transfers and depth-stencil transfers work
in a similar manner. It does downsampling in transfer_map and upsampling
in transfer_unmap.
Reviewed-by: Brian Paul <brianp@vmware.com>
There isn't any difference between 32_FLOAT and 32_*INT in vertex fetching.
Both of them don't do any format conversion.
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously we would generate uniform locations as (slot << 16) +
array_index. We do this to handle applications that assume the location
of a[2] will be +1 from the location of a[1]. This resulted in every
uniform location being at least 0x10000. The OpenGL 4.3 spec was
amended to require this behavior, but previous versions did not require
locations of array (or structure) members be sequential.
We've now encountered two applications that assume uniform values will
be "small." As far as we can tell, these applications store the GLint
returned by glGetUniformLocation in a int16_t or possibly an int8_t.
THIS BEHAVIOR IS NOT GUARANTEED OR IMPLIED BY ANY VERSION OF OpenGL.
Other implementations happen to have both these behaviors (sequential
array elements and small values) since OpenGL 2.0, so let's just match
their behavior.
Fixes "3D Bowling" on Android.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
This is used by _mesa_uniform_merge_location_offset and
_mesa_uniform_split_location_offset to determine how the base and offset
are packed. Previously, this value was hard coded as (1U<<16) in those
functions via the shift and mask contained therein. The value is still
(1U<<16), but it can be changed in the future.
The next patch dynamically generates this value.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
Use new util_fill_box helper for util_clear_render_target.
(Also fix off-by-one map error.)
v2: handle non-zero z correctly in new helper
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED
for miptrees that are capable of supporting fast color clears. This
will have no effect on buffers that don't undergo a fast color clear;
however, for buffers that do undergo a fast color clear, an MCS
miptree will be allocated (at the time of the first fast clear), and
will be used thereafter.
Reviewed-by: Eric Anholt <eric@anholt.net>
In certain circumstances the memory region underlying a miptree is
shared with other miptrees, or with other code outside Mesa's control.
This happens, for instance, when an extension like GL_OES_EGL_image or
GLX_EXT_texture_from_pixmap extension is used to associate a miptree
with an image existing outside of Mesa.
When this happens, we need to disable fast color clears on the miptree
in question, since there's no good synchronization mechanism to ensure
that deferred clear writes get performed by the time the buffer is
examined from the other miptree, or from outside of Mesa.
Fortunately, this should not be a performance hit for most
applications, since most applications that use these extensions use
them for importing textures into Mesa, rather than for exporting
rendered images out of Mesa. So most of the time the miptrees
involved will never experience a clear.
v2: Rework based on the fact that we have decided not to use an
accessor function to protect access to the region.
Reviewed-by: Eric Anholt <eric@anholt.net>
Resolve color buffers that have been fast-color cleared:
1. before texturing from the buffer (brw_predraw_resolve_buffers())
2. before using the buffer as the source in a blorp blit
(brw_blorp_blit_miptrees())
3. before mapping the buffer's miptree (intel_miptree_map_raw(),
intel_texsubimage_tiled_memcpy())
4. before accessing the buffer using the hardware blitter
(intel_miptree_blit(), do_blit_bitmap())
v2: Rework based on the fact that we have decided not to use an
accessor function to protect access to the region.
Reviewed-by: Eric Anholt <eric@anholt.net>
We already had code in intel_downsample_for_dri2_flush() for
downsampling front and back buffers when multisampling was in use.
This patch extends that function to perform fast color clear resolves
when necessary.
To account for the additional functionality, the function is renamed
to simply intel_resolve_for_dri2_flush().
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch implements the "render target resolve" blorp operation.
This will be needed when a buffer that has experienced a fast color
clear is later used for a purpose other than as a render target
(texturing, glReadPixels, or swapped to the screen). It resolves any
remaining deferred clear operation that was not taken care of during
normal rendering.
Fortunately not much work is necessary; all we need to do is scale
down the size of the rectangle primitive being emitted, run the
fragment shader with the "Render Target Resolve Enable" bit set, and
ensure that the fragment shader writes to the render target using the
"replicated color" message. We already have a fragment shader that
does that (the shader that we use for fast color clears), so for
simplicity we re-use it.
Reviewed-by: Eric Anholt <eric@anholt.net>
The fragment shaders that to do color clears will be re-used to
perform so-called "render target resolves" (the resolves associated
with fast color clears). To prepare for that, this patch expands the
class hierarchy for blorp params by adding
brw_blorp_const_color_params (which will be used for all blorp
operations where the fragment shader outputs a constant color).
Some other data structures and functions were also renamed to use
"const_color" nomenclature where appropriate.
Reviewed-by: Eric Anholt <eric@anholt.net>
Since we defer allocation of the MCS miptree until the time of the
fast clear operation, this patch also implements creation of the MCS
miptree.
In addition, this patch adds the field
intel_mipmap_tree::fast_clear_color_value, which holds the most recent
fast color clear value, if any. We use it to set the SURFACE_STATE's
clear color for render targets.
v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree. Generate a
perf_debug message if clearing to a color that isn't compatible with
fast color clear. Fix "control reaches end of non-void function"
build warning.
Reviewed-by: Eric Anholt <eric@anholt.net>
On Gen7+, MCS buffers are used both for compressed multisampled color
buffers and for "fast clear" of single-sampled color buffers.
Previous to this patch series, we didn't support fast clear, so we
only used MCS with multisampled bolor buffers.
As a first step to implementing fast clears, this patch modifies the
code that sets up SURFACE_STATE so that it configures the MCS buffer
whenever it is present, regardless of whether we are multisampling or
not.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch includes code to update the fast color clear state
appropriately when rendering occurs. The state will also need to be
updated when a fast clear or a resolve operation is performed; those
state updates will be added when the fast clear and resolve operations
are added.
v2: Create a new function, intel_miptree_used_for_rendering() to
handle updating the fast color clear state when rendering occurs.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field in the i915 driver). This should make it a
bit easier to implement fast color clears without undue risk to i915.
Reviewed-by: Eric Anholt <eric@anholt.net>
When processing a buffer received from the X server,
intel_process_dri2_buffer() examines intel_region::name to determine
whether it's received a brand new buffer, or the same buffer it
received from the X server the last time it made a request.
However, this didn't work properly, because in the call to
intel_miptree_create_for_dri2_buffer(), we create a fresh intel_region
object to represent the buffer, and this was causing us to forget the
buffer's previous name.
This patch fixes things by copying over the region name when creating
the fresh intel_region object.
At the moment, this is just a minor performance optimization.
However, when fast color clears are added, it will be necessary to
ensure that the fast color clear state for a buffer doesn't get
discarded the next time we receive that buffer from the X server.
Reviewed-by: Eric Anholt <eric@anholt.net>
There is really nothing in struct intel_bo, and having it alias drm_intel_bo
makes the winsys impose almost zero overhead.
We can make the overhead gone completely by making the functions static
inline, if needed.
The motivation is to kill tiling and pitch in struct intel_bo. That requires
us to make tiling and pitch not queryable, and be passed around as function
parameters.
See two commits ago for the rationale. This allows us to delete the
whole gen7_cc_state.c file.
This does move these commands before the depth stall flushes from
brw_emit_depthbuffer, which may be a problem. The documentation for
3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are required
before changing any depth/stencil buffer state, but explicitly lists
3DSTATE_DEPTH_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER,
and 3DSTATE_CLEAR_PARAMS. It does not mention this particular packet
(_3DSTATE_DEPTH_STENCIL_STATE_POINTERS).
No observed Piglit regressions on Sandybridge or Ivybridge.
Together with the last two commits, this makes a cairo-gl benchmark
faster by 0.324552% +/- 0.258355% on Ivybridge. No statistically
significant change on Sandybridge. (Thanks to Eric for the numbers.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we would:
1. Emit the new indirect state.
2. Flag CACHE_NEW_BLEND_STATE.
3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a
pointer to the new indirect state.
This is rather cumbersome: it requires two state atoms instead of one,
and there's a strict ordering dependency in the list. Plus, the code
gets spread across two functions (or even files in the case of Gen7+).
Gen7+ has a packet to update just the blend state pointer, so it makes a
lot of sense to simply emit that right away. Gen6 has a combined packet
which updates blending, the color calculator, and depth/stencil state;
however, each can still be modified independently.
This drops the Gen6 micro-optimization where we tried to only emit one
packet that changed all three states. State updates are pretty cheap.
CACHE_NEW_BLEND_STATE is no longer necessary, so drop it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Works similarly to clip distance. If the cull distance is negative
for all vertices against a specific plane then the primitive
is culled.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cull distance is analogous to clip distance. If a register is
given this semantic, then the values in it are assumed to be a
float32 distance to a plane. Primitives will be completely
discarded if the plane distance for all of the vertices in
the primitive are < 0.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We need to figure out the number of invocations of the clipper
before the emit, because in the emit we are after clipping
where the number of primitives will be equal to number of clipper
invocations minus the clipped primitives. So our computations
were always off by the number of clipped primitives.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Draw depended on clip_plane_enable being set in the rasterizer
to use clipdistance registers for clipping. That's really
unfriendly because it requires that rasterizer state to have
variants for every shader out there. Instead of depending on
the rasterizer lets extract the info from the available state:
if a shader writes clipdistance then we need to use it and we
need to clip using a number of planes equal to the number
of writen clipdistance components. This way clipdistances
just work.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
we were always fetching the info from the vertex shader, but if
geometry shader is present it should be used as the source of
that info.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Fixes piglit texture-packed-formats regression. We need to implement
more XBGR formats here eventually, but many are UINT/SINT formats
which swrast doesn't handle yet anyway (integer textures).
Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=64935
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Set env var RADEON_VA=0 to disable VM on Cayman/Trinity.
Useful for debugging.
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Having figured out what was going on with piglit fbo-depth copypixels
GL_DEPTH_COMPONENT32F (falling all the way back to swrast on CopyPixels to
a float depth buffer), I'm not inclined to fix the problem currently but
it seems worth saving someone else the debug time.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We do a lot of multiplies by 3 or 4 for skinning shaders, and we can avoid
the sequence if we just move them into the right argument of the MUL.
On pre-IVB, this means reliably putting a constant in a position where it
can't be constant folded, but that's still better than MUL/MACH/MOV.
Improves GLB 2.7 trex performance by 0.788648% +/- 0.23865% (n=29/30)
v2: Fix test for pre-sandybridge.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
This is a trivial port of 1d6ead3804 from
the FS.
No significant performance difference on trex (misplaced the data, but it
was about n=20).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is different from how we do it in the FS - we are using MAD even when
some of the args are constants, because with the relatively unrestrained
ability to schedule a MOV to prepare a temporary with that data, we can
get lower latency for the sequence of instructions.
No significant performance difference on GLB2.7 trex (n=33/34), though it
doesn't have that many MADs. I noticed MAD opportunities while reading
the code for the DOTA2 bug.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
draw_vertex_buffer declared the size field to be a size_t, but the LLVM
code used an int32 instead. This caused problems on big-endian 64-bit
targets, because the first 32-bit chunk of the 64-bit size_t was always 0.
In one sense size_t seems like a good choice for a size, so one fix
would have been to try to get the LLVM code to use the equivalent of
size_t too. However, in practice, the size is taken from things like ~0
or width0, both of which are int-sized, so it seemed simpler to make the
size field int-sized as well.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Without this, llvmpipe ends up giving a zero size to all uncompressed textures
on non-x86 systems, since align() cannot handle a 0 alignment.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
lp_build_add and lp_build_sub have fallback code for cases
that cannot be handled by known intrinsics. For UNORM formats,
this code was using modulo rather than saturating arithmetic.
This fixes some rendering issues for a gnome session on System z.
It also fixes various piglit tests on z, such as
spec/ARB_color_buffer_float/GL_RGBA8-render.
The patch deliberately doesn't tackle the more complicated
SNORM case.
Tested against piglit on x86_64 and System z with no regressions.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Now that Gen6+ relies on hardware contexts, we don't need to record an
occlusion query value at the end of each batch. That means we no longer
need to reserve space for the absurd number of PIPE_CONTROLs required to
do that on Sandybridge.
See commit 4e087de51a, which bumped this
up to 60 bytes. This is not quite a revert, as it uses 24 bytes instead
of 16, and saves the comments. As far as I can tell, the old value of
16 bytes was just wrong, so we shouldn't go back to that.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
We always allocate the maximum amount of space and never change it, so
it makes sense to do it once. Programming it on startup also lets us
skip re-programming it from BLORP.
This removes a tiny amount of overhead from our drawing loop.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This removes a tiny bit of code from our drawing loop.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Now that we emit invariant state at startup (and never select the media
pipeline), the 3D pipeline will always already be selected, even if BLORP
is the first operation. So this is unnecessary.
v2: Fix unused variable warning (intel_context is no longer used).
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Now that we have hardware contexts, we can safely initialize our GPU
state once at startup, rather than needing a state atom with the
BRW_NEW_CONTEXT flag set.
This removes a tiny bit of code from our drawing loop.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The existing code already returned a boolean; this just clarifies that.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
We already implemented this for ES3, so we just need to turn it on.
Fixes 6 Piglit tests:
spec/glsl-1.50/compiler/built-in-functions/determinant-mat[234].{vert,frag}
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Page 17 of the GLSL 1.50.11 specification states:
"There is a built-in macro definition for each profile the
implementation supports. All implementations provide the following
macro:
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we only supported "#version 150". This patch recognizes
"compatibility" to give the user a more descriptive error message.
Fixes Piglit's version-150-core-profile test.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
If we didn't successfully parse the #version line, there's no point in
continuing with parsing and compiling: it's already failed.
Furthermore, it can actually be harmful: right after handling #version,
we call _mesa_glsl_initialize_types(), which checks state->es_shader and
language_version. If it isn't valid, it hits an assertion failure.
Fixes Piglit's "invalid-version-es." When processing "#version 110 es",
our code set state->es_shader and state->language_version = 110. It
then properly determined that this was invalid and flagged an error.
Since we continued anyway, we hit the assertion mentioned above.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The GPU (at least a3xx, but I think also a2xx) can render directly to
memory, bypassing tiling. Although it can't do this if blend, depth,
and a few other features of the pipeline are enabled. This direct
memory mode can be faster for some sorts of operations, such as simple
blits. In particular, this significantly speeds up XA by avoiding to
pull the entire dest pixmap into GMEM, render tiles, and write it all
back out again. This should also speed up resource copy-region and
blit.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The adreno a3xx GPU is found in newer snapdragon devices, such as the
nexus4. The a3xx is GLESv3 and OpenCL capable, although that is not
enabled yet in gallium.
Compared to a2xx, it introduces an entirely new unified shader ISA, and
re-shuffles all or nearly all of the registers. The good news is that
(for the most part) the registers are more orthogonal, not combining
unrelated state in a single register. And that there is a lot more
flexibility, so we don't need to patch and re-emit the shader like we
did on a2xx.
The shader compiler is currently quite dumb, there would be a lot of
room for improvement with an optimizing pass. Despite that, with the
a320 in my nexus4 it seems to be ~2-3x faster compared to the a220 in my
HP touchpad.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Split the parts that are specific to adreno a2xx series GPUs from the
parts that will be in common with a3xx, so that a3xx support can be
added more cleanly.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We use 128bit vector interleave for untwiddling in the blend code (with
256bit vectors). llvm generates terrible code for this for some reason,
so instead of generating a shuffle for 2 128bit vectors use a
extract/insert shuffle instead (it only seems to matter we're not using
128bit wide vectors for the shuffle). This decreases instruction count of
the blend code generated for a rgba8 render target without blending from
169 to 113 with llvm 3.1 and from 136 to 114 in llvm 3.2/3.3, and I got
a ~8% (llvm 3.1) and ~5% (3.2/3.3) performance improvement in gears.
(The generated code is still not terribly good as we could actually avoid
the interleaving completely but llvm can't know this.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Probably due to CRLF endings, the discovery of python import statements
was not working on Windows builds, causing incremental builds to often
fail unless one wiped out the build directory.
NOTE: This is a candidate for stable branches.
We flush pending rendering before running CopySubBuffer, which
ensures that the right bits get to the screen.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
The coordinates need to be inverted between glX and gallium.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
Just like we produce from inside the Intel driver, this can help provide
information quickly about FBO incompatibility problems (particularly when
using apitrace replay).
Currently, in driver-marked incompleteness cases, you'll get both the
driver message and the core message on Intel. Until the other drivers are
fixed to produce output, I think this is better than not putting in a
message for driver-marked incomplete.
Reviewed-by: Brian Paul <brianp@vmware.com>
When a fake front buffer is in use, if we request the front buffer
(using screen->dri2.loader->getBuffersWithFormat()), the X server
copies the real front buffer to the fake front buffer and returns the
fake front buffer. We sometimes make redundant requests for the front
buffer (due to using a single counter to track invalidates for both
the front and back buffers), so there's a danger of pending front
buffer rendering getting overwritten when the redundant front buffer
request occurs.
Previous to this patch, intel_update_renderbuffers() worked around
that problem by sometimes doing intel_flush() and intel_flush_front()
before calling intel_query_dri2_buffers(). But it only did the
workaround when the front buffer was bound for drawing; it didn't do
it when the front buffer was bound for reading.
This patch moves the workaround code to intel_query_dri2_buffers(), so
that it happens in exactly the circumstances where it is needed.
This should fix some of the sporadic failures in Piglit tests
fbo-sys-blit and fbo-sys-sub-blit.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The patch that follows will fix a bug that prevents
intel_flush_front() from being called often enough. In doing so, it
will create a situation where intel_flush_front() is called during the
initial call to glXMakeCurrent(). In this circumstance,
ctx->DrawBuffer hasn't been initialized yet and is NULL. Fortunately,
intel->front_buffer_dirty is false, so intel_flush_front() doesn't
actually need to do anything. To avoid a segfault, swap the order of
terms in intel_flush_front()'s if statement.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
piglit OpenGL ES 3.0/minmax now passes. This was also one of the subcase
failures in OpenGL 3.2/minmax (and still is, because our value is too low
for 3.2, but at least we report what it is).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part of fixing piglit OpenGL ES 3.0/minmax.
v2: s/_gles3/_es3/ in extra name, for consistency (review by Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Part of fixing piglit OpenGL ES 3.0/minmax.
v2: s/_gles3/_es3/ in extra name, for consistency (review by Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
These functions must clear all bound layers, not just the first.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Believe it or not but these two are actually the first two functions which
really belong in this file nowadays.
Reviewed-by: Brian Paul <brianp@vmware.com>
Mostly just make sure the layer parameter gets passed through to the right
places (and get clamped, can do this at setup time), fix up clears to
clear all layers and disable opaque optimization. Luckily don't need to
touch the jitted code.
(Clears invoked via pipe's clear_render_target method will not work however
since the pipe_util_clear function used for it doesn't handle clearing
multiple layers yet.)
v2: per Brian's suggestion, prettify var initialization and add some comments,
add assertion for impossible layer specification for surface.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Transfers always use z/depth for layers no matter if it's a 1d or 2d array
texture, we don't follow OpenGL's crazyness there. Luckily this appears to
only be a doc bug, everyone doing the right thing already.
While here also document z/depth parameter for cube map arrays.
v2: fix typo spotted by Eric Anholt
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Checking if array_size is greater than 1 is not enough for single-layered
array textures.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced().
draw_arrays() was used by nobody else. Now there's just one "draw" entrypoint
into the draw module.
Signed-off-by: Brian Paul <brianp@vmware.com>
This change came from the discovery that the STATIC_ASSERT to check that
the number of register file strings didn't actually work.
Similar changes could be made for the other string arrays in tgsi_string.c
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Removes the special-case suppression of gl_ClipVertex in the VUE map.
Also calculate vertex outcodes for user clip planes based on
gl_ClipVertex if written; otherwise gl_Position.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When clipping triangles against a user clip plane, and gl_ClipVertex
is provided in the vertex, use it instead of hpos.
TODO: A similar change should be made at some point for line clipping.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Introduce ilo_surface_cso and initialize it in create_surface(). With the
change, we can emit SURFACE_STATE directly from the CSO and remove
emit_surf_SURFACE_STATE(). We do not deal with depth/stencil surfaces yet.
Introduce ilo_cbuf_cso and initialize it in set_constant_buffer(). As
ilo_view_surface is embedded in ilo_cbuf_cso, switch to emit_SURFACE_STATE()
for constant buffers and remove emit_cbuf_SURFACE_STATE().
Introduce ilo_view_cso and initialize it in create_sampler_view(). Add
emit_SURFACE_STATE() to GPE, which can emit SURFACE_STATE from
ilo_view_surface.
Moving the work to create time reduces the work at emit time.
Saves time overall as create work is only done once.
Fix compiler warning in gen7_pipeline_sol.
[olv: remember pipe_alpha_state instead of pipe_depth_stencil_alpha_state in
ilo_dsa_state]
Introduce ilo_ve_cso and initialize it in create_vertex_elements_state().
This commit goes a step further by setting up mappings from HW VB to PIPE VB,
which we failed to do previously. That allows us to support instanced
rendering.
Remove hiz and dsa from the parameters. We would know whether HiZ buffer
exists from ilo_texture once it is supported. DSA state should not affect
3DSTATE_DEPTH_BUFFER.
Introduce ilo_sampler_cso and initialize it in create_sampler_state(). This
saves us from having to perform CPU-intensive calculations to construct
hardware sampler states in draw_vbo().
This allows us to memcpy() the state in draw_vbo(). Add ilo_init_states() and
ilo_cleanup_states() that are called when contexts are created and destroyed
respectively, and properly set the initial scissor state in ilo_init_states().
Introduce ilo_viewport_cso and initialize it in set_viewport_states(). This
saves us from having to perform CPU-intensive calculations to construct
hardware viewport states in draw_vbo().
Define and use
struct ilo_sampler_state;
struct ilo_view_state;
struct ilo_cbuf_state;
struct ilo_resource_state;
struct ilo_global_binding;
in ilo_context.
We were counting uniforms located in UBOs against the default uniform
block limit, while not doing any counting against the specific combined
limit.
Note that I couldn't quite find justification for the way I did this, but
I think it's the only sensible thing: The spec talks about components, so
each "float" in a std140 block would count as 1 component and a "vec4"
would count as 4, though they occupy the same amount of space. Since GPU
limits on uniform buffer loads are surely going to be about the size of
the blocks, I just counted them that way.
Fixes link failures in piglit
arb_uniform_buffer_object/maxuniformblocksize when ported to geometry
shaders on Paul's GS branch, since in that case the max block size is
bigger than the default uniform block component limit.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Putting the human readable device names directly in the PCI ID list
consolidates things in one place. It also makes it easy to customize
the name on a per-PCI ID basis without a huge code explosion.
Based on a patch by Kristian Høgsberg.
v2: Fix 830M/845G names and #undef CHIPSET (caught by Emit Velikov).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch unifies mesa's PACKAGE_VERSION on autotools, scons and
Android build systems.
Current behaviour is:
- Autotools uses 9.2.0 as PACKAGE_VERSION
- Scons and Android use 9.2-devel as PACKAGE_VERSION
With this patch all three build systems use 9.2.0-devel as
PACKAGE_VERSION.
Reviewed-by: Brian Paul <brianp@vmware.com>
RADEON_GEM_WAIT_IDLE is declared DRM_IOW but mesa
uses it with drmCommandWriteRead instead of drmCommandWrite
which leads to the ioctl being unmatched and returning an
error on at least OpenBSD.
Problem originally noticed in libdrm by Mark Kettenis.
Dave Airlie pointed out that mesa has the same issue.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
When building dri-swrast, use gallium_check_st to set HAVE_COMMON_DRI.
Commit 07f2dee7 added setting of HAVE_COMMON_DRI in gallium_check_st.
But the dri-swrast case did not use gallium_check_st.
So dri/common was still not built.
v2: set HAVE_COMMON_DRI=yes instead of using gallium_check_st
NOTE: This is a candidate for the 9.1 branch.
(Depends on 7de78ce5 and 07f2dee)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61821
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
The main change is to use MCJIT rather than the old JIT, which will never
be supported for System z. The endianness part is by example since the
patch was tested on a glibc system.
Signed-off-by: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
This was always doing per-pixel alignment which isn't necessary, except
for the buffer case (due to the per-element offset). The disabled code
for calculating it was incorrect because it assumed that always the full
block would be fetched, which may not be the case, so fix this up.
The original code failed for instance for r10g10b10a2 the alignment would
have been calculated as 4 (block_width) * 4 (bytes) so 16, but the actual
fetch may have only fetched 2 values at a time, hence only alignment 8 -
it is unclear what exactly would happen in this case (alignment larger
than size to fetch).
So just use the (already calculated) fetch size instead and get alignment
from that which should always work, no matter if fetching 1,2 or 4 pixels.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For rendering to buffers, we cannot have any y alignment.
So make sure that tile clear commands only clear up to the fb width/height,
not more (do this for all resources actually as clearing more seems
pointless for other resources too). For the jit fs function, skip execution
of the lower half of the fragment shader for the 4x4 stamp completely,
for depth/stencil only load/store the values from the first row
(replace other row with undef).
For the blend function, also only load half the values from fs output,
replace the rest with undefs so that everything still operates on the
full 4x4 block to keep code the same between 4x1 and 4x4 (except for
load/store of course which also needs to skip (store) or replace these
values with undefs (load))., at the cost of slightly less optimal code
being produced in some cases.
Also reduce 1d and 1d array alignment too, because they can be handled the
same as buffers so don't need to waste memory.
v2: don't try to run special blend code for 4x1, (very) slightly less
complexity if we just use the same code as for 4x4 which may or may not
make it easier to optimize in the future (as we care a lot more about 4x4
performance than 1d).
v2: don't use undef values for unused fs src outputs with llvm 3.1 as it
apparently can trigger a bug in llvm.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Some parameters were used inconsistently, for instance not using
block_width/block_height/block_size for deferring number of pixels
but rather relying on guesses from the number of fragment shaders etc,
so fix this up (no actual change in behavior since the block size stays
fixed). (Though most of the code would work with different block_height,
with three exceptions, one being the hacked r11g11b10 conversions and
twiddle code which only work with block_height 2 not 1, and the last
one being blend vector type not being 128bit wide.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
There's no good reason why it can't handle 2x4f->1x8ub, 1x4f->1x4ub and
1x8f->1x8ub cases, there might be legitimate reasons why we don't have
enough input vectors for a full destination vector, and using pack
intrinsics should still be much better than using generic conversion
(it looks like convert_alpha from the blend code might hit this though
I suspect it could be avoided).
v2: add another test vector format to lp_test_conv so this gets tested.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The code was designed to handle no-op concat but failed (unless the
caller was using same pointer for src and dst).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We've never properly supported more than one address register. There
isn't even a field in prog_src_register or prog_dst_register to indicate
which address register to use if RelAddr!=0.
In the state tracker, clamp MaxAddressRegs against MAX_PROGRAM_ADDRESS_REGS
since many gallium drivers do support more.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65226
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Blorp and the hardware blitter can't be used to implement
CopyTexSubImage when the image type is 1D_ARRAY, because of a
coordinate system mismatch (the Y coordinate in the source image is
supposed to be matched up to the Z coordinate in the destination
texture).
The hardware blitter path (intel_copy_texsubimage) contained a perf
debug warning for this case, but it failed to actually fall back. The
blorp path didn't even check.
Fixes piglit test "copyteximage 1D_ARRAY".
Reviewed-by: Eric Anholt <eric@anholt.net>
Commit 045612c (intel: Add an assert for glCopyTexSubImage() being
called on MSAA buffers) added an assertion to intel_copy_texsubimage()
to make sure that multisampling was not in use, based on the
assumption that glCopyTexSubImage() can't legally be used with
multisampling.
However, there is one case where glCopyTexSubImage() can legally be
used with multisampling: when the source buffer is a multisampled
window system buffer. If the source and destination color formats
don't match, the blorp path will fail, so intel_copy_texsubimage()
will be called. In this case, we need intel_copy_texsubimage() to
return false so that we fall back to meta to do the copy. (The
multisampled source buffer won't cause a problem for the meta path,
because it uses glReadPixels, which forces a multisample resolve).
It's still safe to assert that the destination image is
single-sampled, because it's not legal to call glCopyTexSubImage() on
multisampled textures.
Fixes some failures with piglit tests "copyteximage
{1D,2D,CUBE,RECT,2D_ARRAY}" (with "samples=..." argument).
Reviewed-by: Eric Anholt <eric@anholt.net>
Okay I now understand why Frank would want to run away, this is
my attempt at fixing the CVE out of bounds access to constants
outside the range. This attempt converts any illegal constants
to constant 0 as per the GL spec, and is undefined behaviour.
A future patch should add some debug for users to find this out,
but this needs to be backported to stable branches.
CVE-2013-1872
v2: drop the last hunk which was a separate fix (now in master).
hopefully fix the indentations.
v3: don't fail piglit, the whole 8/16 dispatch stuff was over
my head, and I spent a while figuring it out, but this one is
definitely safe, one piglit pass extra on my Ironlake.
NOTE: This is a candidate for stable branches.
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were copying the source stencil data onto the destination depth data.
Fixes piglit copyteximage other than 1D_ARRAY.
v2: Fix unintentional dropping of the "don't double-copy for packed
depth/stencil" check. While blorp is only supported on separate
stencil hardware at the moment, hopefully that will change soon.
Review by Jordan.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When making v2 of da2880bea0, I carefully
checked all of the calls in that commit to see that I'd updated them, but
forgot to update the new calls in the later commits such as
.e845c5cf7abce55759501a473459aff3bf25c9ca. As a result, we were getting Y
tiled temporaries even though the whole point of the temporary was to
untile!
The steady state of the intro scene of lightsmark goes from 13 to 17 fps.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65154
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
To trigger the bug, it suffices to have a line-continuation followed by
a newline and then a non-line-continuation backslash.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This loop-control condition with a post-decrement operator would lead to
an underflow of collapsed_newlines. This in turn would cause a subsequent
execution of the loop to labor inordinately trying to return the loop-control
variable to a value of 0 again.
Fix this by dis-intertwining the test and the decrement.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65112
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When a gl_client_array is created with glColorPointer,
gl_client_array::Normalized is true. This caused the translation from the
gl_client_array's type to a BRW_SURFACEFORMAT to assertion fail.
Fixes the spinning cube's color in Android 4.2's ApiDemos.apk,
"Graphics > OpenGL ES".
Fixes assertion failure in mesa-demos/src/egl/opengles1/tri_x11 on Haswell
and Ivybridge:
brw_draw_upload.c:287: get_surface_type: Assertion `0' failed.
No Piglit regressions on Haswell.
Note: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42182
Issue: AXIA-2954
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
It was changed from 0 to allow shader outputs at 0 that are
different from position.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We were crashing when GL_READ_BUFFER == GL_NONE. Check for NULL
pointers and reorganize the code. The spec doesn't say which error
to generate in this situation, but NVIDIA raises GL_INVALID_OPERATION.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65173
NOTE: This is a candidate for the stable branches.
Tested-by: Vedran Rodic <vrodic@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Before, on the second call to GenerateMipmap we were enabling two
vertex arrays for the current vertex array object, rather than
the private generate-mipmap vertex array object. This caused
things to blow up elsewhere.
This patch moves the array enables into the block where the
generate-mipmap vertex array object is created, as we do in
the setup_ff_generate_mipmap() function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60518
NOTE: This is a candidate for the stable branches.
Tested-by: core13@gmx.net
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since pipe_surface already has all the necessary fields no interface
changes are necessary except adding a new shader semantic value
(TGSI_SEMANTIC_LAYER).
(Note that what GL knows as "gl_Layer" variable d3d10 is naming
"RENDER_TARGET_ARRAY_INDEX".)
v2: drop cap bit (just tied to geometry shader), add docs.
Surprising this bug survived so long, we were missing a clamp (in the
linear filtering version).
(Valgrind complained a lot about invalid reads with piglit texwrap,
I've also seen spurios failures in this test which might have
happened due to this. Valgrind probably didn't complain before the
alignment reduction in llvmpipe to 4x4 since the test is using tiny
textures so the reads were still always well within allocated area.)
While here, also do an effective clamp (after half subtraction)
of [0,length-0.5] instead of [0, length-1] which saves an instruction
(the filtering weight could be different due to this, but only if
both texels point to the same max texel so it doesn't matter).
(Both changes are borrowed from PIPE_TEX_CLAMP_TO_EDGE case.)
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
One of the assertion made no sense for buffer rendertargets
(due to the union), so drop it. (The same assertion is present already in
the path for texture surfaces later.).
v2: make assertion completely accurate (suggested by Jose).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
brw->ib.type is reset to -1 at the start of each batch. If there's no
index buffer, it won't get updated to a sensible value, resulting in
_mesa_primitive_restart_index's "Invalid index buffer type" assertion
tripping.
Fixes a regression since 7c87a3b5da.
NOTE: This is a candidate for the 9.1 branch (and should be squashed).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65195
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The overallocation was very bad especially for things like 1d array
textures which got blown up by a factor of 64. (Even ordinary smallish
2d textures benefit a lot from this, a mipmapped 64x64 rgba8 texture
previously used 7*16kB = 112kB instead of now ~22kB.)
4x4 is chosen because this is the size the jit functions run on, so
making it smaller is going to be a bit more complicated.
It is actually not strictly 4x4 pixel, since we'd want to avoid situations
where different threads are rendering to the same cacheline so we keep
cacheline size alignment in x direction (often 64bytes).
To make this work introduce new task width/height parameters and make
sure clears don't clear the whole tile if it's a partial tile. Likewise,
the rasterizer may produce fragments outside the 4x4 blocks present in a
tile, so don't call the jit function for them.
This does not yet fix rendering to buffers (which cannot have any y
alignment at all), and 1d/1d array textures are still overallocated by a
factor of 4.
v2: replace magic number 4 with LP_RASTER_BLOCK_SIZE, fix size of buffers
allocated (needed in case we render to them).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These were mostly just a waste of memory and cache pressure, and were
really only used for debugging.
This change reduces instruction count (as measured by callgrind's Ir
event) of gnome-shell-perf-tool on Ivybridge by 3.5% ± 0.015% (n=20).
Signed-off-by: Adam Jackson <ajax@redhat.com>
This fixes the following build errors on powerpc:
CC glapi_dispatch.lo
In file included from glapi_dispatch.c:90:0:
../../../../../src/mapi/glapi/glapitemp.h:1640:1: error: no previous
prototype for 'glReadBufferNV' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:4198:1: error: no previous
prototype for 'glDrawBuffersNV' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6377:1: error: no previous
prototype for 'glFlushMappedBufferRangeEXT'
[-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6389:1: error: no previous
prototype for 'glMapBufferRangeEXT' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6401:1: error: no previous
prototype for 'glBindVertexArrayOES' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6413:1: error: no previous
prototype for 'glDeleteVertexArraysOES' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6433:1: error: no previous
prototype for 'glGenVertexArraysOES' [-Werror=missing-prototypes]
../../../../../src/mapi/glapi/glapitemp.h:6445:1: error: no previous
prototype for 'glIsVertexArrayOES' [-Werror=missing-prototypes]
NOTE: This is a candidate for the 9.0 and 9.1 branches.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
clientDriverNameLength is a CARD32 and needs to be bounds checked before
adding one to it to come up with the total size to allocate, to avoid
integer overflow leading to underallocation and writing data from the
network past the end of the allocated buffer.
NOTE: This is a candidate for stable release branches.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
busIdStringLength is a CARD32 and needs to be bounds checked before adding
one to it to come up with the total size to allocate, to avoid integer
overflow leading to underallocation and writing data from the network past
the end of the allocated buffer.
NOTE: This is a candidate for stable release branches.
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
For formats such as GL_COMPRESSED_SRGB_S3TC_DXT1_EXT we need to
have both the GL_EXT_texture_sRGB and GL_EXT_texture_compression_s3tc
extensions. This patch adds the missing check for the later.
Found when checking out https://bugs.freedesktop.org/show_bug.cgi?id=65173
NOTE: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When we've changed draw_find_shader_output to return -1 instead
of 0 on non found attribs we broke the default behavior of
draw, which was to always redirect those to the first (0th) slot.
To preserve that behavior if draw_emit_vertex_attr notices a
mismatched vertex attrib, it just redirects it to the first slot
(instead of trying to use negative index in an array).
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In traditional multisampled framebuffer rendering, color samples must be
explicitly resolved via BlitFramebuffer before doing the scaled blitting
of the framebuffer. So, scaled blitting of a multisample framebuffer
takes two separate calls to BlitFramebuffer.
This patch implements the functionality of doing multisampled scaled
resolve using just one BlitFramebuffer call. Important changes involved
in this patch are listed below:
- Use float registers to scale and offset texture coordinates.
- Change offset computation to consider float coordinates.
- Round the scaled coordinates down to nearest integer.
- Modify src texture coordinates clipping to account for scaling..
- Linear filter is not yet implemented in blorp. So, don't use
blorp engine to do single sampled scaled blitting.
V3: Fix nearest filtering issue in scaled blits. Makes failing piglit
fbo-blit-stetch test and framebuffer_blit_functionality_magnifying_blit.test
in gles3 CTS pass.
Observed no piglit, gles3 CTS regressions on sandybridge & ivybridge with
this patch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These changes are required to implement scaled blitting in blorp
in my next patch.
No regressions observed in piglit quick-driver.tests with this patch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This reverts commit 98dfd59a04.
The patch was clearly not Piglit tested, as it caused at least 225
tests to start crashing with assertion failures. That was before my
desktop tanked and the test run died completely.
Remove hash function on shader variants. Nature of variants limits them to a
small number and thus its more efficient to just do a memory compare of the
actual shader structures rather than compute and compare hashes.
This is my attempt at fixing this as the CVE is making RH security team
care enough to make me look at this. (please upstream, security fixes are
more important than whatever else you are doing, if for no other reason than
it saves me having to fix stuff I've no real clue about).
Since Frank's original fix was denied, here is my attempt to just
alias all constants that are out of bounds < 0 or > nr_params to constant 0,
hopefully this provides the undefined behaviour idr requires..
CVE-2013-1872
v2: drop the last hunk which was a separate fix (now in master).
hopefully fix the indentations.
NOTE: This is a candidate for stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Set fs_visitor::params_remap to NULL in the constructor.
This variable was potentially tested in fs_visitor::remove_dead_constants()
before being set.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Frank Henigman <fjhenigman@google.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Viewport index should only be used on a per primitive basis, so
instead of fetching it from each vertex, potentially making each
vertex in a primitive use a different viewport index, which is
obviously broken, make sure that we only fetch from the first
vertex in the primitive making the viewport index the same
for the entire primtive.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
We need to clamp to make sure invalid shader doesn't crash our
driver. The spec says to return 0-th index for everything that's
out of bounds.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
If the viewport index is larger than the PIPE_MAX_VIEWPORTS,
then the first (0-th) viewport should be used.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
draw_find_shader_output like most of the code in draw used to
depend on position always being at output slot 0. which meant
that any other attribute being at 0 could signify an error.
unfortunately position can be at any of the output slots, thus
other attributes can occupy slot 0 and we need to mark the ones
which were not found by something else. This commit changes
draw_find_shader_output so that it returns -1 if it can't
find the given attribute and adjust the code that depended
on it returning >0 whenever it correctly found an attrib.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Largely related to making sure the rasterizer can correctly
pick out the correct scissor box for the current viewport.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This adds support for multiple viewports to the draw module.
Multiple viewports depend on the presence of geometry shaders
which can write the viewport index.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Gallium supported only a single viewport/scissor combination. This
commit changes the interface to allow us to add support for multiple
viewports/scissors.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca<jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
It's incorrect and isn't used any longer.
v2: Actually flush vertices/flag _NEW_TRANSFORM on RestartIndex change.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
GL_PRIMITIVE_RESTART_FIXED_INDEX is only supposed to apply to
glDrawElements*. This code is for legacy drawing paths and display
lists, so it shouldn't apply.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The derived _RestartIndex field is an attempt to support both
GL_PRIMITIVE_RESTART and GL_PRIMITIVE_RESTART_FIXED_INDEX (part of ES
3.0). Gallium drivers don't appear to support ES 3.0 yet, so they don't
need to use it. Plus, it's broken and going to go away soon.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Pre-Haswell hardware doesn't support an arbitrary restart index, and
instead compares the index buffer value against 0xFF for byte-size
buffers, 0xFFFF for short-size buffers, or 0xFFFFFFFF for unsigned
integer buffers.
OpenGL allows the restart index to be an arbitrary unsigned integer.
When comparing against byte/short types, the index buffer value should
be promoted to a full 32-bit integer before doing the comparison. The
restart index is /not/ supposed to be masked to byte/short size.
This means that with certain restart indexes, the comparison should
always fail. For example, a restart index of 0xF000FFFF should never
match any byte/short index buffer values due to the extra high bits.
We must not enable hardware primitive restart in such a case. For now,
fall back to software primitive restart as it's the simplest fix. In
the future, we could detect restart indexes that will never match and
skip both hardware and software primitive restart.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The code that updates the ctx->Array._RestartIndex derived state mashed
it to 0xFFFFFFFF when GL_PRIMITIVE_RESTART_FIXED_INDEX was enabled
regardless of the index buffer type. It's supposed to be 0xFF for byte,
0xFFFF for short, or 0xFFFFFFFF for integer types.
The new _mesa_primitive_restart_index() helper gets this right.
The hardware appears to compare against the full 32-bit value some of
the time, causing primitive restart not to occur when it should. The
fact that it works some of the time is rather frightening.
Fixes sporadic failures in the ES 3 instanced_arrays_primitive_restart
conformance test when run in combination with other tests.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This gets the correct restart index for unsigned byte/short types when
using GL_PRIMITIVE_RESTART_FIXED_INDEX.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The derived state approach currently used (_RestartIndex) doesn't work:
in the GL_PRIMITIVE_RESTART_FIXED_INDEX case, the restart index depends
on the index buffer's data type, and that isn't known until draw time.
The existing code also fails to obey the GL 4.3 rules which say that
FIXED_INDEX takes precedence over normal primitive restart.
This helper function correctly determines the restart index, and will
replace the derived state.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The derived _PrimitiveRestart enable flag combines the PrimitiveRestart
and PrimitiveRestartFixedIndex enable flags. However, DrawArrays is not
supposed to do FixedIndex restart:
From the OpenGL 4.3 Core specification, section 10.3.5 (page 302):
"If PRIMITIVE_RESTART_FIXED_INDEX is enabled, primitive restart is not
performed for array elements transferred by any drawing command not
taking a type parameter, including all of the *Draw* commands other
than *DrawElements*."
The OpenGL ES 3.0 specification agrees by omission:
"When DrawElements, DrawElementsInstanced, or DrawRangeElements
transfers a set of generic attribute array elements to the GL..."
Notably, DrawArrays is not included in the list of draw calls that
take PRIMITIVE_RESTART_FIXED_INDEX into consideration.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously it would assertion fail in debug builds (though the correct
value was returned in a non-debug build). Marking it as a candidate for
stable even though it has no current consumers in the stable branches, in
case one shows up in a later backport.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64727
NOTE: This is a candidate for stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were expanding the live range too far, breaking register_coalesce_2()
and compute_to_mrf() on 16-wide shaders. Turning it back on improves
GLB2.7 performance by 0.239355% +/- 0.0850649% (n=398). shader-db stats
are:
total instructions in shared programs: 1627211 -> 1609262 (-1.10%)
instructions in affected programs: 450351 -> 432402 (-3.99%)
While 33 new 16-wide shaders are gained, 70 are lost. Despite that,
tropics (the app that lost the most 16-wide) shows a .41% +/- .16%
(n=7/8, first-run outlier removed) performance improvement on my HSW.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The scheduler didn't know about uniform-type accesses, and if a uniform
access was last in a 16-wide, we'd walk off the end of the array. This
never happened, because we'd never coalesce out all the GRFs, due to a bug
to be fixed in the next commit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965 and radeon use ra_set_node_reg() to force payload registers to
specific registers while exposing those registers to the allocator still.
We were treating those register nodes as unsuccessfully allocated in the
ra_simplify() step, leading to walking the registers again to do
optimistic coloring even if there was nothing left ot do.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Since the introduction of default-to-SARGB8 window system framebuffers,
non-blorp hardware lost blit acceleration for these two paths between the
window system and ARGB8888 textures. Since we shouldn't be doing any
conversion anyway, just compatibility-check the linear variants of the
formats.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61954
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
r600g needs it too, so add ipo in the common radeon_llvm_check().
radeonsi compiled and linked, but it failed at dynamic link time
with a missing symbol.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Eliminate the rest of the no longer needed layout logic.
(It is possible some code could be simplified a bit further still.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Since the glBitmap() MRT change, it's unused. There was basically no way
to responsibly use this function since MRT was introduced.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
Any 32-bit format got ARGB8888 handling (including, say, GL_RG1616), and
anything else got 16-bit (including, say, GL_R8), which could potentially
hang the GPU by writing out of bounds.
NOTE: This is a candidate for the stable branches.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
We'd only hit color buffer 0 even if multiple draw buffers were bound.
NOTE: This is a candidate for the stable branches.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
This will ensure that we have resolves if we ever extend this to
glTexSubImage(), and fixes missing image start offset handling.
The texture buffer alloc ended up getting moved up, because we want to
look at the format of the image's actual mt to see if we'll end up
blitting the right thing, in the case of packed depth/stencil uploads.
This is the last caller of intelEmitCopyBlit() on a miptree-wrapped BO.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
The previous code was missing depth resolves, that had only been prevented
due to no blitting of Y tiling. The pair of flip args in the new blit
function means that we can just drop the pack->Invert fallback.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
I needed to do this for the PBO blit cases to use intel_miptree_blit().
But this also actually partially fixes a bug in EGLImage handling: We
can't share regions across contexts, because regions have a refcount that
isn't protected by a mutex, and different contexts can be simulataneously
accessed from multiple threads. Now we just need to get regions out of
__DRIImage. There was also a missing use of image->offset in the EGLImage
renderbuffer storage code.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
In a bit of debug code, we no longer have the inter-slice x/y to print.
But I think the level/slice is more useful in this case for looking at
what's getting mapped, especially given that INTEL_DEBUG=blit will tell
you the other value.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
While this is a bit more CPU work, it also is less code to handle this
path, and fixes problems with 32k-pitch textures and missing resolves.
v2: Add error checking in new code.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Acked-by: Paul Berry <stereotype441@gmail.com>
For a blit-uploaded temporary, it's faster on current hardware to memcpy
the data into a linear CPU mapping than to go through the GTT.
v2: Turn the not-fully-supported mask into 3 supported enum values.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Paul Berry <stereotype441@gmail.com> (v2)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v2)
This is just in case someone else trips over this due to our weird reuse
of this code in glBlitFramebuffer().
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
I think we've measured no performance difference from this in the past,
except that the blorp code can do things like multisample resolves.
Prevents piglit regression in the next commit when a testcase started
trying to do a multisampled resolve through the old glCopyTexSubImage()
path.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
We were protected for a long time by the fact that depth was Y tiled and
you couldn't blit Y. Now that we can blit Y, we were failing to resolve
depth in glCopyPixels().
Note in the comment about swrast, that the swrast map path does resolves
appropriately already.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
I had previously asserted that it was hard to write a useful, simpler
blit function, but I think this might be it.
This has the side effect of extending the 32k pitch check to a few more
places that were missing it.
v2: Update comment for being moved inside intel_miptree_blit().
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>
Right now, the callers in i965 don't expect a nonzero page offset to
actually occur (since that's being handled elsewhere), but it seems
like a trap to leave it this way.
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
It appears that `sizeof(Class::member)` is either non-standard or
merely unsupported in MSVC.
So use `sizeof(instance->member)` instead, which is guaranteed to work
everywhere.
Also promote the assert to a static assert.
Trivial.
The problem is the sampler units are allocated from the same pool for all
shader stages, so if a vertex shader uses 12 samplers (0..11), the fragment
shader samplers start at index 12, leaving only 4 sampler units
for the fragment shader. The main cause is probably the fact that samplers
(texture unit -> sampler unit mapping, etc.) are tracked globally
for an entire program object.
This commit adapts the GLSL linker and core Mesa such that the sampler units
are assigned to sampler uniforms for each shader stage separately
(if a sampler uniform is used in all shader stages, it may occupy a different
sampler unit in each, and vice versa, an i-th sampler unit may refer to
a different sampler uniform in each shader stage), and the sampler-specific
variables are moved from gl_shader_program to gl_shader.
This doesn't require any driver changes, and it fixes piglit/max-samplers
for gallium and classic swrast. It also works with any number of shader
stages.
v2: - converted tabs to spaces
- added an assertion to _mesa_get_sampler_uniform_value
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
to match the size of ctx->Texture.Unit, and it will also fix
piglit/max-samplers with the following commit.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Some Gallium drivers were crashing, because the array was not large enough.
v2: clamp the per-shader maximum in st/mesa, then sum them all up
NOTE: This is a candidate for the stable branches.
Set up CB_SHADER_MASK register according to pixel shader exports, and enable
some minimal state for colour buffer 1 in case dual source blending is used.
TGSI_TEXTURE_BUFFER is one-dimensional. Assert that exec_tex() is never
called with TGSI_TEXTURE_BUFFER.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch improves handling of unconditional KILL instructions inside
the conditional blocks, uncovering more opportunities for if-conversion.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
PRED_SET instructions that update exec mask should be scheduled immediately
prior to the "if-then-else" block, because any instruction that is
inserted after alu clause with PRED_SET and before conditional block is
also conditionally executed by hw (exec mask is already updated at that
moment).
Propbably it's better to make PRED_SET a part of conditional
"if-then-else" block in the IR to handle this more cleanly,
but for now this temporary solution should prevent the problem.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
For compute shaders we need to let the backend know that
GPRs 0 and 1 are preloaded with some compute-specific input
values, otherwise any use of these regs without previous
definition is considered as undefined value and usually
is simply replaced with 0.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
This allows GVN rewrite pass to propagate non-const (register)
values to FETCH source operands, helping to eliminate unnecessary
copies in some cases.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
We have to assume that all GPRs in compute shader can be indirectly
addressed because LLVM backend doesn't provide any indirect array info.
That's why for compute shaders GPR array is created that covers all used
GPRs (0..r600_bytecode::ngpr-1), but this seriously restricts register
allocation in sb.
This patch checks for actual use of indirect access in the shader and
if it's not used then GPR array is not created, so that regalloc is not
unnecessarily restricted.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
It turns out the MI_LOAD_REGISTER_IMM approach doesn't work on Haswell,
and regressed essentially all the transform feedback Piglit tests.
This morally reverts eaa6fbe6d5. However,
the code is still simpler than it was. On BeginTransformFeedback, we
simply flush the batch and set the SOL reset flag so that the next batch
will start with zeroed offsets. There's still no software counting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64887
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Verify that interface blocks match when linking separate shader
stages into a program.
Fixes piglit glsl-1.50 tests:
* linker/interface-blocks-vs-fs-member-count-mismatch.shader_test
* linker/interface-blocks-vs-fs-member-order-mismatch.shader_test
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Verify that interface blocks match when combining compilation
units at the same stage. (For example, when merging all vertex
shaders.)
Fixes piglit glsl-1.50 test:
* linker/interface-blocks-multiple-vs-member-count-mismatch.shader_test
v5 (Ken): Rename to link_interface_blocks.cpp and drop the separate .h
file for consistency with other linker code. Remove "ok" variable.
Fold cross_validate_interface_blocks into its caller.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
With this change we now support interface block arrays.
For example, cases like this:
out block_name {
float f;
} block_instance[2];
This allows Mesa to pass the piglit glsl-1.50 test:
* execution/interface-blocks-complex-vs-fs.shader_test
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Convert interface blocks with instance names into flat
interface blocks without an instance name.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For interface blocks, there are three separate namespaces for
uniform, input and output blocks.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously uniform blocks allowed for the 'uniform' keyword
to be used with members of a uniform blocks. With interface
blocks 'in' can be used on 'in' interface block members and
'out' can be used on 'out' interface block members.
The basic_interface_block rule will verify that the same
qualifier type is used with the block and each member.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
An interface block member may specify the type:
in {
in vec4 in_var_with_qualifier;
};
When specified with the member, it must match the same
type as interface block type.
It can also omit the qualifier:
uniform {
vec4 uniform_var_without_qualifier;
};
When the type is not specified with the member,
it will adopt the same type as the interface block.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Interface blocks in GLSL 150 allow an instance name to be used.
v2:
* use state->check_version
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously only 'uniform' was allowed for uniform blocks.
Now, in/out can be parsed, but it will only be allowed for
GLSL >= 150.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Enables guardband clipping when the viewport covers the entire render
target.
No piglit regressions on Ironlake.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Relaxes the validation of
OPTION ARB_precision_hint_{nicest,fastest};
to allow duplicate options. The spec says that both /nicest/ and
/fastest/ cannot be specified together, but could be interpreted
either way for respecification of the same option.
Other drivers (NVIDIA etc) accept this, and at least one Unity3D game
expects it to succeed (Kerbal Space Program).
V2: Add spec quote.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
need_flush was uninitialized if hw3d->new_batch was true.
Fixes "Uninitialized scalar variable" defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
'type' was not fully initialized when calling lp_build_context_init.
Fixes "Uninitialized scalar variable" defect reported by Coverity.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much
memory (mostly because the tile cache is operating on fixed max current
sampler views which could be fixed but that's another topic). So it was
decreased to 4. However this is a ridiculously low number which can't
actually really work (the number of tiles needed for as little as
a single quad with linear_mipmap_linear is 2 to 8 for a 2d texture, and
4 to 16 for a 3d texture), as it just about guarantees there will be
cache thrashing sometimes (just about always for 3d textures in fact, since
while there are 4 entries the cache is direct mapped).
So increase that number to 16 (which is still on the low side for direct
mapped cache though I guess using something like 4-way associativity would
be more effective than increasing this further) which has at least some good
chance to avoid thrashing. Since we don't want to increase memory requirements
however in turn decrease the tile size accordingly from 64 to 32 (as a bonus
point this also decreases the cost of texture thrashing which might still
happen sometimes).
I've seen performance improvement in the order of factor ~200 (specifically,
drawing the first frame from the replay from bug 41787 needs "only" ~10s
instead of ~30min, meaning I can actually compare the output with other
drivers...) with this.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This optimization disabled mask checks if the shader is simple enough.
While this should work correctly, the problem is that it can hide real issues
because shaders in practice are usually complex enough (8 instructions or 1
texture is already enough) so this doesn't get used, whereas dumbed-down
tests which should hit all the same code paths suddenly do something quite
different. This was the reason that bug 41787 could not be easily tracked as
stencil test not working correctly (piglit would in fact have failed some
tests without that optimization).
So disable it for now, it's unclear if it's much of a win in any case.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We actually did early depth/stencil test and late depth/stencil write even
when the shader could kill the fragment (alpha test or discard). Since it
matters for the new stencil value if the fragment is killed by depth/stencil
test or by the shader (in which case it will not reach the depth/stencil
test) this simply cannot work (we also would possibly skip writing the new
stencil value due to mask checks but this is a secondary issue).
So use late depth test / late depth write instead in this case.
(No piglit changes as it doesn't seem to hit such bogus early depth test
/ late depth write path.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We did mask checks between depth/stencil testing and depth/stencil write.
This meant that if the depth/stencil test killed off all fragments we never
actually wrote the new stencil value. This issue affected all early/late
test/write combinations.
So move the mask check after depth/stencil write (for early depth test,
could do the same for late depth test but might not be worth it at that
point so just skip it there).
This addresses https://bugs.freedesktop.org/show_bug.cgi?id=41787.
Piglit does not hit this issue because of the simple_shader optimization
in generate_fs_loop() which means we're skipping the mask checks.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This was meant to disable some code which isn't needed when depth/stencil
isn't written. However, there's more code which wouldn't be needed in that
case so having the condition there was just odd (llvm will drop all the code
anyway).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
* We generate a static library for Haiku
Gallium targets as our port system combines
the compiled rendering code into a modular
ar for each module (for example, our port
system combines llvm libsoftpipe.a libllvmpipe.a
into a single ar for the Haiku build system.
I'd like the Gallium hgl target scons build
system to do this some day, however how is
beyond me at the moment. This is a first step.
Set lod/layer related fields of 3DSTATE_DEPTH_BUFFER. Since we always point
to a single level/layer, those fields are always zero and this commit
effectively makes no change.
While at it, make it easier to disable manual slice offset calculation.
The view extent was set to be the same as the depth while it should be set to
the number of layers. It makes a difference for 3D textures.
Also use this as a chance to clean up the code.
No need to emit 3DSTATE_SO_BUFFER and 3DSTATE_SO_DECL_LIST when SO is
disabled. As the implicit flush done by the commands is also gone, emit an
explicit flush.
Most of the work in BeginTransformFeedback is only necessary on Gen6.
We may as well just skip it on Gen7+.
v2: Add an intel->gen == 6 assert.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Now that we have hardware contexts, we don't need to continually
reprogram the GS_SVBI_INDEX registers. They're automatically saved and
restored with the context, so they can just increment over time. We
only need to reset them when starting transform feedback.
There's also no reason to delay until the next drawing operation; we can
just emit the packet immediately. However, this means we must drop the
initialization in brw_invariant_state, as BeginTransformFeedback may
occur before the first drawing in a context.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
EXT_transform_feedback isn't yet supported on Gen4-5, so none of this
query code is actually used. This also means we can remove some of the
surrounding support code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Failing to get a hardware context now means failing to load the driver,
so this code will never get hit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
and add assertions to prevent buffer overflow. This fixes corruption
of the si_shader struct.
NOTE: This is a candidate for the 9.1 branch.
[ Cherry-pick of r600g commit da33f9b919 ]
Reviewed-by: Marek Olšák <maraeo@gmail.com>
- recent gdb handles DWARF fine (tested both with version
7.1.90.20100730 from mingw-w64 project, and 7.5-1 from mingw project)
- http://people.freedesktop.org/~jrfonseca/bfdhelp/ was updated to
handle DWARF
- stabs requires ugly hacks to prevent compilation failures
- mixing stabs/dwarf prevents proper backtraces (which is inevitable,
given that the MinGW C runtime is pre-built with DWARF)
For example, without this change I get:
(gdb) bt
#0 _wassert (_Message=0xf925060 L"Num < NumOperands && \"Invalid child # of SDNode!\"",
_File=0xf60b488 L"llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534)
at ../../../../mingw-w64-crt/misc/wassert.c:51
#1 0x0368996b in _assert (_Message=0x39d7ee4 "Num < NumOperands && \"Invalid child # of SDNode!\"",
_File=0x39d7e94 "llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534)
at ../../../../mingw-w64-crt/misc/wassert.c:44
#2 0x00000004 in ?? ()
#3 0x00000004 in ?? ()
#4 0x0f60b488 in ?? ()
#5 0x00000000 in ?? ()
While with this change I get:
(gdb) bt
#0 _wassert (_Message=0xfb982e8 L"Num < NumOperands && \"Invalid child # of SDNode!\"",
_File=0xefbcb40 L"llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534)
at ../../../../mingw-w64-crt/misc/wassert.c:51
#1 0x039c996b in _assert (_Message=0x3d17f24 "Num < NumOperands && \"Invalid child # of SDNode!\"",
_File=0x3d17ed4 "llvm/include/llvm/CodeGen/SelectionDAGNodes.h", _Line=534)
at ../../../../mingw-w64-crt/misc/wassert.c:44
#2 0x033111cc in getOperand (Num=4, this=<optimized out>)
at llvm/include/llvm/CodeGen/SelectionDAGNodes.h:534
#3 getOperand (i=4, this=<optimized out>)
at llvm/include/llvm/CodeGen/SelectionDAGNodes.h:779
#4 llvm::SelectionDAG::getNode (this=0xf00cb08, Opcode=79, DL=..., VT=..., N1=..., N2=...)
at llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2859
#5 0x03377b20 in llvm::SelectionDAGBuilder::visitExtractElement (this=0xfb45028, I=...)
at llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:2803
[...]
Reviewed-by: Brian Paul <brianp@vmware.com>
Emit XY_SRC_COPY_BLT to do the job. Since ETC1 textures cannot be mapped for
reading, as is required by util_copy_resource_region, this fixes copying of
ETC1 textures.
The problem with cp hooks is that when we switch from 3D ring to 2D ring, and
when there are active queries, we will emit 3D commands to 2D ring because
the new-batch hook is called.
This commit introduces the idea of cp owner. When the cp is flushed, or when
another owner takes place, the current owner is notified, giving it a chance
to emit whatever commands there need to be. With this mechanism, we can
resume queries when the 3D pipeline owns the cp, and pause queries when it
loses the cp. Ring switch will just work.
As we still need to know when the cp bo is reallocated, a flush callback is
added.
Now that we have hardware contexts and can use MI_STORE_REGISTER_MEM,
we can use the GPU's pipeline statistics counters rather than going out
of our way to count primitives in software.
Aside from being simpler, this also paves the way for Geometry Shaders,
which can output an arbitrary number of primitives on the GPU. It will
also allow us to use hardware primitive restart when these queries are
in use.
The GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN query is easy: it
corresponds to the SO_NUM_PRIMS_WRITTEN/SO_NUM_PRIMS_WRITTEN0_IVB
counters.
The GL_PRIMITIVES_GENERATED query is trickier. Gen provides several
statistics registers which /almost/ match the semantics required:
- IA_PRIMITIVES_COUNT
The number of primitives fetched by the VF or IA (input assembler).
This undercounts when GS is enabled, as it can output many primitives.
- GS_PRIMITIVES_COUNT
The number of primitives output by the GS. Unfortunately, this
doesn't increment unless the GS unit is actually enabled, and it
usually isn't.
- SO_PRIM_STORAGE_NEEDED*_IVB
The amount of space needed to write primitives output by transform
feedback. These naturally only work when transform feedback is on.
We'd also have to add the counters for all four streams.
- CL_INVOCATION_COUNT
The number of primitives processed by the clipper. This doesn't work
if the GS or SOL throw away primitives for rasterizer discard.
However, it does increment even if the clipper is in REJECT_ALL mode.
Dynamically switching between counters would be painfully complicated,
especially since GS, rasterizer discard, and transform feedback can all
be switched on and off repeatedly during a single query.
The most usable counter is CL_INVOCATION_COUNT. The previous two
patches reworked rasterizer discard support so that all primitives hit
the clipper, making this work.
v2: Occlusion query bug fixes removed and squashed in earlier patches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This has more of a negative impact than the previous patch, as on Gen6
passing primitives through to the clipper means we actually have to make
the GS thread write them to the URB.
I don't see another good solution though, and rasterizer discard is not
the most common of cases, so hopefully it won't be too terrible.
v2: Add a perf_debug; resolve rebase conflicts on the brw dirty flags;
remove the rasterizer_discard field from brw_gs_prog_key.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v1]
Reviewed-by: Paul Berry <stereotype441@gmail.com>
In order to implement the GL_PRIMITIVES_GENERATED query in a sane
fashion on our hardware, we can't discard primitives until the clipper.
The patch after next explains the rationale.
By setting the clipper to REJECT_ALL mode, all primitives get thrown away,
so rendering is still appropriately disabled.
This may negatively impact performance in the rasterizer discard case,
but it's unclear how much and this hasn't been observed to be a
bottleneck in any application we've looked at. The clipper is the very
next stage in the pipeline, so I don't think it will be terrible.
v2: Add a perf_debug; resolve rebase conflicts on the brw dirty flags.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We don't currently use the clipper statistics, but we'll soon use
CL_INVOCATIONS_COUNT to implement the GL_PRIMITIVES_GENERATED query.
The number of primitives generated is not supposed to be altered during
operations such as glGenerateMipmap.
Prevents spec/EXT_transform_feedback/generatemipmap prims_generated
from breaking when we start using pipeline statistics registers to
implement the GL_PRIMITIVES_GENERATED query in a few commits.
v2: Use the BRW_NEW_META_IN_PROGRESS flag for correct state handling.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v1]
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This will allow us to disable statistics during meta operations.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Hardware contexts greatly simplify the query object code. The pipeline
statistics counters get saved and restored with the context, which means
that we don't need to worry about other workloads polluting them.
This means that we can simply write a single pair of values (one at
BeginQuery and one at EndQuery) rather than a series of pairs. This
also means we don't need to worry about the BO getting full. We also
don't need to delay BO allocation and starting snapshot until the first
draw.
The generation split here is a little off: technically, Ironlake can also
support hardware contexts. However, the kernel currently doesn't, and
even if it were to do so someday, we'd need to wait a while before
bumping the kernel requirement to take advantage of it.
v2: Incorporate Paul's feedback.
- Clarify which functions are Gen4/5-only via assertions and comments.
- Change how driver hook initialization happens.
- Update comments.
- Squash a bug fix from a later commit here where it belongs.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> [v1]
Acked-by: Paul Berry <stereotype441@gmail.com>
BLORP is used for operations like glClear, glCopyTexImage, and
glBlitFramebuffer which aren't supposed to contribute fragments toward
occlusion queries.
This prevents Piglit tests from breaking in the next commit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Hardware contexts are necessary to reasonably support OpenGL 3.2.
In particular, we currently maintain software counters for transform
feedback buffer offsets and counters, which relies on knowing the number
of primitives generated. Geometry shaders violate that assumption.
At the time of writing, Debian has moved to Kernel 3.8, which means most
people probably have a newer kernel by now. It's also worth noting that
this patch won't land until Mesa 10 which is currently targeted for
September. By that point, even more people will have a newer kernel.
Also, don't bother trying to allocate contexts on pre-Gen6, as it
currently will always fail, and if this changes in the future, we'll
need to reevaluate our hw_ctx/gen checks.
This patch leaves the code for flagging BRW_NEW_CONTEXT on new
batchbuffers if hw_ctx == NULL since that still occurs pre-Gen6.
Also remove the Gen7+ check for kernel 3.3, since it's now redundant.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Kernel 3.3 introduced the SOL reset execbuf parameter, needed for GL 3.0
on Ivybridge. Bumping the requirement will give an obvious error
message rather than simply reporting GL 2.1.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
brw_link_shader() unconditionally calls lower_vector_insert() with true
as the second parameter. This means that both constant and variable
indexed expressions will get lowered, so we should never see this in the
backend.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
do_vec_index_to_swizzle() should remove any vector extract operations
with a constant index. It's unconditionally called from
do_common_optimization().
do_vec_index_to_cond_assign() should remove the rest, and it is
unconditionally called from brw_link_shader(). This means that we
should never see ir_binop_vector_extract in the backend.
Silences compiler warnings.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Now that we can handle it both for sampling and as depth/stencil enable it.
Passes nearly all additional piglit tests which are now performed, with two
exceptions (one being a framebuffer blit which fails for all other formats
including stencil too as we don't support stencil blits, the other reporting
a unexpected GL error so doesn't look to be llvmpipe's fault).
We need to split up the depth and stencil values in this case, and there's
some new logic required to handle float depth and stencil simultaneously.
Also make sure we get the 64bit zs clear values and masks propagated
correctly.
We do rendering to linear color buffers for quite some time, and since
switching to linear depth buffers all the tiled/linear logic was unused.
So get rid of (most) of it - there's still some LAYOUT_NONE things and
late allocation of resources which probably could be simplified.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The code avoided first_layer parameter in the sampler interface (and needing
to do another calculation at runtime) by fixing up the base texture pointer
instead. Unfortunately, this didn't actually work as we have mip-first
texture layout so fixing up the base ptr by a fixed amount is very wrong if
there are mipmaps present. The wrong offsets caused misrendering and crashes.
Fix this by just adjusting the individual mip level offsets instead.
Spotted by Jose.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Since we can only sample either depth or stencil but not both only load
the required bits which makes things a bit easier (it requires special
handling since the format doesn't fit into 32bit).
The logic for deciding if depth or stencil should be sampled is a bit odd,
but seems to be what other drivers and statetrackers do: if it's a format with
both depth and stencil (or just with depth) then sample depth, for sampling
stencil a sampler view format with only stencil is required.
Also while here fix up stencil sampling for other formats as well, though
this isn't supported by mesa (ARB_stencil_texturing), and while blits would
use it they don't work neither since they'd also need stencil export.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
I don't know what this code was trying to do but whatever it was it couldn't
have worked since negation of integer boolean inputs while not specified as
outright illegal (not yet at least) won't do anything since it doesn't affect
the result of comparison with zero at all. In fact it looks like the whole
instruction can just be omitted.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Now that the rb has a reference to the teximage, we didn't need anything
else out of the attachment.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We keep having to pass the attachments around with our gl_renderbuffers
because that's the only way to find what the gl_renderbuffer actually
refers to. This is a step toward removing that (though drivers still need
the Zoffset as well).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is the opportunity that radeon and intel drivers rely on for flushing
render targets that may get reused as textures. Before EGL, that only
happened for GL_TEXTURE attachments.
Fixes piglits:
KHR_gl_renderbuffer_image/renderbuffer-texture
OES_EGL_image/renderbuffer-texture
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This change was meant as a stepping stone to use PMADDUBSW SSSE3
instruction, but actually this refactoring by itself yields a 10%
speedup on texture intensive shaders (e.g, Google Earth's ocean water
w/o S3TC on a Ivy Bridge machine), while giving yielding exactly the
same results, whereas PMADDUBSW only gave an extra 5%, at the expense of
2bits of precision in the interpolation.
I belive that the speedup of this change comes from the reduced register
pressure (as 8.8 fixed point intermediates take twice the space of 8bit
unorm).
Also, not dealing with 8.8 simplifies lp_bld_sample_aos.c code
substantially -- it's no longer necessary to have code duplicated for
low and high register halfs.
Note about lp_build_sample_mipmap(): the path for num_quads > 1 is never
executed (as it is faster on AVX to split the 256bit wide texture
computation into two 128bit chunks, in order to leverage integer
opcodes). This path might be useful in the future, so in order to
verify this change did not break that path I had to apply this change:
@@ -1662,11 +1662,11 @@ lp_build_sample_soa(struct gallivm_state *gallivm,
/*
* we only try 8-wide sampling with soa as it appears to
* be a loss with aos with AVX (but it should work).
* (It should be faster if we'd support avx2)
*/
- if (num_quads == 1 || !use_aos) {
+ if (/* num_quads == 1 || ! */ use_aos) {
if (num_quads > 1) {
if (mip_filter == PIPE_TEX_MIPFILTER_NONE) {
LLVMValueRef index0 = lp_build_const_int32(gallivm, 0);
/*
and then run texfilt mesademo:
LP_NATIVE_VECTOR_WIDTH=256 ./texfilt
Ran whole piglit without regressions.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The SROA and function inliner passes are espically important, because
they optimize away unsupported features: functions and indirect
private memory access.
When an application is using PBOs, we attempt to use the BLT engine to
perform ReadPixels. If that fails due to some restrictions, it's useful
to raise a performance warning.
In the non-PBO case, we always use a CPU mapping since getting the data
into client memory requires a CPU-side copy. This is a very common case,
so raising a performance warning is annoying. In particular, apitrace's
image dumping code hits this path, causing it to print hundreds of
thousands of performance warnings via ARB_debug_output. This tends to
obscure actual errors or other important messages.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
When intel_finalize_mipmap_tree() calls intel_miptree_copy_teximage()
to reassemble a depth miptree that has been broken apart into pieces
(to deal with misalignment of levels/layers within the miptree), it
just copies the depth data, not the HiZ data. This is reasonable,
since the alignment restrictions of HiZ are a large part of the reason
why the miptree had to be broken apart in the first place. However,
in order for the depth copy to be sufficient, we need to do a depth
resolve first, to make sure any deferred depth writes that are in the
HiZ buffer get performed.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64662 and
https://bugs.freedesktop.org/show_bug.cgi?id=64659.
NOTE: This is a candidate for stable release branches.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Whether HiZ is enalbed or not, separate stencil is supported and enforced on
GEN7+. Now that we support separate stencil resources, we know how to emit
3DSTATE_STENCIL_BUFFER.
For allocations, we need to support stencil-only and separate stencil
resources. For mapping, we need to support software tiling and
packing/unpacking for separate stencil resources.
There were 2 issues with it:
1) The texture format which should be used for texturing was only set
in gl_texture_image::TexFormat, which wasn't used for sampler views.
2) Textures are sometimes reallocated under some circumstances
in st_finalize_texture, which is unacceptable if the texture comes
from a window system.
The issues are resolved as follows:
1) If surface_based is true (texture_from_pixmap, etc.), store the format
in a new variable st_texture_object::surface_format.
2) Don't reallocate a surface-based texture in st_finalize_texture.
Also don't use st_ChooseTextureFormat is st_context_teximage, because
the format is dictated by the caller.
This fixes the glx-tfp piglit test.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This fixes and enables texturing with compressed MSAA colorbuffers
on Evergreen and Cayman. For the first time, multisample textures work
on Cayman.
This requires the libdrm flag RADEON_SURF_FMASK.
v2: require libdrm_radeon 2.4.45
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This should have no change on driver operation, but it means that when you
wonder why some format isn't supported natively, you can just look at the
table above, instead of wondering if maybe there's an appropriate entry in
the surface formats table that is already supported.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously we would expand it to RGBA_FLOAT16. This format now comes out
as framebuffer incomplete, but it seems worth the memory savings if that's
what people are asking for (and GL3 does list it under "texture-only"
color formats)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The next commit introduces what is apparently our first one, which tripped
over this in glReadPixels.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is a step on the way to removing some of our code for forcing alpha
to 1, but I want easy bisecting so I'll add groups of formats separately.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers now clamp this to the appropriate range for the bound
stencil buffer when emitting stencil state.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Clamps the stencil reference value to the range representable in the
currently-bound draw framebuffer's stencil attachment.
V2: Add spec quote.
NOTE: This is a candidate for stable branches.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Always check if a bo is busy in choose_transfer_method() since we always need
to map it in either map() or unmap(). Also determine how a bo is mapped in
choose_transfer_method().
The indices are not consecutive when using the geometry shader,
which means we were extracting non existing values. Create
an array of linear indices and always use it instead of the passed
indices. Found by Jose.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Pass in the size of the index buffer, when available, and use it
to handle out of bounds conditions. The behavior in the case of
an overflow needs to be the same as with other overflows in the
vertex processing pipeline meaning that a vertex should still
be generated but all attributes in it set to zero.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
the number of vertices to fetch doesn't necessarily equal the
total number of input vertices, e.g. we might want to fetch
a single vertex but then draw it twice. Lets use the correct
number of input vertices in the statistics.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We would crash when stride was bigger than the size of the buffer.
The correct behavior is to just fetch zero's in this case.
Unfortunatly with user_buffer's there's no way to validate the size
because currently we're just not getting it. Adjust the draw interface
to pass the size along the mapped buffer, which works perfectly
for buffer backed vertex_buffers and, in future, it will allow
us to plumb user_buffer sizes through the same interface.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The support is analogous to the way we handle indirect addressing
in temporaries, except that we don't have to worry about storing
(after declarations) and thus we'll able to keep using the old
code when indirect addressing isn't used. In other words we're
still using constants directly, unless the instruction has
immediate register with indirect addressing.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Static initialization of internal libstdc++ data related to iostream
causes segfaults with some apps.
This patch replaces all uses of std::ostream and std::ostringstream in sb
with custom lightweight classes.
Prevents segfaults with ut2004demo and probably some other old apps.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Parsing and ir construction is required for optimization only,
it's unnecessary if we only need to print shader dump.
This should make new disassembler more tolerant to any new
features in the bytecode.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Resource mapping is distinct from resource allocation, and is going to get
more and more complex. Move the related functions to a new file to make the
separation clear.
Mesa's extension table incorrectly lists this GL_OES_texture_npot as
ES2-only. It's also an ES1 extension. This patch adds ES1 to the
extensions API mask.
From the GL_OES_texture_npot spec:
OpenGL ES 1.0 or OpenGL ES 2.0 is required. This extension is
written against OpenGL ES 1.1.12 and OpenGL ES 2.0.25.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that all the places that used to generate array derefeneces of
vectors have been changed to generate either ir_binop_vector_extract or
ir_triop_vector_insert (or both), remove all support for dealing with
this deprecated construct.
As an added safeguard, modify ir_validate to reject ir_dereference_array
of a vector.
v2: Convert tabs to spaces. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Like with type conversions on out parameters, some extra copies need to
occur to handle these cases. The fundamental problem is that
ir_binop_vector_extract is not an lvalue, but out and inout parameters
must be lvalues. A previous patch delt with a similar problem in the
LHS of ir_assignment.
v2: Convert tabs to spaces. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Variable indexing into vectors using ir_dereference_array is being
removed, so this lowering pass has to generate something different.
v2: Convert tabs to spaces. Suggested by Eric.
v3: Simplify code slightly by assuming that elements of
gl_ClipDistanceMESA will always be vec4. Suggested by Paul.
v4: Fairly substantial rewrite based on the rewrite of "glsl: Convert
lower_clip_distance_visitor to be an ir_rvalue_visitor"
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
ir_call was changed long ago to be a statement rather than an
expression. That makes this comment no longer valid.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Right now the lower_clip_distance_visitor lowers variable indexing into
gl_ClipDistance into variable indexing into both the array
gl_ClipDistanceMESA and the vectors of that array. For example,
gl_ClipDistance[i] = f;
becomes
gl_ClipDistanceMESA[i >> 2][i & 3] = f;
However, variable indexing into vectors using ir_dereference_array is
being removed. Instead, ir_expression with ir_triop_vector_insert will
be used. The above code will become
gl_ClipDistanceMESA[i >> 2] =
vector_insert(gl_ClipDistanceMESA[i >> 2], i & 3, f);
In order to do this, an ir_rvalue_visitor will need to be used. This
commit is really just a refactor to get ready for that.
v4: Split the least amount of refactor from the rest of the code
changes.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Now ir_dereference_array of a vector will never occur in the RHS of an
expression.
v2: Add back the { } around the if-statement body to make it more
readable. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The ast_array_index code can't know whether to generate an
ir_binop_vector_extract or an ir_triop_vector_insert. Instead it will
always generate ir_binop_vector_extract, and the LHS and RHS have to be
re-written.
v2: Convert tabs to spaces. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will eventually replace do_vec_index_to_cond_assign. This lowering
pass is called in all the places where do_vec_index_to_cond_assign or
do_vec_index_to_swizzle is called.
v2: Use WRITEMASK_* instead of integer literals. Use a more concise
method of generating broadcast_index. Both suggested by Eric.
v3: Use a series of scalar compares instead of a single vector compare.
Suggested by Eric and Ken. It still uses 'if (cond) v.x = y;' instead
of conditional assignments because ir_builder doesn't do conditional
assignments, and I'd rather keep the code simple.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Lower ir_binop_vector_extract with a non-constant index to a series of
conditional moves. This is exactly like ir_dereference_array of a
vector with a non-constant index.
v2: Convert tabs to spaces. Suggested by Eric.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Lower ir_binop_vector_extract with a constant index to a swizzle. This
is exactly like ir_dereference_array of a vector with a constant index.
v2: Convert tabs to spaces. Suggested by Eric.
v3: Correctly call convert_vector_extract_to_swizzle in
ir_vec_index_to_swizzle_visitor::visit_enter(ir_call *ir). Suggested by
Ken.
v4: Use CLAMP instead of MIN2(MAX2()). Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Use a first function that extract the vector being indexed and the index
from the deref. Call the second function that does the real work.
Coming patches will add a new ir_expression for variable indexing into a
vector. Having the lowering pass split into two functions will make it
much easier to lower the new ir_expression.
v2: Convert tabs to spaces. Suggested by Eric.
v3: Move some bits from a later patch back to this patch so that it
actually compiles. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The new opcode is used to generate a new vector with a single field from
the source vector replaced. This will eventually replace
ir_dereference_array of vectors in the LHS of assignments.
v2: Convert tabs to spaces. Suggested by Eric.
v3: Add constant expression handling for ir_triop_vector_insert. This
prevents the constant matrix inversion tests from regressing. Duh.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The new opcode is used to get a single field from a vector. The field
index may not be constant. This will eventually replace
ir_dereference_array of vectors. This is similar to the extractelement
instruction in LLVM IR.
http://llvm.org/docs/LangRef.html#extractelement-instruction
v2: Convert tabs to spaces. Suggested by Eric.
v3: Add array index range checking to ir_binop_vector_extract constant
expression handling. Suggested by Ken.
v4: Use CLAMP instead of MIN2(MAX2()). Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Commit b765740 (glsl: Pass struct shader_compiler_options into
do_common_optimization.) added a new parameter to
do_common_optimization() but didn't update test_optpass.cpp, causing
"make check" to break.
This patch makes the proper updates to test_optpass.cpp so that the
build succeeds again.
This pass flips (matrix * vector) operations to (vector *
matrixTranspose) for certain built-in matrices (currently
gl_ModelViewProjectionMatrix and gl_TextureMatrix).
This is equivalent, but results in dot products rather than multiplies
and adds. On some hardware, this is more efficient.
This pass is conditionalized on ctx->mvp_with_dp4, the flag drivers set
to indicate they prefer dot products.
Improves performance in Lightsmark by 1.01131% +/- 0.162069% (n = 10)
on a Haswell GT2 system. Passes Piglit on Ivybridge.
v2: Use struct gl_shader_compiler_options instead of plumbing through
another boolean flag for this purpose.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Doing matrix multiplies with DP4s is fewer instructions than MUL/ADD,
especially since we don't support MAD in the vertex shader.
Not observed to improve performance in any fixed function applications,
but is useful for the next patch.
I've left this unset for the fragment shader because the scalar backend
can't use DP4 and does have MAD support.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This flag essentially tells the compiler whether it prefers
dot products or multiply/adds for matrix operations. As such,
ShaderCompilerOptions seems like the right place for it.
This also lets us specify it on a per-stage basis. This patch makes all
existing users set the flag for the Vertex Shader stage only, as it's
currently only used for fixed-function vertex programs. That will
change soon, and I wanted to preserve the existing behavior.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
do_common_optimization may need to make choices about whether to emit
certain kinds of instructions. gl_context::ShaderCompilerOptions
contains exactly that information, so it makes sense to pass it in.
Rather than passing the whole array, pass the structure for the stage
that's currently being worked on.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We can't include shaderobj.h from the standalone utilities, so we
unfortunately have to copy this function.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Marek added these new formats in commit f9fa725690, but
without comments relating to the packing. Sometimes the naming is
confusing, so these comments are helpful in determining whether two
formats are compatible.
The new comments are based on my reading of format_unpack.c.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
- don't reference a buffer for a local variable
(that's never useful unless it can be the only reference to the buffer)
- check if the buffer is not NULL
- set buffer_size as specified with BindBufferRange
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: move the flagging from intel_bufferobj_data to intel_bufferobj_alloc_buffer
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If Const.CheckArrayBounds is false, the only code using _MaxElement is
glDrawRangeElements, so I changed it and explained in the code why
_MaxElement is not very useful there.
BTW, the big magic number was copied to the letter
from _mesa_update_array_max_element.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The limits should not be different and OpenGL requires both to be at least 32,
which is also the maximum limit on radeon.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Const.MaxTextureImageUnits -> Const.FragmentProgram.MaxTextureImageUnits
Const.MaxVertexTextureImageUnits -> Const.VertexProgram.MaxTextureImageUnits
etc.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Shaders are unified on most hardware (= same limits in all stages).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
We were not allowed to say the "GT3" name, but we really needed to
have the PCI IDs because too many people had such machines, so we had
to make the GT3 machines work as GT2.
Let's just say that GT2_PLUS was a short for GT2_PLUS_1 :)
NOTE: This is a candidate for stable branches.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Haswell's GT3 variant offers 32kB of URB space for push constants, while
GT1 and GT2 match Ivybridge, providing 16kB. Update the code to reserve
the full 32kB on GT3.
v2: Specify push constant size correctly. I thought GT3 reinterpreted
the value as multiples of 2kB, but it doesn't. You simply have to
program an even number.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This is the same change as the previous commit to the FS. A very few VSes
are regressed by 1 or 2 instructions, which look recoverable with a bit
more dead code elimination.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, we would sometimes not consider a write to a register to
extend the end of the interval, nor would we consider a read before a
write to extend the start. This made for a bunch of complicated logic
related to how to treat the results when dead code might be present.
Instead, just extend the interval and fix dead code elimination to know
how to remove it.
Interestingly, this actually results in a tiny bit more optimization:
total instructions in shared programs: 1391220 -> 1390799 (-0.03%)
instructions in affected programs: 14037 -> 13616 (-3.00%)
v2: Fix a theoretical problem with the simd16 workaround if dst == src,
where we would revert the bump of the live range.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Now tells Gallium that ilo supports primitive restart.
Updated ilo_draw_vbo to be able to check that the indexed
primitive being rendered can actually be supported in HW. If not,
will break up into individual prims similar to what Mesa does.
[olv: a minor fix after rebasing and formatting]
Before, if we failed to allocate the index buffer we'd silently
return from st_draw_vbo() without drawing anything. We should
raise GL_OUT_OF_MEMORY to give some indication that something went
wrong.
Note: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
It helps a bit with vertex shader performance on i915g
(a couple percent faster with openarena).
I have tried most other passes, and they weren't showing
any measurable improvement. Note that my vertex shaders
didn't have loops, so maybe the loop optimizations could
still be useful in the future.
Reviewed-by: Brian Paul <brianp@vmware.com>
Unfortunately the surface formats table is now splattered across multiple
chapters. All surface format enums from brw_defines.h are present, but
only support for them that is mentioned in the public specs is included
here.
v2 (from Ken): Mark R32G32B32A32_SFIXED as unsupported on Ivybridge.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for drivers that
use Mesa IR.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Fabian Bieler <fabianbieler@fastmail.fm>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test shaders/glsl-copy-propagation-self-2 for gallium drivers.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Fabian Bieler <fabianbieler@fastmail.fm>
Reviewed-by: Brian Paul <brianp@vmware.com>
The constant packets for gen6 are too small for gen7, and while IVB seems
happy with them HSW blows up. Fix it by emitting the correct packets on
gen7, for all stages.
v2: Include the packets instead of just skipping them.
NOTE: This is a candidate for the stable branches.
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Emit EGL_BAD_CONTEXT if the user passes a context to
eglCreateImageKHR(type=EGL_ANDROID_image_native_buffer).
From the EGL_ANDROID_image_native_buffer spec:
* If <target> is EGL_NATIVE_BUFFER_ANDROID and <ctx> is not
EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
Note: This is a candidate for the stable branches.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This basically reverts commit
2acc719374.
With the previous change, we're not batchbuffer limited any
longer. So we actually start seeing a performance difference
between X and Y tiling. X tiling is funny because it is
faster for screen-aligned quads but slower in games. So let's
use Y tiling which is 10% faster overall.
Now that we don't throttle at every batchbuffer, we can shrink
the size of batchbuffers to achieve early flushing. This gives
a significant speed boost in a lot of games (on the order of
20%).
It should be TGSI_TYPE_UNSIGNED, not TGSI_TYPE_FLOAT.
Fixed also gallivm not_emit_cpu() to use uint build context.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Move the body of tgsi_opcode_infer_dst_type() to a new helper function,
tgsi_opcode_infer_type(), and call the helper function from
tgsi_opcode_infer_dst_type(). The diff looks complicated simply because the
code is moved around.
A following commit will make tgsi_opcode_infer_src_type() call
tgsi_opcode_infer_type().
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Reorder opcodes by their assigned numbers. This makes it easier to see the
differences between tgsi_opcode_infer_src_type() and
tgsi_opcode_infer_dst_type().
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Make use of tgsi_util_get_texture_coord_dim() to replace the big switch table.
There is a subtle difference with this change. When TXP is used with an array
texture, the layer is now also projected. This behavior matches the TGSI doc.
Since GLSL does not allow TXP on an array texture, I am not sure which
behavior is correct or preferred.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
This util function returns the dimension of the texture coordinates for a
texture target, and the location of the shadow reference value.
For example, when the texture target is TGSI_TEXTURE_SHADOW2D, the dimension
of the texture coordinates is 2, and the location of the ref value is 2
(that is, the Z channel).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Roland Scheidegger <sroland@vmware.com>
Adds the remaining integer opcodes, and some opcodes are moved to more
appropriate places, along with getting rid of the (already nearly empty)
ps_2_x section. Though the CAP bits for some of these are still a bit in
the air so the documentation isn't quite as watertight as is desirable.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We can replace CNDxx with MOV (and possibly eliminate after
propagation) in following cases:
If src1 is equal to src2 in CNDxx instruction then the result doesn't
depend on condition and we can replace the instruction with
"MOV dst, src1".
If src0 is const then we can evaluate the condition at compile time and
also replace it with MOV.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Use the same limit for kcache constants in alu group on r6xx as on other
chips (two const pairs). Relaxing this will require additional checks to
make sure that all 4 consts in the group come from 2 kcache sets (clause
limit), probably without noticeable improvements of shader performance.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Everyone was doing effectively the same thing, except for some funky code
reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
using the texture's _BaseFormat. swrast's sRGB handling is left in place,
though it should be done by using _mesa_get_render_format() at render time
instead (as-is, it will miss updates to GL_FRAMEBUFFER_SRGB).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We're looking for the logical width of our level, which is what
image->Width2/Height2 is. The previous code relied on MSAA textures being
only level 0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There was some comment about trying to avoid marking resolves in
updownsample, but if the downsample is never actually rendered to, then
the required resolve tracked in the downsample will never be executed, so
who cares?
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Only lower bitfieldInsert to BFM+BFI (and don't lower
bitfieldExtract at all) since three-source instructions are now
usable in the vertex shader.
v3: Lower bitfield_insert in the same pass with everything else, since
it doesn't produce any instructions to be lowered (the other two
lowering passes that were in a previous iteration of this series
emitted subtractions which needed to be lowered).
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> [v2]
v2: Rebase on LRP addition.
Use fix_3src_operand() when emitting BFE and BFI2.
Add BFE and BFI2 to is_3src_inst check in
brw_vec4_copy_propagation.cpp.
Subtract result of FBH from 31 (unless an error) to convert
MSB counts to LSB counts
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Don't bother scalarizing ir_binop_bfm, since its results are
identical for all channels.
v2: Subtract result of FBH from 31 (unless an error) to convert
MSB counts to LSB counts.
v3: Use op0->clone() in ir_triop_bfi to prevent (var_ref
channel_expressions) from appearing multiple times in the IR.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> [v2]
Specifically
bfe - for bitfieldExtract()
bfi1 and bfi2 - for bitfieldInsert()
bfrev - for bitfieldReverse()
cbit - for bitCount()
fbh - for findMSB()
fbl - for findLSB()
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Also update asserts to allow BFE and BFI2, which take (unsigned)
doubleword arguments.
v2: Allow BRW_REGISTER_TYPE_UD for src1 and src2 as well.
Assert that src2.type (instead of src0.type) matches dest.type since
it's the primary argument and src0 and src1 might correctly have
different types.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> [v1]
i965/Gen7+ and Radeon/Evergreen+ have bfm/bfi instructions to implement
bitfieldInsert() from ARB_gpu_shader5.
v2: Add ir_binop_bfm and ir_triop_bfi to st_glsl_to_tgsi.cpp.
Remove spurious temporary assignment and dereference.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
v2: Order bits from LSB end (31 - count) for ir_unop_find_msb.
v3: Add ir_triop_bitfield_extract as an exception to the op[0]->type ==
op[1]->type assertion in ir_constant_expression.cpp.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> [v2]
This library is very small, so there is not much to gain from building
it as a shared library. Also, when linking statically with LLVM, a
shared libradeonllvm exports LLVM symbols and creates problems when
used with other shared objects that also link statically to LLVM.
Reviewed-by: Mathias.Froehlich@web.de
The LLVM C API is considered stable and should never change, so it
is much more desirable to use than the LLVM C++ API, which is constantly in
flux.
v2:
- Split target initialization and lookup into separate functions
Reviewed-by: Mathias.Froehlich@web.de
This does not solve all of the problems with using LLVM in a
multithreaded enivronment, but it should help in some cases.
Reviewed-by: Mathias.Froehlich@web.de
This leads to crashes when multiple threads try to compile compute
shaders in the same time.
Fixes a crash in bfgminer when using more than one thread.
Of the 3 controls in the extension, one was kept in GL core and the other
two were explicitly deprecated and the reasonable default behavior was
encoded in the spec. By not exposing the extension, we avoid shader
recompiles when switching between float and unorm color buffers.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This cleans up some funny-looking code in some unigine shaders I was
looking at. Also slightly helps on planeshift and a few shaders in an
upcoming Valve release.
total instructions in shared programs: 1653715 -> 1653587 (-0.01%)
instructions in affected programs: 16550 -> 16422 (-0.77%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It should be unsigned, not enum pipe_flush_flags.
Fixed a build error:
src/gallium/state_trackers/egl/android/native_android.cpp:426:29: error:
invalid conversion from 'int' to 'pipe_flush_flags' [-fpermissive]
v2: replace all occurrences of enum pipe_flush_flags by unsigned
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
[olv: document the parameter now that the type is unsigned]
Improves glb2.7 performance at a misaligned size by 2.3% +/- 0.7% (n=11).
The workaround was to avoid bad primitive/surface sizes, but that's worked
around as of a14dc4f92c. (One might note
that pre-gen7 we don't know that the right half of an 8x4 at the right
edge is actually our pixels, but we're already clobbering those pixels for
depth resolves anyway and more work would be required to avoid that).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
A surprising number of apps and benchmarks have poor code like this:
glBegin(GL_LINE_STRIP);
glVertex(v1);
glVertex(v2);
glEnd();
// Possibly some no-op state changes here
glBegin(GL_LINE_STRIP);
glVertex(v3);
glVertex(v4);
glEnd();
// repeat many, many times.
The above sequence can be converted into:
glBegin(GL_LINES);
glVertex(v1);
glVertex(v2);
glVertex(v3);
glVertex(v4);
glEnd();
Similarly for GL_POINTS, GL_TRIANGLES, etc.
Merging was already implemented for GL_QUADS in the display list code.
Now other prim types are handled and it's also done for immediate mode.
In one case:
before after
-----------------------------------------------
number of st_draw_vbo() calls: 141 45
number of _mesa_prims issued: 7520 632
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
gallium lies. buffer_size is not actually buffer_size but available
size, which is 'buffer_size - buffer_offset' so by adding buffer
offset we'd incorrectly compute overflow.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In ureg src registers could have an indirect register that was
either a temp or an addr register, while dst registers allowed
only addr. That made moving between them a little difficult so
make them behave the same way and allow temp's and addr registers
as indirect files for both (tgsi supports it, just ureg didn't).
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
A lot of them were missing. Others were moved from the Compute ISA
to a new Integer ISA section as that seemed more appropriate.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Eliminating this we no longer need to copy between linear and swizzled layout.
This is probably not quite ideal since it's a bit more work for now, could do
some optimizations by moving depth testing outside the fragment shader loop
(but tricky for early depth test as we don't have neither the mask nor the
interpolated z in the right order handy).
The large amount of tile/untile code is no longer needed will be deleted
in next commit.
No piglit regressions.
v2: change a forgotten LAYOUT_NONE to LAYOUT_LINEAR.
v3: fix (bogus) uninitialized variable warnings, add comments, fix a bad type
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Assigning a struct only copies the members - any padding is left as is.
Thus this code:
struct foo_t foo;
foo = bar;
leaves the padding of foo intact, ie uninitialized random garbage.
This patch fixes constant shader recompiles by initializing the struct
to zero. For completeness, memcpy is used to copy the key to the shader
struct.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
One build system for linux/unix only drivers should be enough.
Additionally the nouveau target was disabled anyway.
Acked-by: Jose Fonseca <jfonseca@vmware.com>
post_scheduler clears interference set for reallocatable values when
the value becomes live first time, and then updates it to take into
account modified order of operations, but this was not handled properly
if the value appears first time as a source in copy operation.
Fixes issues with webgl demo: http://madebyevan.com/webgl-water/
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
New disassembler is not completely isolated yet from further processing
in r600g/sb that is not required for printing the dump, so it has higher
probability to fail in case of any unexpected features in the bytecode.
This patch adds "sbdisasm" flag for R600_DEBUG that allows to use new
disassembler in r600g/sb for shader dumps when shader optimization
is not enabled.
If shader optimization is enabled, new disassembler is used by default.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Mesa build is too complex to rely on successful builds. On refactorings
it is always a good idea to use git grep to prevent missing cases:
$ git grep u_assembled_primitive
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c: u_assembled_primitive(in_prim);
The differences from the previous releases that affect st/egl are
- logging macros are prefixed with an 'A'
- dequeueBuffer() and enqueueBuffer() require an additoinal argument for
fence fd, acquired from libsync
Additionally, include gralloc_drm.h with extern "C".
The function returns the number of reduced/tessellated primitives for the
given vertex count.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Zack Rusin <zackr@vmware.com>
Switch to '>=' for comparisons, and it becomes obvious that the comparison for
PIPE_PRIM_QUAD_STRIP was wrong.
Add minimum vertex count check for PIPE_PRIM_LINE_LOOP. Return 1 for
PIPE_PRIM_POLYGON with 3 vertices.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Zack Rusin <zackr@vmware.com>
As a side effect, primitives with adjacency are now correctly validated.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Zack Rusin <zackr@vmware.com>
Move together (or add) functions to decompose/reduce/assemble a primitive,
give them consistent names, and document them. Add u_prim_vertex_count() so
that the vertex count information can be used elsewhere.
u_assembled_primitive() will be removed in a folow-on commit.
[olv: fix a warning when -Wold-style-declaration is enabled]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Zack Rusin <zackr@vmware.com>
While this is ignorant of dependency control, it's still good for a 0.39%
+/- 0.08% performance improvement on GLBenchmark 2.7 (n=548)
v2: Rewrite as a subclass of the base class for the FS instruction
scheduler, inheriting the same latency information.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These will get virtualized as we add VS scheduling support.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
I need this so I can look at vec4 and fs registers' files from the same
.cpp file without namespaces. As far as I can tell we never rely on the
particular numerical values of the files, though I thought it sounded like
a good idea when doing the VS (it turns out having 0 be BAD_FILE is nicer).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This will free instruction scheduling to make better choices. No
statistically significant performance difference on GLB2.7 (n=93).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
instead of crashing just fill zeros at the input slots that don't
match, that's the mandated behavior and it avoids debug asserts.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
It's valid because we reuse certain arithmetic operations
for both signed and unsigned types (e.g. uadd, umad, which
have a bit unfortunate naming)
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The GPU apparently goes looking for constants even though there are no
shader stages enabled, and gets stuck because we haven't told it there are
no constants to collect. If any other user of the 3D pipeline had run
(even the Render accel of the X server!) since power on, then the in-GPU
constant buffers would have been set up with some contents we didn't use,
and we would succeed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56416
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Dave Airlie <airlied@redhat.com>
NOTE: This is a candidate for the stable branches.
We are already emitting a EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT packet
when this flush flag is set, so flushing the dest caches with a
SURFACE_SYNC should not be necessary.
The motivation for this change is that emitting a SURFACE_SYNC packet with
the CB bits set was causing compute shaders to hang on Cayman.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Remove all the glDraw* functions from the GLvertexformat structure.
The point of that dispatch struct is to handle all the functions which
dispatch differently depending on whether we're inside glBegin/End.
glDraw* are never allowed inside glBegin/End so we can remove those
entries.
This simplifies the code paths and gets rid of quite a bit of code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
If the currently compiled primitive state is PRIM_UNKNOWN we should
not return true from _mesa_inside_dlist_begin_end(). This lets us
simplify the calls to that function.
Note, the call to _mesa_inside_dlist_begin_end() in vbo_save_EndList()
should have probably been checking for PRIM_UNKNOWN too, but it wasn't.
So there's no code change change.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is set during context creation/initialization. We know we're
not inside glBegin/glEnd at this point so use PRIM_OUTSIDE_BEGIN_END.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The old code didn't make sense. The clause in question did the
same thing as the next else-if clause. If we're already executing
a glBegin/End pair and we're starting a new primitive, that's an
error.
Fixes more failures in piglit gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Functions like glDrawArrays, glDrawElements, etc. are illegal between
glBegin/glEnd and should generate GL_INVALID_OPERATION.
Fixes several piglit gl-1.0-beginend-coverage failures.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The _save_OBE_DrawArrays/Elements/RangeElements() functions are
called when building a display list and we know we're outside
glBegin/End.
We shouldn't call the normal _mesa_validate_DrawArrays/Elements()
functions here because those functions only work properly in immediate
mode or during dlist execution. At dlist compile time, we can't call
_mesa_update_state(), etc. and examine the current state since it won't
apply when the list is executed later.
Fixes several failures in piglit's gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
If we're in GL_COMPILE_AND_EXECUTE mode and inside glBegin, calling
glEndList() should generate an error.
Fixes a failure in piglit's gl-1.0-beginend-coverage test.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The old code was hard to understand and not entirely correct.
Note that PRIM_INSIDE_UNKNOWN_PRIM is no longer set anywhere so
we'll be able to remove that next.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
...in terms of new _mesa_is_valid_prim_mode(). We need a mode validater
function that doesn't depend on current state for the display list code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These values pertain to display lists, and the new types of geometry
shader primitives can be used in display lists.
And add new PRIM_MAX constant for follow-on changes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This removes the test for _mesa_inside_dlist_begin_end().
If ctx->Driver.CurrentSavePrimitive==PRIM_UNKNOWN (the initial value),
_mesa_inside_dlist_begin_end() will, confusingly, return TRUE.
So we didn't set the ctx->ListState.Current.ShadeModel value and it
remained in its indeterminate state.
This didn't effect correctness, but it defeated the intended optimization
of dropping redundant glShadeModel() state changes in order to
coalesce sequences of drawing commands.
Verified with new piglit gl-1.0-dlist-shademodel test.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Without this patch, radeon_uvd failed to find the libdrm includes:
In file included from radeon_uvd.c:48:
../../winsys/radeon/drm/radeon_winsys.h:44:35: error:
libdrm/radeon_surface.h: No such file or directory
Signed-off-by: Lauri Kasanen <cand@gmx.com>
When checking framebuffer completeness, we test each attachment.
We verify that all attachments are consistent in terms of layers.
1. They must all be layered, or all non-layered
2. If they are layered, they must match in depth
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
If glFramebufferTexture is used, then the framebuffer attachment is
layered.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
With glFramebufferTexture, a renderbuffer may support
all layers of the texture, so we need the depth of the
renderbuffer to check for consistency which is required
for framebuffer completeness.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This like the fifth attempt to fix the issue.
Also with the new "validating" flag, we can set recalculate_inputs to FALSE
earlier in vbo_bind_arrays, because _mesa_update_state won't change it.
NOTE: This is a candidate for the stable branches.
v2: fixed a typo
Reviewed-by: Brian Paul <brianp@vmware.com>
The shadow comparitor needs to be loaded into the Z component of the
last DWord.
Fixes es3conform's shadow_execution_vert and oglconform's
shadow-grad advanced.textureGrad.1D tests on Haswell.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
According to the Ivybridge PRM, Volume 4 Part 1, page 130, in the
section for the sample_d message: "The r coordinate contains the faceid,
and the r gradients are ignored by hardware."
This doesn't match GLSL, which provides gradients for all of the
coordinates. So we would need to do some math to compute the face ID
before using sample_d. We currently don't have any code to do that.
However, we do have a lowering pass that converts textureGrad to
textureLod, which solves this problem. Since textureGrad on three
components is sufficiently obscure, it's not a performance path.
For now, only handle samplerCubeShadow; we need tests for samplerCube
and samplerCubeArray.
Fixes es3conform's shadow_comparison_frag test on Haswell.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Consider the following shader:
vec4 f(vec4 v) { return v; }
vec4 f(vec4 v);
The prototype exactly matches the signature of the earlier definition,
so there's absolutely no point in it. However, it doesn't appear to
be illegal. The GLSL 4.30 specification offers two relevant quotes:
"If a function name is declared twice with the same parameter types,
then the return types and all qualifiers must also match, and it is the
same function being declared."
"User-defined functions can have multiple declarations, but only one
definition."
In this case the same function was declared twice, and there's only one
definition, which fits both pieces of text. There doesn't appear to be
any text saying late prototypes are illegal, so presumably it's valid.
Unfortunately, it currently triggers an assertion failure:
ir_dereference_variable @ <p1> specifies undeclared variable `v' @ <p2>
When we process the second line, we look for an existing exact match so
we can enforce the one-definition rule. We then leave sig set to that
existing function, and hit sig->replace_parameters(&hir_parameters),
unfortunately nuking our existing definition's parameters (which have
actual dereferences) with the prototype's bogus unused parameters.
Simply bailing out and ignoring such late prototypes is the safest
thing to do.
Fixes Piglit's late-proto.vert as well as 3DMark/Ice Storm for Android.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
The three users of GALLIUM_PIPE_LOADER_LIBS (OpenCL, gallium-gbm,
gallium tests) don't appear to need libws_xlib.la.
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
It guarded the function prototype of pipe_loader_sw_probe, whose use (in
pipe_loader.c) and definition (in pipe_loader_sw.c) were not guarded.
Both are built into libpipe_loader.la if HAVE_LOADER_GALLIUM, which is
enable_gallium_loader in configure.ac.
Tested-by: Tom Stellard <thomas.stellard@amd.com>
Tested-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The number of samples is already available in the miptree data
structure, so there's no need to pass it in.
I suspect this may fix a subtle bug because in one case
(intel_renderbuffer_update_wrapper) we were always passing zero for
num_samples, even though the buffer in question was not guaranteed to
be single-sampled. But I wasn't able to find a failing test case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Technically it's legal for geometry shader to not emit any
vertices. It's silly, but perfectly legal, so lets make draw
stop crashing if it happens.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The upside is less CPU overhead in fiddling with GL error handling, the
ability to use the constant color write message in most cases, and no GLSL
clear shaders appearing in MESA_GLSL=dump output. The downside is more
batch flushing and a total recompute of GL state at the end of blorp.
However, if we're ever going to use the fast color clear feature of CMS
surfaces, we'll need this anyway since it requires very special state
setup.
This increases the fail rate of some the GLES3conform ARB_sync tests,
because of the initial flush at the start of blorp. The tests already
intermittently failed (because it's just a bad testing procedure), and we
can return it to its previous fail rate by fixing the initial flush.
Improves GLB2.7 performance 0.37% +/- 0.11% (n=71/70, outlier removed).
v2: Rename the key member, use the core helper for sRGB, and use
BRW_MASK_* enums, fix comment and indentation (review by Paul).
v3: Rewrite a comment, drop a silly temporary variable (review by Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: const-qualify ctx, and add a comment about the function (recommended
by Brian and Kenneth).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Improves GLB2.7 performance 0.13% +/- 0.09% (n=104/105, outliers removed).
More importantly, once color glClear()s are done through blorp in the next
commit, this reduces regression in GLES3 conformance tests that rely on
queueing up many glClear()s and having the GPU report being still busy in
an ARB_sync query after that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Collects various statistical information for each shader
and total stats for contexts.
Printed with R600_DEBUG=sb,sbstat
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
In some cases we use value::gvn_source field to link values that
are known to be equal before gvn pass (e.g. results of DOT4 in different
slots of the same alu group), but then source value may become dead later
and this confuses further passes.
This patch resets value::gvn_source to NULL in the dce_cleanup pass
if it points to dead value.
Fixes segfault during shader optimization with ETQW.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
It's not a complete register pressure tracking, yet it helps to prevent
register allocation problems in some cases where they were observed.
The problems are uncovered by false dependencies between fetch instructions
introduced by some recent changes in TGSI and/or default backend.
Sometimes we have code like this:
...
SAMPLE R5.xyzw, R5.xyzw
... store R5.xyzw somewhere
MOV R5.x, <next x coord>
MOV R5.y, <next y coord>
SAMPLE R5.xyzw, R5.xyzw
... <may be repeated a lot of times>
With 2D resources, z and w in SAMPLE src reg aren't used and can be simply
masked, but shader backend doesn't have this information, so it's
considered as data dependency by optimization algorithms.
This results in more clean shader code and may improve the quality of
optimized code produced by r600-sb due to eliminated false dependencies
in some cases.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
The remaining bits happen to do nothing that
_swrast_span_render_start()/finish() don't do.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
It's not really span code ever since we stopped using spans for S8.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
In the case of renering to windows in X, we would render to stale buffers
(or not render at all!) if you hit a MapRenderbuffer as the first thing
done to your window after new buffers are ready to be collected in DRI2.
I think this also covers the weird comment about irb->mt being missing
sometimes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
I always forget how we do this for compressed textures.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Now that everything goes through ImageSlices[], we can rely on the
driver's existing texture mapping function.
A big block of code goes away on Radeon that looks like it was to deal with
the validate that happened at SpanRenderStart, which no longer occurs since we
don't need validation for the MapTextureImage hook.
v2: Rewrite comment about ImageSlices, fix duplicated swImages, touch up
unmap loop.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Brian Paul <brianp@vmware.com>
This code is trying to deal with providing a map in the case that
AllocTexImageBuffer was called, which is hooked up to the swrast variant.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
MapTextureImage has the exact same logic, except it can also handle
swrast-allocated buffers.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
For hardware drivers with pitch alignment requirements, a
non-power-of-two-sized texture format won't end up being an integer number
of pixels per row. Also, avoids having to change our units between
MapTextureImage's rowStride and swrast's RowStride.
This doesn't fully convert the compressed texel fetch path, but does make
sure we don't drop any bits (not that we'd expect to).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
This is a step toward allowing drivers to use their normal mapping paths,
instead of requiring that all slice mappings come from an aligned offset
from the first slice's map.
This incidentally fixes missing slice handling in FXT1 swrast.
v2: Use slice height helper function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: Move slice height calculation to a helper function (recommeded by Brian).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Brian Paul <brianp@vmware.com>
This function going to get used a lot more in upcoming patches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Improves GLB2.7 performance on my HSW by 0.671455% +/- 0.225037% (n=62).
v2: Make is_valid_3src() a method of the fs_reg. (recommended by Ken)
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Improves GLB2.7 trex performance 1.01985% +/- 0.721366% on my IVB (n=10)
and by 3.38771% +/- 0.584241% (n=15) on my HSW, due to a 32x32 ARGB8888
cubemap going from untiled to tiled.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It appears that Z16 on Intel hardware is in fact slower than Z24, so
people are getting surprisingly hurt when trying to use Z16 as a
performance-versus-precision tradeoff, or when they're targeting GLES2 and
that's all you get.
GL 3.0+ have Z16 on the list of required exact format sizes, but GLES
doesn't, so choose the better-performing layout in that case. Improves
GLB 2.7 trex performance at 1920x1080 by 10.7% +/- 1.1% (n=3) on my IVB
system.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For this multi-page single statement, my thought the end was to that the
next block was mis-indented, rather than that the dropped indentation
actually indicated the end of the loop.
In almost all of our cases, getters that are turned on for only some API
variants will have an extension listed as one of the things that can
enable it, and thus api_check gets set. For extra_gl30_es3 (used for
NUM_EXTENSIONS, MAJOR_VERSION, MINOR_VERSION) on a GL 2.1 context, though,
we would check twice, not find either one, but never actually throw the
error.
While we may provide the extension, we need to tell applications that they
can't actually use it:
An implementation can either set QUERY_COUNTER_BITS_ARB to the
value 0, or to some number greater than or equal to n. If an
implementation returns 0 for QUERY_COUNTER_BITS_ARB, then the
occlusion queries will always return that zero samples passed the
occlusion test, and so an application should not use occlusion
queries on that implementation.
These are entirely based on the opcode, which is available in
backend_instruction. It makes sense to only implement them in one
place.
This changes the VS implementation of is_tex() slightly, which now
accepts FS_OPCODE_TXB and SHADER_OPCODE_LOD. However, since those
aren't generated in the VS anyway, it should be fine.
This also makes is_control_flow() available in the VS.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
only report overflow for missing targets if they're actually being
used. if the targets are missing but are not being used by any
slot in the stream output declaration we should correctly just
ignore them.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Interpolation modes other than perspective-barycentric-pixel-center (and
their associated coefficients in the WM payload) only exist in Gen6 and
later.
Unfortunately, if a varying was declared as `centroid`, we would blindly
read the nonexistant values, and so produce all manner of bad behavior
-- texture swimming, snow, etc.
Fixes rendering in Counter-Strike Source and Team Fortress 2 on
Ironlake.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Jordan Justen <jordan.l.justen@intel.com>
We were crashing if one of the buffers wasn't set, we should
just treat it as an overflow. It's useful when using so
statistics because it allows one to figure out how much data
would be generated by so without actually writing any of it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
we weren't adding the soa offsets when constructing the indices
for the gather functions. That meant that we were always returning
the data in the first vertex/primitive/pixel in the SoA structure
and not correctly fetching from all structures.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We already hold the variable, just weren't providing access
to it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We weren't taking the buffer offset, destination offset or the
stride into consideration so we were frequently writing into
an overflown buffer.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This was a very serious bug. We were always doing the viewport
transformations on the first output of the vertex shader. That means
that every application that was storing position in anything but
OUT[0] was outputing untransformed vertices and had broken output
for whatever it was storing at OUT[0]. Correctly take into
consideration where the vertex position is actually stored.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
There can be more stream output decls than shader outputs because
individual components from them can be split and distributed
among different so buffers.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Before, we'd incorrectly generate an error if we we tried to
replace a non-4x4 block near the edge of a NPOT compressed texture.
For example, if the dest image was 15 texels wide and xoffset=12
and width=3 we'd incorrectly generate GL_INVALID_OPERATION.
Verified with new tests added to piglit s3tc-errors test.
Note: This is a candidate for the stable branches.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
patch fixes a crash that happens if glTexSubImage2D is called with a
negative xoffset.
NOTE: This is a candidate for stable branches.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
After more thought/discussion, it seems it is better to handle this sort
of stuff in the state tracker.
So this reverts commit 12096f334b, except the
variant->key -> key shorthands.
This is a simple shader compiler that performs almost zero optimizations. The
generated code is usually much larger comparing to that generated by i965.
The generated code also requires many more registers.
Function-wise, it lacks register spilling and does not support most TGSI
indirections. Other than those, it works alright.
Courtesy of clang:
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1483:10: warning: array index of '2' indexes past the end of an array (that contains 2 elements) [-Warray-bounds]
tmp[2] = lp_build_swizzle_aos(coord_bld, ddx_ddy[1], swizzle02);
^ ~
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1430:10: note: array 'tmp' declared here
LLVMValueRef ddx_ddy[2], tmp[2], rho_vec;
^
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1487:56: warning: array index of '2' indexes past the end of an array (that contains 2 elements) [-Warray-bounds]
rho_vec = lp_build_add(coord_bld, rho_vec, tmp[2]);
^ ~
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1430:10: note: array 'tmp' declared here
LLVMValueRef ddx_ddy[2], tmp[2], rho_vec;
^
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1491:56: warning: array index of '2' indexes past the end of an array (that contains 2 elements) [-Warray-bounds]
rho_vec = lp_build_max(coord_bld, rho_vec, tmp[2]);
^ ~
src/gallium/auxiliary/gallivm/lp_bld_sample.c:1430:10: note: array 'tmp' declared here
LLVMValueRef ddx_ddy[2], tmp[2], rho_vec;
^
Only 13 affected programs in shader-db, but they were all helped.
total instructions in shared programs: 368877 -> 368851 (-0.01%)
instructions in affected programs: 1576 -> 1550 (-1.65%)
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Three-source instructions have a vertical stride overloaded to 4, which
prevents directly using vec4 uniforms as arguments. Instead we need to
insert a MOV instruction to do the replication for the three-source
instruction.
With this in place, we can use three-source instructions in the vertex
shader. While some thought needs to go into deciding whether its better
to use a three-source instruction rather than a sequence of equivalent
instructions (when one or more sources are uniforms or immediates), this
will allow us to skip a lot of ugly lowering code and use the BFE and
BFI2 instructions directly.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
This move the tracing timeout and printing into winsys and add
an debug environement variable for it (R600_DEBUG=trace_cs).
Lot of file touched because of winsys API changes.
v2: Do not write lockup file if ib uniq id does not match last one
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
There was a lot of code in evergreen_compute_internal.c that was not
being used at all and most of it was duplicating code from other parts
of the driver.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
We don't support pre-2.6 kernels anyway - the install docs say 2.6.28
for DRI - and apparently this confuses ld.so's sorting when multiple
libGLs are installed. Just remove it.
Note: this is a candidate for the stable branches.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
New textures or vertex buffers don't always require patching and
re-emitting the shaders. So do a better job of figuring out when we
actually have to patch the shader.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Removes 75/78 state-dependent recompiles in GLB2.7 (the remaining 3 are
due to FBO-rendering size predictions). We currently expose
GL_ARB_color_buffer_float on GL core, so we may mis-predict there, but I'm
about to send a patch for removing that silly extension in that case.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If a bug in an app/stater-tacker causes vertex buffer to fetch vertex
elements that are not bound, simply return zeros instead of crashing.
Reviewed-by: Brian Paul <brianp@vmware.com>
clang is supports most gcc options / extensions, with a some exceptions.
The biggest advantage of using clang is that compilation times are much
short.
One can tell scons to use clang when building by invoking it as
CC=clang CXX=clang++ scons libgl-xlib
From low to high bits, the sample positions are packed y0,x0,y1,x1...
Fixes arb_texture_multisample-sample-position piglit.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We were assigning incorrect const register for immediates, and
potentially writing immediate const to the wrong location. This fixes
an incorrect-rendering bug with xonotic.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Set a few extra registers to make sure we are in proper state for
clearing. And also add some debug options to mark all state dirty in
clear and gmem operations to aid in debugging.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
There is a bit we need to set for 2D vs 3D fetch, to tell the hw whether
there are two or there valid input components.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
The previous approach of using the dst register as an intermediate
temporary doesn't work in a lot of cases. For example, if the dst
register is the same as one of the src registers.
For now, just simplify it and always allocate a new register to use as
an intermediate. In some cases this will result in more registers used
than required. I think the best solution would be to implement an
optimization pass to reduce the number of registers used, which would
also solve the problem we have now of not being able to use GPRs that
are assigned for TGSI_FILE_INPUT.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Opps, didn't notice that I had left it stubbed out.
Also, make things fail a bit more gracefully when things go wrong.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Really this should be set based on buffer format, not on color vs
depth/stencil. Probably there should be more formats that set the bit
as we add support for more render target formats.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Lighter weight then using streamout. Only evergreen
and newer asics support embedded data as src with
CP DMA.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Unlike GEN6, the bits of entry count are distributed like this
width = (entry_count & 0x0000007f); /* bits [6:0] */
height = (entry_count & 0x001fff80) >> 7; /* bits [20:7] */
depth = (entry_count & 0x7fe00000) >> 21; /* bits [30:21] */
The maximum entry count is still limited to 2^27.
This was noted while going over the PRM. No test is impacted, because
1<<20 (the bit that moved) is much larger than GL_UNIFORM_BLOCK_MAX_SIZE,
GL_MAX_TEXTURE_BUFFER_SIZE, or MAX_*_UNIFORM_COMPONENTS.
v2: Explain more in the commit message (by anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
The inverse repeat count should taks up bits 31:15 and is in U1.16. Fixes
the "Restarting lines within a single Begin/End block" subtest of piglit
linestipple, and gets the other failing subtests much closer to passing.
v2: Rewrite commit message with more detailed piglit info (by anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, the only kind of ir_jump that would terminate a basic
block was "return". However, the other possible types of ir_jump
("break", "continue", and "discard") should terminate a basic block
too. This patch modifies basic block analysis so that it terminates a
basic block on any type of ir_jump, not just ir_return.
Fixes piglit test dead-code-break-interaction.shader_test.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Running piglit with this was causing all sort of weird stuff happening
to my desktop (Chromium webpages become blank, Qt Creator flickered,
etc). I tracked this down to shared memory segment leakage when GL is
not shutdown properly. The segments can be seen running `ipcs` and
looking for nattch==0.
This changes fixes this by calling shmctl(IPC_RMID) soon after creation
(which does not remove the segment immediately, but simply marks it for
removal when no more processes are attached).
This matches src/mesa/drivers/x11/xm_buffer.c behaviour.
v2:
- move shmctl(IPC_RMID) after XShmAttach() for *BSD, per Chris Wilson
- remove stray debug printfs, spotted by Ian Romanick
NOTE: This is a candidate for stable branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
We need to handle the leading vertex information when
assembling primitives for the geometry shader otherwise
the resulting triangles will have vertices at incorrect
input locations.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The commit below exposed a bug in dri2_add_config.
commit 3998f8c6b5
Author: Ralf Jung <post@ralfj.de>
Date: Tue Apr 9 14:09:50 2013 +0200
egl/x11: Fix initialisation of swap_interval
This little code snippet near the bottom of dri2_add_config,
if (double_buffer) {
...
conf->base.MinSwapInterval = dri2_dpy->min_swap_interval;
conf->base.MaxSwapInterval = dri2_dpy->max_swap_interval;
}
it never did what it claimed to do. The assignment never changed the value
of conf->base.MaxSwapInterval, because dri2_dpy->max_swap_interval was,
until the above exposing commit, unitialized here. That is,
conf->base.MaxSwapInterval was 0 before and after assignment. Ditto for
the min swap interval.
Above the troublesome code snippet, the call to _eglFilterArray rejects
the config as unmatching if its swap interval bounds differ from the base
config's. Before the exposing commit, at the call to _eglFilterArray, the
swap interval bounds were always [0,0], and hence no config was rejected
due to swap interval.
After the exposing commit, _eglFilterArray incorrectly rejected some
configs, which prevented dri2_egl_config::dri_double_config from getting
set for the rejected config, which resulted in a NULL pointer getting
passed into dri2CreateNewDrawable, and then segfault.
The solution: set the swap interval bounds before _eglFilterArray.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63447
Tested-by: Lu Hua <huax.lu@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The previous commit introduced extra words, breaking the formatting.
This text transformation was done automatically via the following shell
command:
$ git grep 'THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY' | sed 's/:.*$//' | xargs -I {} sh -c 'vim -e -s {} < vimscript2
where 'vimscript2' is a file containing:
/THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY/;/^ *$/ !fmt -w 78 -p '// '
:wq
Reviewed-by: Brian Paul <brianp@vmware.com>
The previous commit introduced extra words, breaking the formatting.
This text transformation was done automatically via the following shell
command:
$ git grep 'THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY' | sed 's/:.*$//' | xargs -I {} sh -c 'vim -e -s {} < vimscript
where 'vimscript' is a file containing:
/THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY/;/\*\// !fmt -w 78 -p ' * '
:wq
Reviewed-by: Brian Paul <brianp@vmware.com>
This brings the license text in line with the MIT License as published
on the Open Source Initiative website:
http://opensource.org/licenses/mit-license.php
Generated automatically be the following shell command:
$ git grep 'THE AUTHORS BE LIABLE' | sed 's/:.*$//g' | xargs -I '{}' \
sed -i 's/THE AUTHORS/THE AUTHORS OR COPYRIGHT HOLDERS/' {}
This introduces some wrapping issues, to be fixed in the next commit.
Reviewed-by: Brian Paul <brianp@vmware.com>
See previous commit for the rationale. These weren't caught by the
automatic conversion due to the "OR IBM" addition.
Reviewed-by: Brian Paul <brianp@vmware.com>
Generated automatically be the following shell command:
$ git grep 'BRIAN PAUL BE LIABLE' | sed 's/:.*$//g' | xargs -I '{}' \
sed -i 's/BRIAN PAUL/THE AUTHORS/' {}
The intention here is to protect all authors, not just Brian Paul. I
believe that was already the sensible interpretation, but spelling it
out is probably better.
More practically, it also prevents people from accidentally copy &
pasting the license into a new file which says Brian is not liable when
he isn't even one of the authors.
Reviewed-by: Brian Paul <brianp@vmware.com>
There used to be a derived state _ClampReadColor, so setting _NEW_COLOR
made sense. The state is gone now.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
We don't want to set the flag for Gallium.
I think only swrast needs the flag to be set for occlusion queries.
v2: fix stats_wm updates in i965
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The functions don't affect driver state. There is no code that would rely
on vertices being flushed prior to changing the states, and no code that
would check for _NEW_STENCIL before using the states.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
both functions don't change the framebuffer in any way
(if mesa_meta is not used)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
No driver checks the flag. Nobody uses it.
I also removed the FLUSH_VERTICES calls, because PixelStorei has no effect
on rendering.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
_NEW_TRANSFORM_FEEDBACK is not used by core Mesa, so it can be removed.
Instead, an new private flag is added to i965 to serve the same purpose.
If you're new to this:
* When creating a context. you can set private dirty flags
in gl_context::DriverFlags, eg.:
ctx->DriverFlags.NewStateX = BRW_NEW_STATE_X;
* When StateX is changed, core Mesa does:
ctx->NewDriverState |= ctx->DriverFlags.NewStateX;
* When you have to draw, read and clear ctx->NewDriverState.
* Pros: not touching NewState, the driver decides the mapping between
GL states and hw state groups, unlimited number of flags in core Mesa
(still limited number of flags in the driver though)
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
because the code looks at the visual if there is a depth or stencil buffer
before enabling depth or stencil, respectively.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
Squashed commit of the following:
commit 04c5fa2cbb8e89d6f2fa5a75af1cca03b1f6b852
Author: José Fonseca <jfonseca@vmware.com>
Date: Tue Apr 23 17:37:18 2013 +0100
gallium: s/lower_left_origin/bottom_edge_rule/
commit 4dff4f64fa83b9737def136fffd161d55e4f1722
Author: José Fonseca <jfonseca@vmware.com>
Date: Tue Apr 23 17:35:04 2013 +0100
gallium: Move diagram to docs.
commit 442a63012c8c3c3797f45e03f2ca20ad5f399832
Author: James Benton <jbenton@vmware.com>
Date: Fri May 11 17:50:55 2012 +0100
gallium: Replace gl_rasterization_rules with lower_left_origin and half_pixel_center.
This change is necessary to achieve correct results when using OpenGL
FBOs.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
This fixes a crash when a resource cannot be mapped to the CPU's address space
because it's too big.
This puts a global pipe_context in r600_screen, which is guarded by a mutex,
so that we can use pipe_context when there isn't one around.
Hopefully our multi-context support is solid.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
NOTE: This is a candidate for the 9.1 branch.
Although this might be useful for ARB_clear_buffer_object,
I need it for initializating resources in r600g.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: comment cleanups
NOTE: This is a candidate for the 9.1 branch.
Number of vertices to fetch doesn't always equal the number of input
vertices. To correctly compute the number if IA primitives we need
to use the total number of input vertices, not only those that
need to be fetched.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
TGSI geometry shader input declerations are of the IN[][2] format
and the dimensions of the array have to be deduced from the input
primitive property.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We want to be able to reset certain parts of the pipeline,
in particular the input primitive index, but only either with
seperate invocations of the draw_vbo or new instances. In all
other cases (e.g. new invocations due to primitive restart)
that data needs to be preserved. Add a function through which
we can reset instance dependent data.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Same approach as in the llvmpipe, if the geometry shader is
null and we have stream output then attach it to the vertex
shader right before executing the draw pipeline.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The code doesn't set brw->query.obj to NULL, it sets query->bo to NULL.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
TEMP is not the only register file that accept unsigned. OUT too.
Actually, what determines the appropriate type of the destination value is
not the opcode, but rather the register.
Also cleanup/simplify code. Add a few more asserts, but also make
code more robust by handling graceful if assert fails.
This fixes segfault / assertion in the included vert-uadd.sh graw shader.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This should be reusable for other non-gallium drivers, so we can make the
extension always be available.
v2: Add a more detailed comment than the old function had (recommended
by Brian).
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
I noticed a fallback in regnum through sysprof, and wanted a nicer way to
get information about it.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2.7 was a particularly trouble ridden release.
Furthermore, the bug no longer can be reproduced ever since the
first_level state was taken in account.
Reviewed-by: Brian Paul <brianp@vmware.com>
They are supported on LLVM 3.1, at least on x86. (I haven't tested on PPC
though.)
Actually lp_build_linear_mip_levels() already has been emitting them for
some time.
This avoids intrinsics, which tend to be an obstacle for certain
optimization passes.
Reviewed-by: Brian Paul <brianp@vmware.com>
There will be a new IR for a3xx, which has a very different shader ISA
(more scalar oriented). So rename to avoid conflicts later when I start
adding a3xx support to the gallium driver.
Signed-off-by: Rob Clark <Rob Clark robdclark@freedesktop.org>
The standalone shader assembler needed some meta-data to know about
attributes/varyings/etc, to do the shader linkage. We don't need these
parts with gallium/tgsi, so just get rid of it.
Signed-off-by: Rob Clark <Rob Clark robdclark@freedesktop.org>
Should be able to handle all things which make this tricky to implement.
Fallthroughs, including most notably into/out of default, should be handled
correctly but are quite a mess.
If we see largely unoptimized switches in the wild should probably think
about some "real" switch optimization pass, e.g. things like this:
switch
case1
someinst
brk
case2
default
case3
someinst
brk
case4
someinst
endswitch
are legal, but the pointless case2/case3 statements not only cause condition
evaluation but will turn this into a "fake" fallthrough case (because
mask and defaultmask are already updated for case2 when default is
encountered) requiring executing code twice.
If default is at the end though, there's never any code re-execution, and
if that's not the case if there's no fallthrough in (not even a fake one)
and out of default there's no code re-execution neither.
v2: add comments, and use enum for break type instead of magic boolean.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
It seems there was a typo in gallivm breakc handling (I am actually still
not sure it is really needed but otherwise that statement really should go
away). Also fix the wrong src argument type, even though they weren't really
used.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
While initially that opcode probably was meant for something along the
lines of sm3 break_comp it has never worked that way (not even the
argument count was right) and now the opcode has quite different
semantics so just remove it. (Discovered by Jose Fonseca)
This is still not really correct, since at least for sm 4.0
the nesting limit is 64 per subroutine, and subroutine nesting itself
has a limit of 32, so since we have a flat stack we'd need 32*64.
But this should probably be better fixed with per-subroutine stacks,
since otherwise these structures get really big (like 100kB for the
lp_exec_mask).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Input assembler needs to be able to decompose adjacency primitives
into something that can be understood by the rest of the pipeline.
The specs say that the adjacency primitives are *only* visible
in the geometry shader, for everything else they need to be
decomposed. Which in most of the cases is not an issue, because
the geometry shader always decomposes them for us, but without
geometry shader we were passing unchanged adjacency primitives
to the rest of the pipeline and causing crashes everywhere. This
commit introduces a primitive assembler which, if geometry
shader is missing and the input primitive is one of the
adjacency primitives, decomposes them into something
that the rest of the pipeline can understand.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
pre_clip_pos is a float[4] we just used (*float)[4] to be able to
jump within the array of vertex_headers with it. So if the idx
happened to be anything but 0, we'd actually read from some garbage
in memory. Change it to just be a simple pointer instead of casting
it to something that it's not. As suggested by Jose.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is the kind of information that would have been present for GLX, if
GLX supported modern GL. This allows these entrypoints to get automatic
asynchronous marshalling code generated for glthread.
This bug is currently benign, since get_called_parameter_string() is
currently only used for functions that return true for
glx_function.has_different_protocol(), and none of those functions
include padding. However, in order to implement marshalling of GL API
functions, we'll need to use get_called_parameter_string() far more
often.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Without this patch, $$.negate, $$.rgba_valid, and $$.xyzw_valid take
on garbage values. At the moment this problem is benign (the garbage
values happen to be zero), but in my experiments executing GL
operations on a background thread, the garbage values change, leading
to piglit failures.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since stdbool.h's "true" and "false" are #defines, they got expanded when
used as macro arguments, and that expanded value was stored in the
XML string, producing XML that driconf would then fail to parse.
Currently no drivers included stdbool along with driconf, but I keep
accidentally doing so on intel as we move towards using normal C.
v2: rebase on master.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
It's next to useless, since it just allows you to turn off VDPAU and
XvMC with a single switch. Just check whether Gallium drivers are
enabled instead.
Reviewed-by: Christian König <christian.koenig@amd.com>
Most test pass, issue are with border color and swizzle.
Based on ircnick<maelcum> patch.
v2: Restaged commit hunk
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
v2: Remove left over code
v3: Restage properly the commit so hunk of first one are not in
second one.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Not all are supported as render targets.
The state tracker fallback of using RGBA instead of RGBX currently
fails for blending, we could work around this by clearing their alpha
to 1 and modifying the color mask to disable writing alpha.
This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.
The dependency of update_sampler on the texture updates was
introduced to avoid doing the apply_depthmode to the swizzle twice.
v2: Moved swizzling helper to u_format.c, extended the CAP to
provide more accurate information.
Per message on mesa-users list, this wasn't working before.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Turns out the previous "fix" for handling per-pixel face selection and
derivatives didn't work out that well - the derivatives were wrong by
quite a bit, in theory transformation of the derivatives into cube space
should work, but would be _a lot_ more work than the "simplified" transform
used.
So, for explicit derivatives, I'm just giving up and go back to not honoring
them.
For implicit derivatives (and the fake explicit ones) however we try
something a little different, we just calculate rho as we would for a 3d
texture, that is after scaling the coords by the inverse major axis.
This gives the same results as calculating the derivs after projection of
the coords to the same face as long as all pixels hit the same face (and
only without rho_no_opt, otherwise it should be a bit worse). And when
not all pixels are hitting the same face, the results aren't so hot but
not catastrophically bad (I believe not off by more than a factor of 2 without
no_rho_approx and not more than sqrt(2) with no_rho_approx). I think this is
better than just picking the wrong face but who knows...
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This will calculate rho correctly as
sqrt(max((ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2), (ds/dx)^2 + (dt/dx)^2 + (dr/dx)^2))
instead of max(|ds/dx|,|dt/dx|,|dr/dx|,|ds/dy|,|dt/dy,|dr/dy|)
(for 3 coords - 2 coords work analogous, for 1 coord there's no point doing
the exact version), for both implicit and explicit derivatives.
While such approximation seems to be allowed in OpenGL some APIs may be less
forgiving, and the error can be quite large (sqrt(2) for 2 coords, sqrt(3) for
3 coords so wrong by nearly one mip level in the latter case).
This also helps to single out "real" bugs from "expected" ones, so it is debug
only (though at least combined with no_brilinear I didn't really see much of a
performance difference but only tested with a debug build - at least with
implicit mipmaps the instruction count is almost exactly the same though the
instructions are more complex (1 sqrt and mul/adds instead of and/max mostly).
The code when the option isn't set stays exactly the same.
v2: rename no_rho_opt to no_rho_approx.
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently the vdpau and xvmc detection code, is enabled for all builds. The
state trackers exist only within gallium. Enable whenever at least one gallium
driver is selected
v2: removed stray '-a'
[mattst88 v3]: Removed stray $.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63645
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
We were trying to use a destroy method from a deleted context.
This fix is based on what's in the svga driver.
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Fixes issue identified by Klocwork analysis:
'attribute_map' array elements might be used uninitialized in this
function (vec4_visitor::lower_attributes_to_hw_regs).
The attribute_map array contains the mapping from shader input
attributes to the hardware registers they are stored in.
vec4_vs_visitor::setup_attributes() only populates elements of this
array which, according to core Mesa, are actually used by the shader.
Therefore, when vec4_visitor::lower_attributes_to_hw_regs() accesses
the array to lower a register access in the shader, it should in
principle only access elements of attribute_map that contain valid
data. However, if a bug ever caused the driver back-end to access an
input that was not flagged as used by core Mesa, then
lower_attributes_to_hw_regs() would access uninitialized memory, which
could cause illegal instructions to get generated, resulting in a
possible GPU hang.
This patch makes the situation more robust by using memset() to
pre-initialize the attribute_map array to zero, so that if such a bug
ever occurred, lower_attributes_to_hw_regs() would generate a (mostly)
harmless access to r0. In addition, it adds assertions to
lower_attributes_to_hw_regs() so that if we do have such a bug, we're
likely to discover it quickly.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For some reason I made this happen under indirect rendering,
I think we might have a leak, valgrind gave out, so I said I'd
fix the basic problem.
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
No longer pass -a flag to the get_hash_generate.py script to specify
OpenGL, ES1, ES2, etc. This updates the autoconf, scons and android
build files too (so we can bisect).
This is the last of the API-dependent conditional compilation in
core Mesa.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
we were ignoring leading/provoking vertex settings which was
breaking decomposition of some strips.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
we were using the wrong vars, reporting incorrect stream output
statistics.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We were always treating the vertex index as a scalar but when the
shader is using indirect addressing it will be a vector of indices
for each channel. This was causing some nasty crashes insides
LLVM.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
If a window's minimized we get a zero-size window. Skip the SwapBuffers
in that case to avoid some warning messages with the VMware svga driver.
Internal bug #996695
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The caller of NewTextureObject does the right thing if NULL is returned,
so this function should do the right thing too.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The specification says that the geometry shader should exit if the
number of emitted vertices is bigger or equal to max_output_vertices and
we can't do that because we're running in the SoA mode, which means that
our storing routines will keep getting called on channels that have
overflown (even though they will be masked out, but we just can't skip
them).
So we need some scratch area where we can keep writing the overflown
vertices without overwriting anything important or crashing.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Can happen if we were using stream output without geometry
shader, by returning early we avoid a crash.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is a basic implementation of the pipeline statistics in the
draw module. The interface is similar to the stream output statistics
and also requires that the callers explicitly enable it.
Included is the implementation of the interface in llvmpipe and
softpipe. Only softpipe enables the pipeline statistics capability
though because llvmpipe is lacking gathering of the fragment shading
and rasterization statistics.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The issue with SOA execution and end_primitive opcode is that it
can be executed both when we haven't emitted any vertices, in
which case we don't want to emit an empty primitive, and when
the execution mask is zero and the execution should be skipped. We
handled only the latter of those conditions. Now we're combining the
execution mask with a mask created from emitted vertices to handle
both cases. As a result we don't need the pending_end_primitive
flag which was broken because it was static and could be affected
by both above mentioned conditions at run-time.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Same as with llvmpipe: we can't be divind/moding by zero and we
need to make sure that dividing/moding by zero produces 0xffffffff.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Add a note to update PACKAGE_VERSION for Android and scons builds
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Handle legacy/obsolete specs as well
List all specs in extensions.html
Mark 'OLD' extensions as obsolete in extensions.html
Update the spec location in old relnotes
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
relnotes-*html > relnotes/*html
RELNOTES-* > relnotes/*
fix links, css and frames
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
TGSI_OPCODE_IF condition had two possible interpretations:
- src.x != 0.0f
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
vertex and fragment shaders
- gallivm/llvmpipe
- postprocess
- vl state tracker
- vega state tracker
- most old drivers
- old internal state trackers
- many graw examples
- src.x != 0U
- Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was true for both
vertex and fragment shaders
- tgsi_exec/softpipe
- r600
- radeonsi
- nv50
And drivers that use draw module also were a mess (because Mesa would
emit float IFs, but draw module supports native integers so it would
interpret IF arg as integers...)
This sort of works if the source argument is limited to float +0.0f or
+1.0f, integer 0, but would fail if source is float -0.0f, or integer in
the float NaN range. It could also fail if source is integer 1, and
hardware flushes denormalized numbers to zero.
But with this change there are now two opcodes, IF and UIF, with clear
meaning.
Drivers that do not support native integers do not need to worry about
UIF. However, for backwards compatibility with old state trackers and
examples, it is advisable that native integer capable drivers also
support the float IF opcode.
I tried to implement this for r600 and radeonsi based on the surrounding
code. I couldn't do this for nouveau, so I just shunted IF/UIF
together, which matches the current behavior.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
v2:
- Incorporate Roland's feedback.
- Fix r600_shader.c merge conflict.
- Fix typo in radeon, spotted by Michel Dänzer.
- Incorporte Christoph Bumiller's patch to handle TGSI_OPCODE_IF(float)
properly in nv50/ir.
This patch adds PCI IDs for Bay Trail (sometimes called Valley View).
As far as the 3D driver is concerned, it's very similar to Ivybridge,
so the existing code should work just fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Assume the maximum pixel size (16 bytes per pixel). In addition to
moving redundant malloc and free calls outside the loop, this fixes a
potential resource leak when a surface is mapped and the malloc fails.
This also makes blit_nearest look a bit more like blit_linear.
v2: Use MAX_PIXEL_BYTES instead of 16. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This was originally discovered by Klocwork analysis:
Possible memory leak. Dynamic memory stored in 'srcBuffer0'
allocated through function 'malloc' at line 566 can be lost at line
746
However, I think the problem is actually much worse. Since the memory
is freed after the first pass through the loop, the released buffer may
be used on the next iteration!
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There is a hardware bug on Cayman where a BREAK/CONTINUE followed by
LOOP_STARTxxx for nested loops may put the branch stack into a state
such that ALU_PUSH_BEFORE doesn't work as expected. Workaround this
by replacing the ALU_PUSH_BEFORE with a PUSH + ALU
Fixes piglit tests EXT_transform_feedback/order*
v2: Use existing loop count and improve comment
v3: [Vadim Girlin] Set jump address for PUSH instructions
NOTE: This is a candidate for the 9.1 branch
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Instead of emitting configuration values (e.g. number of gprs used) in a
predefined order, the LLVM backend now emits these values in
register/value pairs. The first dword contains the register address and
the second dword contians the value to write.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Inserting the value for the second quad in the wrong place for the
following shuffle. This meant the row or image stride was undefined which is
quite catastrophic, can lead to bogus texels fetched or just segfault.
This code is only hit for SoA path currently, still surprising it
didn't crash more or caused more visible issues (I think llvm used a
broadcast shuffle for the undefined parts of the vector, hence the undefined
value for the second quad was just the same as that from the first quad,
so as long as both quads hit the same mip level everything was fine, and since
lower mips always have the same large stride it made it less likely to
hit out-of-bound memory in case of differing lods).
Note: this is a candidate for stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Null platform IDs are OK according to the spec, but some applications have
been reported to get paranoid and assume that our NULL platform is unusable.
As it doesn't hurt to have device enumeration separate from the rest of the
device code (quite the opposite, it makes the code cleaner), make the API use
an actual platform object that keeps track of the available devices instead of
the former NULL pointer.
Reported-and-reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
I don't see a sensible value to use in this path, but we shouldn't ever
hit this outside of developer new-texture-target enabling.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We don't want to store this thing in the class, and we do need the
definition to be at the top of the function and held onto until the end
here, so there's not much to do besides (void) reference it.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This was copy and pasted from can_reswizzle_dst(), and we can just fold it
in instead to avoid the warning.
Reviewed-by: Matt Turner <mattst88@gmail.com>
I think this actually clarifies what's going on in the asserts a bit,
given how many regions we've got floating around.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We assert that failure doesn't happen, but it fixes a warning in the
release build and it would at least give working behavior for a user by
falling back to the normal texsubimage path.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This was silly -- checking that we didn't overflow the array by dividing
the array size by 2 and then multiplying it back up by 2.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Asserts don't stop execution in release builds, so we would continue on to
use an uninitialized format value. Just take the failure path, which
appears to continue up the call stack for a while.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The call has no side effects, and moving it into the assert cleans up a
compile warning in the release build.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We have this support for firsthalf/sechalf instructions, which would be
called in the !has_compr4 (aka original gen4) 16-wide case. We currently
only support 16-wide for gen5+, so we weren't tripping over this, but it
would have been a problem if we ever try to enable it.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This is a poor substitute for proper global dead code elimination that
could replace both our current paths, but it was very easy to write. It
particularly helps with Valve's shaders that are translated out of DX
assembly, which has been register allocated and thus have a bunch of
unrelated uses of the same variable (some of which get copy-propagated
from and then left for dead).
shader-db results:
total instructions in shared programs: 1735753 -> 1731698 (-0.23%)
instructions in affected programs: 492620 -> 488565 (-0.82%)
v2: Fix comment typo
Reviewed-by: Matt Turner <mattst88@gmail.com>
This instruction doesn't update its IR destination, it just moves from
payload to f0. This caused the dead code elimination pass I'm adding to
dead-code-eliminate the first step of interpolation.
Reviewed-by: Matt Turner <mattst88@gmail.com>
These checks were all over, and every time I wrote one I had to try to
decide again what the cases were for partial updates.
v2: Fix inadvertent reladdr check removal.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The other dispatch tables (Exec and Save) are freed, but BeginEnd is
never freed. This was found by inspection why investigating the leak of
shared state in _mesa_initialize_context.
NOTE: This is a candidate for stable branches
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Back up at line 1017 (not shown in patch), we add a reference to the
shared state. Several places after that may divert to the error
handler, but, as far as I can tell, nothing ever unreferences the shared
state.
Fixes issue identified by Klocwork analysis:
Resource acquired to 'shared->TexMutex' at line 1012 may be lost
here. Also there is one similar error on line 1087.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
dri2_create_surface can fail for a variety of reasons, including bad
input data. Dereferencing the NULL pointer and crashing is not okay.
Fixes issue identified by Klocwork analysis:
Pointer 'surf' returned from call to function 'dri2_create_surface'
at line 285 may be NULL and will be dereferenced at line 291.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Duh.
Fixes issues identified by Klocwork analysis:
Pointer 'table' returned from call to function 'calloc' at line 115
may be NULL and will be dereferenced at line 117.
and
Suspicious dereference of pointer 'table' before NULL check at line
119.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Ensure that process_array_type never returns NULL, and let
process_array_type handle the case where the supplied base type is NULL.
Fixes issues identified by Klocwork analysis:
Pointer 'type' returned from call to function 'get_type' at line
1907 may be NULL and may be dereferenced at line 1912.
and
Pointer 'field_type' checked for NULL at line 4160 will be
dereferenced at line 4165. Also there is one similar error on line
4174.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes issue identified by Klocwork analysis:
Pointer 'field_type' returned from call to function 'glsl_type' at
line 4126 may be NULL and may be dereferenced at line 4139. Also
there are 2 similar errors on line(s) 4165, 4174.
In practice, it should be impossible to actually get NULL in here
because a syntax error would have already caused compilation to halt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Pointed out by gcc
nve4_compute.c: In function 'nve4_launch_grid':
nve4_compute.c:511:7: warning: 'ret' may be used uninitialized in
this function [-Wmaybe-uninitialized]
if (ret)
^
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Edit by Christoph Bumiller:
Set it to -1 to indicate failure and only when it's actually required.
As otherwise it is unused - pointed out by gcc
nve4_compute.c:586:20: warning: 'nve4_cache_split_name' defined but not used [-Wunused-function]
static const char *nve4_cache_split_name(unsigned value)
^
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
For debug build we'll hit the assert, for release we are going to emit random data
as subOp is used uninitilised. Spotted by gcc
codegen/nv50_ir_emit_nv50.cpp: In member function 'void nv50_ir::CodeEmitterNV50::emitATOM(const nv50_ir::Instruction*)':
codegen/nv50_ir_emit_nv50.cpp:1554:12: warning: 'subOp' may be used uninitialized in this function [-Wmaybe-uninitialized]
uint8_t subOp;
^
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
v2: I rewrote this to use the sample positions properly.
v3: rewrite properly to use bitfield to cast back to signed ints
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
v2: idr pointed out a bug in how we picked the max sample counts,
use new internal format chooser interface to pick proper answers.
v3: use st_choose_format directly, it was okay, fix anding of masks.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
I've no idea when sample_chan would ever be 4 here, but 4 is most
definitely wrong, array textures have it as 3 as well.
Also the cayman code though unused is obviously wrong.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since the vec4_visitor and vec4_generator classes are going to be
re-used for geometry shaders, we can't enable their debug
functionality based on (INTEL_DEBUG & DEBUG_VS) anymore. Instead, add
a debug_flag boolean to these two classes, so that when they're
instantiated the caller can specify whether debug dumps are needed.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Geometry shader inputs are arrays, but they use an unusual array
layout: instead of all array elements for a given geometry shader
input being stored consecutively, all geometry shader inputs are
interleaved into one giant array. As a result, the array stride we
use to access geometry shader inputs must be equal to the size of the
input VUE, rather than the size of the array element.
This patch introduces a new virtual function,
vec4_visitor::compute_array_stride(), which will allow geometry shader
compilation to specialize the computation of array stride to account
for the unusual layout of geometry shader input arrays. It also
renames the local variable that the ir_dereference_array visitor uses
to store the stride, to avoid confusion.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch introduces a new function,
vec4_visitor::lower_attributes_to_hw_regs(), which replaces registers
of type ATTR in the instruction stream with the hardware registers
that store those attributes. This logic will need to be common
between the vertex and geometry shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch introduces a new function, vec4_visitor::emit_vertex(),
which contains the code for emitting vertices that will need to be
common between the vertex and geometry shaders.
Geometry shaders will need to use a different message header, and a
different opcode, for their URB writes, so we introduce virtual
functions emit_urb_write_header() and emit_urb_write_opcode() to take
care of the GS-specific behaviours.
Also, since vertex emission happens at the end of the VS, but in the
middle of the GS, we need to be sure to only call
emit_shader_time_end() during VS vertex emission. We accomplish this
by moving the call to emit_shader_time_end() into the VS
implementation of emit_urb_write_opcode().
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since this function is going to get used for geometry shaders too, it
deserves a more generic name: generate_vec4_instruction.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch removes the following field from vec4_generator, since it
is not used:
- struct brw_vs_compile *c
And changes the following field:
- struct gl_vertex_program *vp => struct gl_program *prog
With these changes, vec4_generator no longer refers to any VS-specific
data structures. This will pave the way for re-using it for geometry
shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v2: Use the name "prog" rather than "p".
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The next patch is going to change the type of vec4_generator::vp from
struct gl_vertex_program * to struct gl_program *, and rename it. The
sensible name to change it to is vec4_generator::prog. However, prog
is already used. Since the existing vec4_generator::prog is of type
struct gl_shader_program, it makes sense to rename it to shader_prog.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch moves the following data structures from vec4_visitor to
vec4_vs_visitor, since they contain VS-specific data:
- struct brw_vs_compile *c (renamed to vs_compile)
- struct brw_vs_prog_data *prog_data (renamed to vs_prog_data)
- src_reg *vp_temp_regs
- src_reg vp_addr_reg
Since brw_vs_compile and brw_vs_prog_data also contain vec4-generic
data, the following pointers are added to the base class, to allow it
to access the vec4-generic portions of these data structures:
- struct brw_vec4_compile *c
- struct brw_vec4_prog_key *key
- struct brw_vec4_prog_data *prog_data
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
v2: Use shorter names in the base class and longer names in the
derived class.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch moves functions from vec4_visitor to vec4_vs_visitor that
deal with ARB (assembly) vertex programs. There's no point in having
these functions in the base class since we don't intend to support
assembly programs for the GS stage. The following functions are
moved:
- setup_vp_regs
- get_vp_dst_reg
- get_vp_src_reg
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The system values handled by vec4_visitor::visit(ir_variable *) are
VS-specific (vertex ID and instance ID). This patch moves the
handling of those values into a new virtual function,
make_reg_for_system_value(), so that this VS-specific code won't be
inherited by geomtry shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch makes the following vec4_visitor functions virtual, since
they will need to be implemented differently for vertex and geometry
shaders. Some of the functions are renamed to reflect their generic
purpose, rather than their VS-specific behaviour:
- setup_attributes
- emit_attribute_fixups (renamed to emit_prolog)
- emit_vertex_program_code (renamed to emit_program_code)
- emit_urb_writes (renamed to emit_thread_end)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch just creates the derived class; later patches will migrate
VS-specific functions and data structures from the base class into the
derived class.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow the generic parts to be re-used for geometry shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v2: Put urb_read_length and urb_entry_size in the generic struct.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In patches that follow, we'll be splitting structs brw_vs_prog_data
and brw_vs_compile into a vec4-generic base struct and a VS-specific
derived struct (this will allow the vec4-generic code to be re-used
for geometry shaders). Having brw_vs_compile point to
brw_vs_prog_data makes it difficult to do this cleanly.
Fortunately most of the functions that use brw_vs_compile (those in
the vec4_visitor class) already have access to brw_vs_prog_data
through a separate pointer (vec4_visitor::prog_data). So all we have
to do is use that pointer consistently, and plumb prog_data through
the few remaining functions that need access to it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch modifies the arguments to brw_compute_vue_map() so that
they no longer bake in the assumption that we are generating a VUE map
for vertex shader outputs. It also makes the function non-static so
that we can re-use it for geometry shader outputs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The vec4_visitor functions don't use any VS specific data from
vec4_visitor::vp. So rename it to "prog" and change its type from
struct gl_vertex_program * to struct gl_program *. This will allow
the code to be re-used for geometry shaders.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
v2: Use the name "prog" rather than "p".
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The next patch is going to change the type of vec4_visitor::vp from
struct gl_vertex_program * to struct gl_program *, and rename it. The
sensible name to change it to is vec4_visitor::prog. However, prog is
already used in backend_visitor (which vec4_visitor derives from).
Since backend_visitor::prog is of type struct gl_shader_program *, it
makes sense to rename it to shader_prog.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were. (Anonymous structs are assigned names like
"#anon_struct_0001"--see the ast_struct_specifier constructor in
glsl_parser_extras.cpp.)
Fix the comment and add assertions to validate that it really is never
NULL.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Just everything you need for UVD with r600g and radeonsi.
v2: move UVD code to radeon subdir, clean up build system additions,
remove an unused SI function, disable tiling on SI for now.
v3: some minor indentation fix and rebased
v4: dpb size calculation fixed
v5: implement proper fall-back in case the kernel doesn't support UVD,
based on patches from Andreas Boll but cleaned up a bit more.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The EGLConfig attributes EGL_MIN/MAX_SWAP_INTERVAL were incorrectly set to
0 and 0. This prevented clients from setting the swap interval to a
reasonable value, like 1 or 2.
Swap interval worked correctly in Mesa 9.0. The commit below introduced
the bug.
commit 7e9bd2b2ed
Author: Eric Anholt <eric@anholt.net>
Date: Tue Sep 25 14:05:30 2012 -0700
egl: Add support for driconf control of swapinterval.
Note: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63078
[chadv: Wrote commit message]
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If a region is larger than the estimated aperture size, we map/unmap it
by copying with the BLT engine. Which means we can't use Y-tiling.
Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
recent change to use Y-tiling by default on Gen6+. This was due to a
botched merge conflict resolution.
v2: Return a mask of valid tilings from intel_miptree_select_tiling.
This allows us to avoid the X-tiling fallback if Y-tiling is actually
mandatory.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
gen7_blorp_emit_depth_stencil_config() is only called when
params->depth.mt is non-null. Therefore, it's not necessary to do an
"if (params->depth.mt)" test inside it. The presence of this if test
was misleading static analysis tools (and briefly, me) into thinking
that gen7_blorp_emit_depth_stencil_config() might sometimes access
uninitialized data and dereference a null pointer.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
both mov and ucmp can be used to move variables of any type.
correctly note that about ucmp in the tgsi_info and make
sure gallivm can handle that by correctly casting the untyped
moves.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We were using simple temporaries, without using alloca or phi
nodes which meant that on every iteration of the loop our
temporaries, which were holding the number of vertices and
primitives which were emitted, were being reset to zero. Now
we're using alloca to allocate those variables to preserve
them across conditionals.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We were missing the implementation of PIPE_QUERY_SO_STATISTICS
query, this change implements it on top of the existing
facilities.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We want to both make sure we never divide by zero to not generate
sigfpe and that divide by zero is guaranteed to return 0xffffffff.
Based on José idea.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
we break when the mask values are 0 not, 1, plus it's bit comparison
not a floating point comparison. This fixes both.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Enable hiz by setting intel_context::has_hiz. However, to work around
a hardware bug, we selectively enable hiz for only nicely aligned miptree
slices.
No Piglit regressions on Haswell 0x0d26 rev07 when based atop
mesa-master-4ad3601.
Improves the performance of GLB27_TRex_C24Z16_FixedTimeStep by 18.52%
(hsw-0x0d26-rev07; kernel-3.9.0-rc1; GLBenchmark 2.7.0 Release a68901;
samples=3).
v2: Replace the check for IS_HASWELL(devid) in intel_miptree_slice_has_hiz()
with a conditional set of has_hiz. [for anholt]
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
When appropriate, replace each check `hiz_mt != NULL` with either a call
to intel_miptree_slice_has_hiz() or intel_renderbuffer_has_hiz(). No
behavioral change.
This prepares for selectively enabling hiz on individual miptree slices
for Haswell.
This refactoring had several side effects.
1. To prevent new warnings about discarding the const qualifier,
I removed 'const' from some variable declarations in
intel_validate_framebuffer(). The alternative was to add const
qualifiers to multiple function signatures in the
intel_renderbuffer_has_hiz call graph. Since the dominant convention
in the Intel code is to not qualify function parameters as const,
I chose to remove rather than add const qualifiers.
2. I changed the signature of brw_emit_depth_stencil_hiz() by replacing
`struct intel_mipmap_tree *hiz_mt` with `bool hiz`. The function used
hiz_mt mostly as a boolean indicator of the presence of hiz, so the
signature change is consistent with the patch's goal.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Add new parameters `depth_level` and `depth_layer`, which specify depth
miptree's slice of interest. A following patch will pass the new
parameters through to intel_miptree_slice_has_hiz().
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The new fields define the 2D miptree slice to be used. A following patch
will pass the new fields through to intel_miptree_slice_has_hiz().
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
On Haswell, HiZ will selectively be enabled on individual miptree slices
to workaround a hardware bug. The new field 'has_hiz' indicates if HiZ is
enabled for a given slice.
Also add two new accessor functions for this field.
intel_miptree_slice_has_hiz
intel_renderbuffer_has_hiz
The new field and accessor functions are not yet used. Also, this patch
introduces no behavioral change because, in this patch,
intel_miptree_alloc_hiz() sets has_hiz for all slices.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The hardware docs and the simulator require that the rectangle primitive
emitted during fast depth clears and hiz resolves must be aligned to 8x4
pixels.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
This allows the computation of the offset to get written directly into the
message source.
shader-db results:
total instructions in shared programs: 3308390 -> 3283025 (-0.77%)
instructions in affected programs: 442998 -> 417633 (-5.73%)
No difference in GLB2.7 low res (n=9).
Reviewed-by: Matt Turner <mattst88@gmail.com>
We have several places in our pull constant handling where we make a
temporary src_reg for an int, and then turn it into a dst. In doing so,
we were writing to the dst.xyzw, so we never register coalesced it with a
later mov from dst.x to real_dst.x.
These extra channels written would be removed if we had channel-wise DCE
in the backend, but we don't. Fix it for now by just not writing these
extra channels that won't get used.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The software-tracked transform feedback offsets (svbi_0_starting_index)
are incorrect in the presence of primitive restart, so we were actually
updating it with a bogus value if the batch wrapped and we emitted the
packet again during a single transform feedback. By reducing state
emission, we avoid the bug.
Fixes piglit OpenGL 3.1/primitive-restart-xfb flush
Reviewed-by: Paul Berry <stereotype441@gmail.com>
NOTE: This is a candidate for the 9.1 branch.
The software-tracked transform feedback offsets (svbi_0_starting_index)
are incorrect in the presence of primitive restart, so we can't reliably
compute offsets for our buffer pointers after a batch flush. Thanks to HW
contexts, our transform feedback offsets are now saved, so we can just
keep using the ones from before the batch wrap.
Fixes piglit OpenGL 3.1/primitive-restart-xfb flush
Reviewed-by: Paul Berry <stereotype441@gmail.com>
NOTE: This is a candidate for the 9.1 branch.
"ctx->DrawBuffer->Visual" might be invalid if (NewState &_NEW_BUFFERS) != 0.
v2: also fix:
- RGBA_INTEGER_MODE_EXT
- RGBA_FLOAT_MODE_ARB (also check API support)
- FRAMEBUFFER_SRGB_CAPABLE_EXT
NOTE: This is a candidate for stable branches.
Reviewed-by: Eric Anholt <eric@anholt.net>
Gen7.5 (Haswell) hardware supports primitive restart for all primitive
types. It also handles all possible primitive restart indices.
Rather than specialize both can_cut_index_handle_restart_index() and
the switch statement in can_cut_index_handle_prims() for Haswell, just
return early if the hardware is Haswell because we know it can handle
everything.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
brw_draw.c contains a trim() function which modifies the vertex count
for quads and quad strips in order to discard dangling vertices. In
principle this shouldn't be necessary, since hardware since Gen4 is
capable of discarding dangling vertices by itself. However, it's
necessary because as a hack to speed up rendering on Gen 4-5, we
sometimes convert quads to trifans and quad strips to tristrips. The
trim() function isn't necessary on Gen6 and up.
This patch documents why and when the trim() function is necessary,
and avoids calling it when it's not needed.
This will avoid creating problems when we enable hardware support for
primitive restart of quads and quad strips on Haswell.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The call to emit_shader_time_end() before the second URB write was
conditioned with "if (eot)", but eot is always false in this code
path, so emit_shader_time_end() was never being called for vertex
shaders that performed 2 URB writes.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Drawing subtitles didn't increased the dirty area of the surface.
Reported and tested by freeedrich on irc.
v2: don't clear the surface
Signed-off-by: Christian König <christian.koenig@amd.com>
In the mailing list discussion of "glsl/linker: fix varying packing
for non-flat integer varyings." (commit 7862bde), we concluded that
since the bug only applies to integral variables, it is safer to just
apply the bug fix to integer varyings. I forgot to make the change
before pushing the patch upstream. (Note: we aren't aware of any bugs
in commit 7862bde; it just seems wise to be on the safe side).
This patch makes the change. Assuming commit 7862bde gets
cherry-picked back to 9.1, this commit should be cherry-picked too.
NOTE: This is a candidate for the 9.1 release branch.
When a varying is consumed by transform feedback, but is not used by
the fragment shader, assign_varying_locations() sets its interpolation
type to "flat" in order to ensure that lower_packed_varyings never has
to deal with non-flat integral varyings (the GLSL spec doesn't require
integral vertex outputs to be flat if they aren't consumed by the
fragment shader).
A similar situation will arise when geometry shader support is added,
since the GLSL spec only requires integral vertex shader outputs to be
flat when they are consumed by the fragment shader. This patch
modifies the linker to handle this situation too.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
To minimize the variety of type conversions that lower_packed_varyings
needs to perform, it assumes that integral varyings are always
qualified as "flat". link_varyings.cpp takes care of ensuring that
this is the case (even in the circumstances where GLSL doesn't require
it).
This patch documents the assumption with an assertion, for ease in
future debugging.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Commit dfb57e7 (glsl: Fix error checking on "flat" keyword to match
GLSL ES 3.00, GLSL 1.50) relaxed the rules for integral varyings: they
only need to be declared as "flat" if they are a fragment shader
inputs. This allowed for the possibility of a vertex shader output
being a non-flat integer, provided that it was not matched to a
fragment shader input. A non-contrived situation where this might
arise is if a vertex shader generates some integral outputs which are
consumed by tranform feedback, but not by the fragment shader.
Unfortunately, lower_packed_varyings assumes that *all* integral
varyings are flat, regardless of whether they are consumed by the
fragment shader. As a result, attempting to create a non-flat
integral vertex output of a size that required packing (i.e. a size
other than ivec4 or uvec4) would cause an assertion failure in
lower_packed_varyings.
This patch prevents the assertion failure by forcing vertex shader
outputs to be "flat" whenever they are not consumed by the fragment
shader. This should have no effect on rendering since the "flat"
keyword only affects the behaviour of fragment shader inputs.
Fixes piglit test "spec/EXT_transform_feedback/nonflat-integral".
NOTE: This is a candidate for the 9.1 release branch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
ir_print_visitor::visit(ir_variable *)'s mode[] array needs to match
the declaration of the enum ir_variable_mode. It's hard to verify
that at compile time, but at least we can use a STATIC_ASSERT to make
sure it's the right size.
This required adding ir_var_mode_count to the enum.
This patch updates the interp[] array to match the enum
glsl_interp_qualifier.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Add a STATIC_ASSERT to make sure the array is the correct size.
This required adding INTERP_QUALIFIER_COUNT to the enum.
Fixes uninitialized scalar variable defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
The multiplication part of tgsi_umad did not work on Cayman, because it did
not populate the correct vector slots.
This fixed hardlocks in the EXT_transform_feedback/order tests.
NOTE: This is a candidate for the stable branches.
(might not be easy to cherry-pick though)
Signed-off-by: Marek Olšák <maraeo@gmail.com>
This option can force textures to be untiled. However, on Gen6+, depth
buffers must be Y-tiled. MSAA buffers also must be Y-tiled. So setting
this option on even a trivial application like glxgears causes assertion
failures in a debug build, and likely GPU hangs in a release build.
It's just giving users a license to shoot themselves in the foot.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
In the past, we preferred X-tiling for color buffers because our BLT
code couldn't handle Y-tiling. However, the BLT paths have been largely
replaced by BLORP on Gen6+, which can handle any kind of tiling.
We hadn't measured any performance improvement in the past, but that's
probably because compressed textures were all untiled anyway.
Improves performance in GLB27_TRex_C24Z16_FixedTime by 7.69231%.
v2: Rebase on top of Eric's untiled-for-larger-than-aperture changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The code has no rationale for why we would force compressed textures to
be untiled, and it appears to work fine. Git archeology indicates that
it's been that way dating back to when we first started tiling.
Improves performance in GLB27_TRex_C24Z16_FixedTimeStep at 1280x720 by
10.0529% +/- 0.573075% (n=12). Improves performance in Xonotic by
4.56409% +/- 0.27965% (n=3).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch (1) extracts from intel_miptree_create() the spaghetti logic
that selects the tiling format, (2) rewrites that spaghetti into a lucid
form, and (3) moves it to a new function, intel_miptree_choose_tiling().
No behavioral change.
As a bonus, it is now evident that the force_y_tiling parameter to
intel_miptree_create() does not really force Y tiling.
v2 (Ken): Rebase on top of Eric's untiled-for-larger-than-aperture
changes. This required passing in the miptree.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
When moving the renderbuffer to a new miptree, we neglected to allocate
the hiz buffer for the new miptree. Oops.
Fixes all Piglit depthstencil-render-miplevels tests from crash to pass on
Sandybridge.
Note: This is a candidate for the 9.1 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
calim pointed out we were getting mipmap levels for array multisamples,
this didn't make sense. So then I noticed this function takes last_level
so we are passing in a too high value here.
I think this should fix the case he was seeing.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Check the type of the array operand and the index operand before doing
other checks. This simplifies the code a bit now (eliminating the
error_emitted parameter), and enables some later functional changes.
The shader
uniform float x[6];
uniform sampler2D s;
void main() { gl_Position.x = xx[s + 1]; }
still generates (only) the two expected errors:
0:3(33): error: `xx' undeclared
0:3(39): error: Operands to arithmetic operators must be numeric
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously the shader
uniform float x[6];
void main() { gl_Position.x = x[1.0]; }
would have generated the errors
0:2(33): error: array index must be integer type
0:2(36): error: array index must be < 6
Now only
0:2(33): error: array index must be integer type
will be generated.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This puts all of the checks togeher for easier reading. It also means
that all the checks are blocked on array->type->is_array. Shortly this
will allow elimination of some is_error check work-arounds in this
function.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Also, document the reason for not checking for type->is_array in some of
the bound-checking cases.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
That last consumer of the return value was changed to not use it by the
previous commit.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The error_emitted flag is used in semantic checking to prevent spurious
cascading errors. For example,
void foo(sampler2D s, float a)
{
float x = a + (1.2 + s);
...
}
should only generate a single error. Without the error_emitted flag for
the first error, "a + ..." would also generate an error.
However, a bunch of cases in _mesa_ast_array_index_to_hir that were
setting error_emitted would mask legitimate errors. For example,
vec4 a[7];
float b = a[3.14];
should generate two error (float index and type mismatch in assignment).
The uses of error_emitted would cause only the first to be emitted.
This patch removes most of the places in _mesa_ast_array_index_to_hir
that would set the error_emitted flag.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I love 800+ line switch-statements as much as the next guy... Future
commits will make changes to this part of the AST-to-HIR conversion, and
extracting this code will make that a bit easier.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This still fails, since 8192*4bpp == 32768, which is too big to use the
blitter on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we require 2.6.39, there's no need to also check for 2.6.29.
Calling drm_intel_bufmgr_gem_enable_fenced_relocs() without checking
should be safe, as it simply sets a flag.
This does remove the check for zero fences available, but that doesn't
seem worth checking.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Chris Wilson's relaxed relocation patch landed in March 2011. Anyone
running pre-3.0 kernels probably isn't going to get the latest Mesa
anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
These were likely used for BRW_NEW_... dirty bit flags at one point, but
they're unused now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Nobody uses this value, so there's no need to set it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
When I removed the proj_attrib_mask optimization, I also removed the
last consumer of this bit without realizing it.
Since nobody uses it, there's no point in flagging it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Clover needs the irreader component of llvm
v2: Check for irreader component
irreader is only available with LLVM 3.3 >= 177971
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
It has 2 dependencies: glClampColor and the framebuffer, we might just as well
do the update where those two are changed.
v2: cosmetic changes from Brian's email
Reviewed-by: Brian Paul <brianp@vmware.com>
This should reduce shader recompilations with drivers that emulate fragment
color clamping, because we want the clamping to be enabled only if there is
a signed normalized or floating-point colorbuffer.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reported-by: `per` in #intel-gfx
The size of the cache key varies, so store the actual size as well as
the key blob itself, rather than just assuming it's the same as the size
passed in.
NOTE: This is a candidate for stable branches.
V2: Don't leave silly holes in structure; use unsigned instead of GLuint.
V3: Fix missing case for `last` match.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This function is a holdover from r600g and is identical to
si_pm4_inval_texture_cache(), so it is not needed.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com
This target string now contains four values instead of three. The old
processor field (which was really being interpreted as arch) has been split
into two fields: processor and arch. This allows drivers to pass a
more a more detailed description of the hardware to compiler frontends.
v2:
- Adapt to libclc changes
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Add UTIL_FORMAT_LAYOUT_ETC to util_format_is_compressed. It was missing.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Don't check if there's sampler support for stencil if we're not
going to actually blit/copy stencil values. Fixes the case where
we mistakenly said we can't support a blit of depth values from
S8Z24 to X8Z24.
Also, rename the is_stencil variable to dst_has_stencil to improve
readability.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Switch to use the envytools generated headers for register/bitfield
definitions. This is the first step in preparing to add a3xx support,
since it avoids having conflicting names for a3xx and a2xx registers.
And since I'm using envytools for a3xx it is simpler to just use it for
everything.
This shouldn't cause any functional change, it is really just a lot of
renaming.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Otherwise we will not receive destroy windows events, causing framebuffers
to leak.
This happens particularly with java and jogl.
Tested with java + jogl, MATLAB.
VMware Internal Bug Number: 1013086.
Reviewed-by: Brian Paul <brianp@vmware.com>
At least on llvm 3.2 this appears to work fine. Tested on an Athlon XP
2600+, which has sse and 3dnow but not sse2.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Build time option, set RADEON_CS_DUMP_ON_LOCKUP to 1 in radeon_drm_cs.h to
enable it.
When enabled after each cs submission the code will try to detect lockup by
waiting on one of the buffer of the cs to become idle, after a timeout it
will consider that the cs triggered a lockup and will write a radeon_lockup.c
file in current directory that have all information for replaying the cs.
To build this file :
gcc -O0 -g radeon_lockup.c -ldrm -o radeon_lockup -I/usr/include/libdrm
v2: Add radeon_ctx.h file to mesa git tree
v3: Slightly improve dumped file for easier editing, only dump first faulty cs
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
The default wrap mode (PIPE_TEX_WRAP_REPEAT) is incompatible with
unnormalized texcoords (at least for softpipe).
v2: use PIPE_TEX_WRAP_CLAMP_TO_EDGE
Reviewed-by: Marek Olšák <maraeo@gmail.com>
GLBenchmark 2.7's shaders contain conditional blocks like:
if (x) {
if (y) {
...
}
}
where the outer conditional's then clause contains exactly one statement
(the nested if) and there are no else clauses. This can easily be
optimized into:
if (x && y) {
...
}
This saves a few instructions in GLBenchmark 2.7:
total instructions in shared programs: 11833 -> 11649 (-1.55%)
instructions in affected programs: 8234 -> 8050 (-2.23%)
It also helps CS:GO slightly (-0.05%/-0.22%). More importantly,
however, it simplifies the control flow graph, which could enable other
optimizations.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This clarifies that the offset of 2 is actually 16 kB / 8kB units.
It also keys both computations off of a single variable, which should
make it easier to change in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
These variables are only used within a single function, so we may as
well make them local variables.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This was only produced by the brw_wm_input_dimensions atom, which was
removed in the previous commit. So there's no need for the dirty bit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was only used to compute proj_attrib_mask, which was removed by the
previous commit. That makes this dead code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
The previous commit removed the last user of this field, so there's no
longer any point in setting it. Removing this should eliminate
state-dependent recompiles, and make the precompile more reliable.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This optimization attempts to avoid extra attribute interpolation
instructions for texture coordinates where the W-component is 1.0.
Unfortunately, it requires a lot of complexity: the brw_wm_input_sizes
state atom (all the brw_vs_constval.c code) needs to run on each draw.
It computes the input_size_masks array, then uses that to compute
proj_attrib_mask. Differences in proj_attrib_mask can cause
state-dependent fragment shader recompiles. We also often fail to guess
proj_attrib_mask for the fragment shader precompile, causing us to
needlessly compile it twice.
Furthermore, this optimization only applies to fixed-function programs;
it does not help modern GLSL-based programs at all. Generally, older
fixed-function programs run fine on modern hardware anyway.
The optimization has existed in some form since the initial commit. When
we rewrote the fragment shader backend, we dropped it for a while. Eric
readded it in commit eb30820f26 as part of
an attempt to cure a ~1% performance regression caused by converting the
fixed-function fragment shader generation code from Mesa IR to GLSL IR.
However, no performance data was included in the commit message, so it's
unclear whether or not it was successful.
Time has passed, so I decided to re-measure this. Surprisingly,
Eric's OpenArena timedemo actually runs /faster/ after removing this and
the brw_wm_input_sizes atom. On Ivybridge at 1024x768, I measured a
1.39532% +/- 0.91833% increase in FPS (n = 55). On Ironlake, there was
no statistically significant difference (n = 37).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is the same computation as the _WriteEnabled flag, so we may as
well use it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
ctx->Stencil.WriteMask is a statically sized array of 3 elements.
Checking it against 0 actually is a NULL check, and can never fail,
which meant that we always said stencil writes were enabled.
Use the new core Mesa derived state flag to fix this.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965 needs to know whether stencil writes are enabled in several places,
and gets the test wrong sometimes. While we could create a function to
compute this, it seems generally useful enough to warrant a new piece of
derived state. Also, all the plumbing is already in place.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
The ar_ge_as_at variable was just very very confusing since the condition
was actually the other way around (as_at_ge_ar). So change the condition
(and the selects depending on it) to match the variable name.
And also change the chosen major axis in case the coord values are the
same. OpenGL doesn't care one bit which one is chosen in this case but
it looks like dx10 would require z chosen over y, and y chosen over x
(previously did x chosen over y, y chosen over z). Since it's all the
same effort just honor dx10's wishes. (Though actually, for some prefered
orderings, we could save one (or two with derivatives) selects since the
tnewx and tnewz (and the corresponding dmax values) are the same.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The way we were allocating registers before, packing into low register
numbers for Ironlake, resulted in an overly-constrained dependency graph
for instruction scheduling. Improves GLBenchmark 2.1 performance by
4.5% +/- 0.7% (n=26). No difference on my old GLSL demo (n=20). No
difference on nexuiz (n=15).
v2: Fix off-by-one bug that made the change only work for 16-wide on i965.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
GCC 4.8 now warns about typedefs that are local to a scope and not
used anywhere within that scope. This produced spurious warnings with
the STATIC_ASSERT() macro (which used a typedef to provoke a compile
error in the event of an assertion failure).
This patch switches to a simpler technique that avoids the warning.
v2: Avoid GCC-specific syntax. Also update p_compiler.h.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The former just checks that the given block is valid by checking
the header and footer.
The later sets the memory block's tag. With extra debug code, we
can use that for monitoring/checking particular allocations.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This is trivial now, though need to make sure we pass all the necessary
derivative values (which is 3 each for ddx/ddy not 2).
Passes piglit arb_shader_texture_lod-texgradcube test.
v2: add the forgotten abs() for all incoming derivatives (discovered
by new piglit arb_shader_texture_lod-texgradcube test, though more by
luck as it was failing only for exactly one pixel...).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This proved to be tricky, the problem is that after selection/mirroring
we cannot calculate reasonable derivatives (if not all pixels in a quad
end up on the same face the derivatives could get "randomly" exceedingly
large).
However, it is actually quite easy to simply calculate the derivatives
before selection/mirroring and then transform them similar to
the cube coordinates (they only need selection/projection, but not
mirroring as we're not interested in the sign bit, of course). While
there is a tiny bit more work to do (need to calculate derivs for 3
coords instead of 2, and additional selects) it also simplifies things
somewhat for the coord selection itself (as we save some broadcast aos
shuffles, and we don't need to calculate the average vector) - hence if
derivatives aren't needed this should actually be faster.
Also, this has the benefit that this will (trivially) work for explicit
derivatives too, which we completely ignored before that (will be in a
separate commit for better trackability).
Note that while the way for getting rho looks very different, it should
result in "nearly" the same values as before (the "nearly" is only because
before the code would choose the face based on an "average" vector and hence
the derivatives calculated according to this face, where now (for implicit
derivatives) the derivatives are projected on the face selected for the
first (top-left) pixel in a quad, so not necessarly the same face).
The transformation done might not quite be state-of-the-art, calculating
length(dx,dy) as max(dx,dy) certainly isn't neither but this stays the
same as before (that is I think a better transform would _somehow_ take
the "derivative major axis" into account so that derivative changes in
the major axis wouldn't get ignored).
Should solve some accuracy problems with cubemaps (can easily be seen with
the cubemap demo when switching wrapping/filtering), though we still don't
do seamless filtering to fix it completely (so not per-sample but per-pixel
is certainly better than per-quad and already sufficient for accurate
results with nearest tex filter).
As for performance, it seems to be a tiny bit faster too (maybe 3% or so
with cubemap demo). Which I'd have expected with nearest/nearest filtering
where this will be less instructions, but the difference seems to actually
be larger with linear/linear_mipmap_linear where it is slightly more
instructions, probably the code appears less serialized allowing better
scheduling (on a sandy bridge cpu). It actually seems to be now at least
as fast as the old path using a conditional when using 128bit vectors too
(that is probably more a result of testing with a newer cpu though), for now
that old path is still there but unused.
No piglit regressions.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Using a different packing for the single coord case should save a shuffle.
Plus some minor style fixes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Should be way faster of course on cpus supporting this (includes AMD
Bulldozer and Jaguar cores, Intel Ivy Bridge and up (except budget models)).
Passes piglit fbo-blending-formats GL_ARB_texture_float -auto on Ivy Bridge.
Reviewed-by: Brian Paul <brianp@vmware.com>
When geometry shaders are present, one needs to be able to create
an empty geometry shader with stream output that needs to be
resolved later and attached to the currently bound vertex shader.
Lets add support for it to llvmpipe and draw. draw allows attaching
independent stream output info to any vertex shader and llvmpipe
resolves at draw time which vertex shader the given empty geometry
shader should be linked to.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We need to reset the internal state of the so buffers or we'll
keep appending even though we're not supposed to.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
I think this was there before and got accidently
removed during a merge. Same code as for the GS
context, which is also using an enum instead of
hardcoded numbers.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
It's quite helpful during the rendering when we know
exactly the count of the vertices available in the
buffer.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We were flushing with incorrect number of primitives. TGSI exec
can only work with a single primitive at a time. Plus the fetching
with multiple primitives on llvm paths wasn't copying the last
element.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The functions are prototyped in u_transfer.h and are related to the
other functions in u_transfer.c.
The next patch will re-use the u_resource.c file for new code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The fallbacks count is the number of drawing calls that use a "draw"
module fallback, such as polygon stipple.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
NOTE: Changed the semantic index for the drawtex coordinate to
be the texture unit index instead of always 0.
Not sure if this is correct but since the value seems to depend
on the unit it would make sense to use different varying slots.
This still isn't optimal, since the fence will signal a bit late,
but better than checking on the bo, which may never be ready if it
is shared (which is likely).
Also, renamed "pixels-rendered" to "samples-passed" because the
occlusion counter increments even if colour and depth writes are
disabled, or (on some implementations) for killed fragments that
passed the depth test when PS early_fragment_tests is set.
This patch consolidates duplicate code in the brw_depthbuffer and
gen7_depthbuffer state atoms. Previously, these state atoms contained
5 chunks of code for emitting the _3DSTATE_DEPTH_BUFFER packet (3 for
Gen4-6 and 2 for Gen7). Also a lot of logic for determining the
appropriate buffer setup was duplicated between the Gen4-6 and Gen7
functions.
This refactor splits the code into three separate functions:
brw_emit_depthbuffer(), which determines the appropriate buffer setup
in a mostly generation-independent way, brw_emit_depth_stencil_hiz(),
which emits the appropriate state packets for Gen4-6, and
gen7_emit_depth_stencil_hiz(), which emits the appropriate state
packets for Gen7.
Tested using Piglit on Gen5-7 (no regressions).
v2: Re-word some comments. Fix an assertion that incorrectly
prohibited packed depth/stencil formats on Gen6 (these are allowed
provided that HiZ is disabled).
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit dbf94d105a, which
was working around a bug in the handling of array indexing when
constant folding built-in functions. Now that the constant folding
bug has been fixed, the workaround is no longer needed.
Mesa constant-folds built-in functions by using a miniature GLSL
interpreter (see
ir_function_signature::constant_expression_evaluate_expression_list()).
This interpreter had a bug in its handling of array indexing, which
caused expressions like "m[i][j]" (where m is a matrix) to be handled
incorrectly. Specifically, it incorrectly treated j as indexing into
the whole matrix (rather than indexing just into the vector m[i]); as
a result the offset computed for m[i] was lost and m[i][j] was treated
as m[j][0].
Fixes piglit tests inverse-mat[234].{vert,frag}.
NOTE: This is a candidate for the 9.1 and 9.0 branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57436
Conceptually the same as previously done in float_to_half.
Should cut down number of instructions from 14 to 10 or so, but
will promote some NaNs to Infs, so it's disabled.
It gets a bit tricky though handling all the cases correctly...
Passes basic tests either way (though there are no tests testing special
cases, but some manual tests injecting them seemed promising).
v2: style and comment fixes suggested by Jose
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This replaces the existing float-to-half implementation.
There are definitely a couple of differences - the old implementation
had unspecified(?) rounding behavior, and could at least in theory
construct Inf values out of NaNs. NaNs and Infs should now always be
properly propagated, and rounding behavior is now towards zero
(note this means too large but non-Infinity values get propagated to max
representable value, not Infinity).
The implementation will definitely not match util code, however (which
does nearest rounding, which also means too large values will get
propagated to Infinity).
Also fix a bogus round mask probably leading to rounding bugs...
v2: fix a logic bug in handling infs/nans.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reduced stack size allows to run more threads in some cases,
improving performance for the shaders that use stack (that is, for the
shaders with control flow instructions). E.g. with unigine-based apps.
v4: implement exact computation taking into account wavefront size
v5: add cases for RV620, RS880
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
v2: reduce key size, don't copy key around to much.
v3: remove key size reduction
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
A fix for lower_jumps progress reporting, very much like similar in
c1e591eed.
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
All the other expression types allowed here have inst->mlen == 0, and this
one has implied MRF writes for all of its payload, so nothing else in the
implementation should need to change.
Reduces SEND messages for loading from pull constants in kwin's Lanczos
shader from 16 to 6. (Due to a deficiency in constant propagation, I
can't use the hack I did in the previous commit to test the performance
change)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61554
NOTE: This is a candidate for the 9.1 branch.
This comes at a minor performance cost at the moment (-3.2% +/- 0.2%, n=14 on
my GM45 forced to load all uniforms through the varying-index path), but we
get a whole vec4 at a time to reuse in the next commit.
v2: Fix comment about channels in the other message.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for the 9.1 branch.
We weren't setting needs_dep[i] in the loops, so we'd continue on to
potentially add the same workaround MOVs to the later basic block
boundaries, too. We can either set needs_dep[i] to exit through the
normal path, or we can just return since we know we're done.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For sampler messages, it depends on the target gen, and on gen4
SIMD16-sampler-on-SIMD8-execution we were returning 4 instead of 8 like we
should.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for the 9.1 branch.
I think this makes it much more obvious what's going on here.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is our first CSE on a regs_written() > 1 instruction, so it takes a
bit of extra fixup. Reduces the number of loads on kwin's Lanczos shader
from 12 to 2.
v2: Fix compiler warning (false positive on possibly-uninitialized variable)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61554
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
NOTE: This is a candidate for the 9.1 branch.
Like we have done for the VS and for constant-index uniform loads, we use
the sampler engine to get caching in front of the L3 to avoid tickling the
IVB L3 bug. This is also a bit of a functional change, as we're now
loading a vec4 instead of a single dword, though we're not taking
advantage of the other 3 components of the vec4 (yet).
With the driver hacked to always take the varying-index path for all
uniforms, improves performance of my old GLSL demo by 315% +/- 2% (n=4).
This a major fix for some blur shaders in compositors from the
varying-index uniforms support I introduced in 9.1.
v2: Move old offset computation into the pre-gen7 path.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61554
NOTE: This is a candidate for the 9.1 branch.
Right now we don't have anything with regs_written() > 1 and !inst->mlen,
but that's about to change.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We want to load vec4s, since loading a vec4 instead of a dword is
basically no increased latency. But for variable indexed access, the
previous requirement of aligned vec4s for a sampler LD was hard to
implement.
Note that this change only affects those messages that use the surface
format, like sampler LDs, but not to the untyped data cache loads we've
used in other cases.
No significant performance difference on my GLSL demo with uniforms forced
to take the varying pull constants path (n=4).
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This puts the rounding-up logic into the function itself instead of all
the callers having to manage it. Also drop an "unused" comment in gen4,
as the stride *is* used for texbos (and will be for uniforms soon).
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I'm going to want to change the math for gen7 using sampler LD
instructions in a way that gets CSE to occur like we'd hope.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We weren't inserting it into the list, so it did nothing. This line was
replaced by the MOV/MUL block above.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This happens quite a bit with varying-index uniform loads. We could also
do better by avoiding the MACH entirely, but there's no reason not to at
least take this step.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the active uniform is an array, then the length of the uniform name should
include the three extra characters for the "[0]" suffix, which is required by
the GL 4.2 spec to be appended to the uniform name in glGetActiveUniform().
This avoids the situation where the output buffer does not have enough space
to hold the "[0]" suffix, resulting in an incomplete array specification like
"foobar[0".
NOTE: This is a candidate for the 9.1 branch.
Change-Id: I41e87ba347a7169eec8c575596cc3416adbe0728
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is a more aggressive version of the old brw_optimize() path. Reduces
cycles spent in the vertex shader on minecraft by 18.6% +/- 10.0% (n=15).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We dump shader source in ir_to_mesa.cpp, and we dump linked programs here,
but we had no reference from the linked programs to their source. This
was preventing improvement of shader-db to use linked shader programs
instead of individual shader files (which is bogus, because it means we
optimize out VS outputs, and don't interpolate FS inputs!)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If we're drawing to a surface that's 2048 x 2048 pixels or larger there's
danger of fixed-point overflow in the triangle rasterization code. That
leads to various rendering glitches.
Rather than implement some intricate changes to the rasterization code,
simply subdivide triangles into smaller subtriangles to avoid the issue.
Only do this when the drawing surface is larger than 2048 by 2048.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This can be enabled everywhere that ARB_texture_multisample is
supported -- ARB_texture_storage is supported on everything.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
ARB_texture_storage_multisample allows texture parameters to be
queried for TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY
targets.
Some parameters may also be set, with the following exceptions:
- TEXTURE_BASE_LEVEL may not be set to a nonzero value; generates
INVALID_OPERATION
- any state which appears in the `per-sampler` state table may not
be set; generates INVALID_OPERATION
V2: Don't introduce bogus handling of TEXTURE_MAX_LEVEL
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
Now that there are 4 variants, just pass the function name into
teximagemultisample rather than reconstructing it.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
Adds XML for the extension, dispatch_sanity enabling, and the two new
entrypoints. These are both implemented by calling the shared
teximagemultisample() with immutable=GL_TRUE.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
The new entrypoints will come later, but this adds the actual logic for
supporting immutable multisample textures:
- The immutability flag is set as desired.
- Attempting to modify an immutable multisample texture produces
INVALID_OPERATION.
Note: The extension spec does not mention adding this behavior to
TexImage*Multisample, but it seems like the reasonable thing to do.
V2: - Cover missing error cases (unsized formats; texture object zero)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[V1] Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Brian Paul <brianp@vmware.com>
This is about to be used in teximagemultisample() when immutable=true.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
We are intentionally not allocating a slot for gl_ClipVertex. But by
leaving the bit set in the slots_valid, the fragment shader's computation
of where varyings are in urb entry coming out of the SF would be off by
one. Fixes rendering in Freespace 2 SCP, and improves rendering in TF2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62830
Tested-by: Joaquín Ignacio Aramendía <samsagax@gmail.com>
NOTE: This is a candidate for the 9.1 branch.
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Alessandro Pignotti noted when I added this code in commit
0e723b135b that it's in the else block for
"if (busy)", so this debug print couldn't happen.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When reading a column from a row-major matrix, we would slot the single
value read into the vector using an ir_dereference_array of the vector
with a constant index. This will (eventually) get optimized to a
masked-write, so just generate the masked write in the first place.
v2: Remove unused variable 'chan'. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Search and replace:
][0] -> ].x
][1] -> ].y
][2] -> ].z
][3] -> ].w
Fixes piglit tests inverse-mat[234].{vert,frag}. These tests call the
inverse function with constant parameters and expect proper constant
folding to happen. My suspicion is that this patch papers over some bug
in constant propagation involving array accesses.
Either way, all of these accesses eventually get lowered to swizzles.
This cuts out the middle man (saving a trivial amount of CPU).
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Paul Berry <stereotype441@gmail.com>
Since the case was missing bec4->get_scalar_type() would return bvec4,
but vec4->get_scalar_type() would return float.
NOTE: This is a candidate for stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
"discard" instructions generate HALT instructions which jump to a final
HALT near the end of the shader. Previously, fs_generator created this
final jump target when it saw the first FS_OPCODE_FB_WRITE, causing it
to jump right before the FB write epilogue. This is normally good.
However, INTEL_DEBUG=shader_time also has an epilogue section which
records the final timestamp. The frontend emits IR for this just before
FS_OPCODE_FB_WRITE. Unfortunately, this led to the following ordering:
1. Shader Time Epilogue
2. Final HALT (where discards jump)
3. Framebuffer Write Epilogue
This meant that discarded pixels completely skipped the shader time
epilogue, causing no ending timestamp to be written. This obviously
led to inaccurate results.
This patch adds a new FS_OPCODE_PLACEHOLDER_HALT in the IR stream just
before any epilogue sections. This is where the final HALT should be
generated, and makes it easy to ensure the correct ordering:
1. Final HALT
2. Shader Time Epilogue
3. Framebuffer Write Epilogue
For shaders that don't discard, this opcode compiles away to nothing.
The scheduler adds barrier dependencies to make sure that it doesn't
get moved above any FS_OPCODE_DISCARD_JUMP instructions.
One 8-wide shader in GLBenchmark 2.7 dropped from 2291.67 Gcycles to
a mere 5.13 Gcycles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
I'd previously added the minimum names to understand my dumps, but this
makes dumps in general much easier to read.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2 [mattst88]:
- Rebase.
- #define GL_ARB_texture_query_lod to 1.
- Remove comma after ir_lod in ir.h for MSVC.
- Handled ir_lod in ir_hv_accept.cpp, ir_rvalue_visitor.cpp,
opt_tree_grafting.cpp.
- Rename textureQueryLOD to textureQueryLod, see
https://www.khronos.org/bugzilla/show_bug.cgi?id=821
- Fix ir_reader of (lod ...).
v3 [mattst88]:
- Rename textureQueryLod to textureQueryLOD, pending resolution of
Khronos 821.
- Add ir_lod case to ir_to_mesa.cpp.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
x before
+ after
+------------------------------------------------------------------------------+
| x x + |
| xx ++ x + |
| xx ++ + xx ++ |
|x xxx x+++++ + xxx x*x+*+++ + x +|
| |_____|____________A______A____M____M_|_______| |
+------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 23 8083.78 8287.83 8205.55 8162.7461 68.307951
+ 23 8107.56 8358.74 8224.33 8186.1765 71.506301
No difference proven at 95.0% confidence
Reviewed-by: Eric Anholt <eric@anholt.net>
Set its latency to what happens to be the default floating-point
instruction latency. One day we may want to handle latency based on
register bank information.
Reviewed-by: Eric Anholt <eric@anholt.net>
Similar enough that we can try to use shared code.
v2: fix a stupid bug using wrong variable causing mayhem with Inf and NaNs.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com
Previously at least i915 failed to provide an implementation, but
exposed ARB_internalformat_query anyway, leading to crashes when
QueryInternalformativ was called.
Default implementation just returns 1 for everything, so is suitable for
any driver which does not support multisampling.
V2: - Move from intel to core mesa.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's more, but this only adds (most) of the counters that are
handled directly by the shader processors.
The other counter domains are not handled on the multiprocessor and
there are no FIFO object methods for configuring them.
Instead, they have to be programmed by the kernel via PCOUNTER, and
the interface for this isn't in place yet.
We can use %-6s%-6s rather than manually counting characters, resulting
in much more readable code.
This necessitates a small secondary change: using "total fs16" and ""
now causes the "" string to be padded out to 6 characters, resulting in
too much whitespace. Splitting it into "total" and "fs16" produces the
same output as before.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This much more accurately reflects the cost of the vertex shader, since
the payload setup is often a significant fraction of the instructions in
the VS.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This incidentally also teaches it a bit about gen6 math -- we now allow
unswizzled, unmodified GRF temps as the sources for math.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, if you just wrote a constant color to the render target, no
time got noted at all. This is convenient for doing single-instruction
timings, but not so much for actual program analysis.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This avoids conflicts between shader_time and FB writes, so we can include
more of the program under our profiling. This does mean hiding more of
the message setup from the optimizer, which doesn't have a way to handle
multi-reg sends from GRFs.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Ken asked me the other day what -1 vs 0 vs 3 vs other meant in our shader
names, and I realized that it was really unclear. I'd like to do even
better, like noting which one is the clear shader, but that would require
exposing the metaops struct to the driver.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We weren't correctly propagating the samplers and sampler views
when they were related to geometry shaders.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
We were allocating the output buffer but using the input
primitives. We need to allocate that buffer using the
maximum number of output, not input, primitives.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
TGSI semantics currently require an implicit endprim at the end
of GS if an ending primitive hasn't been emitted.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This commits implements code generation of the geometry shaders in
the SOA paths. All the code is there but bugs are likely present.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Allows executing gs on up to 4 primitives at a time. Will also be
required by the llvm code because there we definitely don't want
to flush with just a single primitive.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
To be able to add llvm paths later on we need to have some common
interface for them.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The member was never used and we'll need to handle it differently
because gs will also need samplers/textures setup.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
v2: Use WRITE_DATA packet instead of WRITE_MEM
v3: Remove useless nop packet
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Fixes various test fallout from 90b5a2425a on Pineview, which claims to
support ARB_internalformat_query but doesn't actually provide the
driverfunc.
That driver is still broken [GetInternalformativ will still segfault!]
but it was silly to be going through the sample count logic in the
nonmultisampling case at all.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The pipe query interface is reused. The list of available queries can be
obtained using pipe_screen::get_driver_query_info.
Reviewed-by: Brian Paul <brianp@vmware.com>
Virtual address is used for PIPE_QUERY_SO* queries in
r600_emit_query_begin, but not in r600_emit_query_end.
This will trigger a GPU fault when one of those queries is
made and virtual address is enabled.
Note: this is a candidate for the 9.1 branch
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Optimize out parts of the render target that are scissored out by taking
into account maximal scissor bounds in fd_gmem_render_tiles().
This is a big win on things like gnome-shell which frequently do partial
screen updates.
Signed-off-by: Rob Clark <robdclark@gmail.com>
target-specific variables are undefined when used as pre-requisites.
instead, use secondary-expansion.
I noticed this when building the patch:
i965: Add a driconf option to disable flush throttling
Signed-off-by: Adrian Marius Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Since half of ir_validate uses asserts() (the other using printf() then
abort()), there's not much use to calling it in a release build. Cuts
6.3% of the startup time of TF2.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes assign instead of compare defects reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This patch changes the arrays in brw_vue_map (which only ever contain
values from -1 to 58) from ints to signed chars. This reduces the
size of the struct from 488 bytes to 136 bytes.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: fix STATIC_ASSERT to use 127 instead of 128.
Reviewed-by: Eric Anholt <eric@anholt.net>
With the introduction of geometry shaders, fragment inputs will no
longer come exclusively from the vertex shader; sometimes they come
from the geometry shader. So the name "vp_outputs_written" will
become a misnomer. This patch renames vp_outputs_written to
input_slots_valid, to reflect the true meaning of the bitfield from
the fragment shader's point of view: it indicates which of the
possible input slots contain valid data that was written by the
previous shader stage.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch modifies post-GS pipeline stages (transform feedback, clip,
sf, fs) to refer to the VUE map through brw->vue_map_geom_out rather
than brw->vs.prog_data->vue_map. This ensures that when geometry
shader support is added, these pipeline stages will consult the
geometry shader output VUE map when appropriate, rather than the
vertex shader output VUE map.
v2: Fixed some stale "CACHE_NEW_VS_PROG" comments.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Currently, the GPU pipeline has one active VUE map in effect at any
given time--the one representing the layout of vertex data coming from
the vertex shader. However, when geometry shaders are added, they
will have their own independent VUE map. Later pipeline stages (clip,
sf, fs) will need to consult the geometry shader VUE map if a geometry
shader is in use, and the vertex shader VUE map otherwise.
This patch adds a new field to brw_context, vue_map_geom_out, which
contains the VUE map that should be used by later pipeline stages. It
also adds a new state flag, BRW_NEW_VUE_MAP_GEOM_OUT, which is
signalled whenever the contents of the VUE map changes.
Since we don't support geometry shaders yet, vue_map_geom_out is
currently set only by the brw_vs_prog state atom.
v2: Don't set vue_map_geom_out in do_vs_prog--that's redundant and
possibly problematic for precompiles. Only set it in
brw_upload_vs_prog. Also, make a copy instead of using a
pointer--this makes it possible to detect when the VUE map hasn't
changed, so we can avoid redundant state uploads.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Future patches will allow for there to be separate VUE maps when both
a geometry shader and a vertex shader are in use. When this happens,
we will want to have correspondingly separate outputs_written
bitfields. Moving outputs_written into the VUE map will make this
easy.
For consistency with the terminology used in the VUE map, the bitfield
is renamed to "slots_valid" in the process.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Gen7 adds mask bits to the message header for a URB write which allow
the write to apply only to certain channels. We don't use this
functionality, so to ensure that the entire write always occurs, we
emit an OR instruction to set the mask bits.
With the advent of geometry shaders, URB writes won't just happen at
the end of a thread; they will happen in mid-thread too. Thus, we can
no longer rely on channel 0 being enabled, so we need to emit the OR
instruction in WE_all mode to ensure that it is executed.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The new name clarifies that it represents *one more* than the maximum
possible brw_varying_slot value.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch removes the terminology "vert_result" from the i965 driver,
replacing it with "varying". The old terminology, "vert_result", was
confusing because (a) it referred to the enum gl_vert_result, which no
longer exists (it was replaced with gl_varying_slot), and (b) it
implied a vertex output, but with the advent of geometry shaders, it
could be either a vertex or a geometry output, depending what shaders
are in use. The generic term "varying" is less confusing.
No functional change.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Whitespace fixes.
Bump MAX_DEPTH_TEXTURE_SAMPLES to match what GetInternalformativ is
claiming. Since that limit is what is actually enforced now, this
doesn't actually change anything except the queried value.
There's still no piglits verifying that multisample depth textures work,
but this works in the Unigine demos.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Extends _mesa_check_sample_count() to properly support the
TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY targets, which
have subtly different limits than renderbuffers.
This resolves the remaining TODO in the implementation of
TexImage*DMultisample.
V2: - Don't introduce spurious block.
- Do this in multisample.c instead.
- Fix typo in error message.
- Inline spec quotes
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Pulls the checking of the sample count into a helper function, and
extends the existing logic to include the interactions with both
ARB_texture_multisample and ARB_internalformat_query.
_mesa_check_sample_count() checks a desired sample count against a
a combination of target/internalformat, and returns the error enum
to be produced, if any. Unfortunately the conditions are messy and the
errors vary.
V2: - Tidy up spurious block.
- Move _mesa_check_sample_count() to multisample.c instead; It
doesn't really belong in fbobject.c or teximage.c.
- Inlined spec quotes
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Now that we support ARB_texture_multisample, there are multiple targets
accepted for this query, and they may have target-dependent limits, so
pass the target to the driverfunc.
For example, the sampling hardware may not be able to do general
texelFetch() for some format/sample count combination, but the driver
may still be able to implement a reasonable resolve operation, so it can
be supported for renderbuffers.
V2: - Don't break Gallium compile.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
And use this (and the code for r11g11b10 packed float to float conversion)
in the soa texturing code (the generated code looks quite good).
Should be an order of magnitude faster probably than using the fallback
(not measured).
Tested with piglit texwrap GL_EXT_packed_float and
GL_EXT_texture_shared_exponent respectively (didn't find much else using
it).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
Initial version contributed by: Martin Andersson <g02maran@gmail.com>
This is only used if the memcpy path cannot be used and if no transfer ops
are needed. It's pretty similar to our TexImage and GetTexImage
implementations.
The motivation behind this is to be able to use ReadPixels every frame and
still have at least 20 fps (or 60 fps with a powerful GPU and CPU)
instead of 0.5 fps.
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
I'll need the _mesa_readpixels_needs_slow_path function for the blit-based
version, but it's also useful to have this memcpy-based path in one place
and not scattered across several functions.
v2: add "const" to function parameters
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
I'll need both new functions for later. For now, it consolidates the code
for determining what the transfer ops should be and makes it a little bit
smarter.
v2: added "const"
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
New conversion code to handle conversion from/to r11g11b10 AoS to/from
SoA floats, and also add code for conversion from rgb9e5 AoS to float SoA
(which works pretty much the same as r11g11b10 except for the packing).
(This code should also be used for texture sampling instead of
relying on u_format conversion but it's not yet, so rgb9e5 is unused.)
Unfortunately a crazy amount of hacks is necessary to get the conversion
code running in llvmpipe's generate_unswizzled_blend, which isn't well
suited for formats where the storage representation has nothing to do
with what's needed for blending (moreover, the conversion will convert
from packed AoS values, which is the storage format, to float SoA values,
because this is much more natural for the conversion, and likewise from
SoA values to packed AoS values - but the "blend" (which includes
trivial things like partial mask) works on AoS values, so incoming fs
values will go SoA->AoS, values from destination will go packed
AoS->SoA->AoS, then do blend, then AoS->SoA->packed AoS which probably
isn't the most efficient way though the shuffles are probably bearable).
Passes piglit fbo-blending-formats (with GL_EXT_packed_float parameter),
still need to verify Inf/NaNs (where most of the complexity in the
conversion comes from actually).
v2: drop the (very bogus) rgb9e5 part, and do component extraction
in the helper code for r11g11b10 to float conversion, making the code
slightly more compact (suggested by Jose), now that there are no other
callers left this works quite well. (Could do the same for the
opposite way but it's less than ideal there, final part of packing
needs to be done in caller anyway and there'd be another conditional.)
v3: minor style and comment fixes. Also fix a potential issue with
negative zero being potentially returned by max(src, zero) as we
don't have well-defined min/max behavior (fortunately no additonal cost).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This helps minimize confusion / effort when moving between branches or
helping others.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Normally when submitting the first batch buffer after a flush, we
check whether the GPU has completed processing of the first batch
buffer of the previous frame. If it hasn't, we wait for it to finish
before submitting any more batches. This prevents GPU-heavy and
CPU-light applications from racing too far ahead of the current frame,
but at the expense of possibly lower frame rates. Sometimes when
benchmarking we want to disable this mechanism.
This patch adds the driconf option "disable_throttling" to disable the
throttling mechanism.
Reviewed-by: Eric Anholt <eric@anholt.net>
NOTE: This is a candidate for the 9.1 branch.
Fixes piglit's texture-immutable-levels test.
Reported-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The arithmetic to convert a 3D texture slice to an R coordinate was
incorrect. Found when MSVC warned of a divide by zero.
Note that we don't actually ever hit this path. We don't decompress
slices of 3D textures and we don't support 3D mipmap generation yet.
Fixes random failures with piglit glsl-max-varyings.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Christian König <christian.koenig@amd.com>
This makes basic built-in functions work in GLSL 1.50. It supports
everything except the new Geometry Shader functions.
The new 150.glsl file is 140.glsl plus ARB_texture_multisample.glsl;
150.frag is identical to 140.frag except for the #version bump.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
GLSL 1.50 includes support for the new sampler types introduced by
the ARB_texture_multisample extension.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Commit 33599433c7 began setting the texture swizzle mode to XYZ1 for
RED, RG, and RGB textures in order to force alpha to 1.0 in case we
actually stored the texture as RGBA.
This had a unforseen performance implication: the shader precompile
assumes that the texture swizzle mode will be XYZW for non-shadow
sampler types. By setting it to XYZ1, this means every shader used with
a RED, RG, or RGB texture has to be recompiled. This is a very common
case.
Unfortunately, there's no way to improve the precompile, since RGBA
textures still need XYZW, and there's no way to know by looking at
the shader source what texture formats might be used.
However, we only need to smash alpha to 1.0 if the texture's memory
format actually has alpha bits. If not, the sampler already returns 1.0
for us without any special swizzling. XRGB8888, for example, is a very
common case where this occurs.
This partially fixes a performance regression since commit 33599433c7.
More work is required to fully fix it in all cases. This at least helps
Warsow.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
With the old context creation mechanism, an application asked the GL to
give it a context. Failing to produce a context was a fatal error.
Now, with GLX_ARB_create_context, the application can request a specific
version. If it's higher than the maximum version we support, context
creation will fail. But this is a normal error that applications
recover from.
In particular, the new glxinfo tries to create OpenGL 4.3, 4.2, 4.1,
4.0, 3.3, and 3.2 contexts before finally succeeding at creating a 3.1
context. This led to it printing the following message 6 times:
"brwCreateContext: failed to init intel context"
There's no need to alarm users (and developers) with such a message.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
On an INTEL_DEBUG=perf piglit run on IVB, reduces the instances of "HW
workaround: blit" (the printouts from the misaligned-depth workaround
blits) from 725 to 675.
It doesn't totally eliminate the workaround blit, because we still have
problems with Y offsets that we can't fix (since texturing can only align
miplevels up to 2 or 4, not 8).
No regressions on piglit/es3conform on IVB.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This makes it possible to identify gl_TexCoord and gl_PointCoord
for drivers where sprite coordinate replacement is restricted.
The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings
should be hidden behind the GENERIC semantic or not.
With this patch only nvc0 and nv30 will request that they be used.
v2: introduce a CAP so other drivers don't have to bother with
the new semantic
v3: adapt to introduction gl_varying_slot enum
The commit changed API in a helper library shared by both egl_dri2 and
the gallium egl state tracker, but only egl_dri2 was updated to use the
new interface.
Tested-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Previous to this patch, when using fixed function fragment shading,
bit VARYING_BIT_POS of brw_wm_prog_key::proj_attrib_mask was being set
differently during precompiles and normal usage. During precompiles
it was being set only if the fragment shader reads from window
position (which it never does), so it was always being set to 0.
During normal usage it was being set if the vertex shader writes to
all 4 components of gl_Position (which it usually does), so it was
usually being set to 1. As a result, we were almost always doing an
extra recompile for the fixed function fragment shader.
The recompile was totally unnecessary, though, because
brw_wm_prog_key::proj_attrib_mask is only consulted for
fs_visitor::emit_general_interpolation(), which isn't used for
VARYING_SLOT_POS.
This patch avoids the unnecessary recompile by always setting bit
VARYING_BIT_POS of brw_wm_prog_key::proj_attrib_mask to 1.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, right after calling _mesa_glsl_link_shader(), the fixed
function fragment shader code made several calls with the ostensible
purpose of setting up uniforms for the fragment shader it just
created.
These calls are unnecessary, since _mesa_glsl_link_shader() calls
driver->LinkShader(), which takes care of calling these functions (or
their equivalent). Also, they are dangerous to call after
_mesa_glsl_link_shader() has returned, because on back-ends such as
i965 which do precompilation, _mesa_glsl_link_shader() may have
already cached pointers to the existing uniform structures; attempting
to set up the uniforms again invalidates those cached pointers.
It was only by sheer coincidence that this wasn't manifesting itself
as a bug. It turns out that i965's precompile mechanism was always
setting bit 0 of brw_wm_prog_key::proj_attrib_mask to 0 for fixed
function fragment shaders, but during normal usage this bit usually
gets set to 1. As a result, the precompiled shader (with its invalid
uniform pointers) was not being used.
I'm about to introduce some changes that cause bit 0 of
proj_attrib_mask to be set consistently between precompilation and
normal usage, so to avoid regressions I need to get rid of the
dangerous duplicate uniform setup code first.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to determine when
brw_workaround_depthstencil_alignment() is being called as a
consequence of glClear(), and avoids the unnecessary blit when it is
safe to do so.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Eliminate unnecessary call to _mesa_is_depthstencil_format(). Fix
handling of depth buffer in depth/stencil format.
v3: Use correct bitfields for clear_mask. Fix handling of depth
buffer in depth/stencil format when hardware uses separate stencil.
When invalidating, make sure we still reassociate the image to the new
miptree.
Reviewed-by: Eric Anholt <eric@anholt.net>
Doesn't exist on the asic and will cause a CS rejection
if VM is disabled.
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use vmw_printf() just for extra debugging info (off by default).
Use vmw_error() for real errors/failures/etc that we definitely
want to report.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Checks that no functions are exported that are not part of the ABI.
Note that currently we are exporting functions that are aliased to
functions that are part of the ABI. They shouldn't be exported, but the
XML descriptions don't adequately describe this case.
Checks that no functions are exported that are not part of the ABI.
Note that currently we are exporting functions that are aliased to
functions that are part of the ABI. They shouldn't be exported, but the
XML descriptions don't adequately describe this case.
If we're in some conditional or loop we must not return, or the code
after the condition is never executed.
(v2): And, we also can't just continue as nothing happened, since the
mask update code would later check if we actually have a mask, so we
need to remember that there was a return in main where we didn't exit
(to illustrate this, a ret in a if clause would cause a mask update
which is still ok as we're in a conditional, but after the endif the
mask update code would drop the mask hence bringing execution back to
pixels which should have their execution mask set to zero by the ret).
Thanks to Christoph Bumiller for figuring this out.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=62357.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
To further improve the optimization of source and destination
indirect addressing we need the ability to store a reference
to the declaration of the addressed operands.
Since most of the fields in tgsi_src_register doesn't apply for
an indirect addressing operand replace it with a separate
tgsi_ind_register structure and so make room for extra information.
v2: rename Declaration to ArrayID, put the ArrayID into () instead of []
Signed-off-by: Christian König <christian.koenig@amd.com>
Remember which declarations are declared as "arrays" and so
can be indirectly addressed. ArrayIDs start at 1, cause for
compatibility reasons zero is treaded as no array present.
Signed-off-by: Christian König <christian.koenig@amd.com>
Instead of allocating everything as temporaries, use the
new array allocation functions.
v2: fix bug in simplify_cmp, declare arrays on demand
Signed-off-by: Christian König <christian.koenig@amd.com>
Don't bother with free temporaries, just allocate them at
the end and also emit them in their own declaration.
Signed-off-by: Christian König <christian.koenig@amd.com>
Instead of emitting each temporary separately, emit them in a chunk.
v2: keep separate function for emitting temps
Signed-off-by: Christian König <christian.koenig@amd.com>
No functional change here, but this will let us query the image
for an fd handle later.
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
If ddx does not support swap, don't advertise it. This is a hack to
work around current xservers which advertise this extension even when it
is clearly not supported. When:
http://lists.x.org/archives/xorg-devel/2013-February/035449.html
is merged in upstream xserver and makes it's way into most distros then
this hack can be removed. In the mean time, it is required to allow
gnome-shell/clutter/etc to work properly with a DDX driver which does
not support ScheduleSwap.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This debug flag prints out the native GEN assembly for a blitting
shader produced using BLORP. Hopefully this should be useful in
developing additional BLORP features.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Needs to be set for depth, stencil, and fmask just
like other blocks.
v2: drop additional cayman bits for now
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On cayman, 128bpp surfaces require non_disp ordering for hw
access to both linear and tiled surfaces. When we use the 3D
engine we can set the non_disp ordering on both the tiled and
linear sides (via CB or texture), but when we use the DMA
engine, we can only set the non_disp ordering on the tiled
side, so after a L2T operation with the DMA engine, the data
ends up in the wrong order on the tiled side.
v2: cayman/TN only
v3: fix comments
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=60802
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The only format returned by _mesa_get_format_base_format() that
satisfies _mesa_is_depthstencil_format() is GL_DEPTH_STENCIL, so we
can simplify the check.
Reviewed-by: Eric Anholt <eric@anholt.net>
Fast depth clears have the same depth/stencil alignment requirements
as other drawing operations. Therefore, we need to call
brw_workaround_depthstencil_alignment() from both the clear and
drawing paths.
Without this fix, we get image corruption if the following conditions
hold: (a) the first ever drawing operation to a depth miplevel (or the
first drawing operation after having used the texture for sampling) is
a clear, (b) the depth miplevel has a size that is eligible for fast
depth clears, and (c) the depth miplevel has an offset within the
miptree that isn't 8x8 aligned.
Fixes piglit "depthstencil-render-miplevels" tests with size 273.
NOTE: This is a candidate for stable branches
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch makes the following search-and-replace changes:
gl_frag_attrib -> gl_varying_slot
FRAG_ATTRIB_* -> VARYING_SLOT_*
FRAG_BIT_* -> VARYING_BIT_*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function. But we still need to be able to detect when a given vertex
output has no corresponding fragment input. So it is replaced by a
new function, _mesa_varying_slot_in_fs(), which tells whether the
given varying slot exists as an FS input or not.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
This patch makes the following search-and-replace changes:
gl_geom_result -> gl_varying_slot
GEOM_RESULT_* -> VARYING_SLOT_*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
This patch makes the following search-and-replace changes:
gl_geom_attrib -> gl_varying_slot
GEOM_ATTRIB_* -> VARYING_SLOT_*
GEOM_BIT_* -> VARYING_BIT_*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
This patch makes the following search-and-replace changes:
gl_vert_result -> gl_varying_slot
VERT_RESULT_* -> VARYING_SLOT_*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
Future patches will make use of the enum. It will eventually take the
place of the existing enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib, all of which represent essentially
the same information but using inconsistent values.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
This patch updates the bitfields brw_context::wm.input_size_masks,
tracker::size_masks, and brw_wm_prog_key::proj_attrib_mask, all of
which are indexed by gl_frag_attrib, from 32-bit to 64-bit.
This paves the way for supporting geometry shaders, and for merging
the gl_frag_attrib and gl_vert_result enums. The combination of these
two will require at least 55 bits in the bitfields.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Brian Paul <brianp@vmware.com>
This involved adding another driOptionCache to dri_screen. The
existing one just held the default values. But now we also need
to have the values from the DRI config file so that we can get at
the always_have_depth_buffer config option, which is per-screen.
This option is needed for some applications that neglect to request
a depth buffer when choosing a visual/fbconfig.
The Linux app Topogun is an example of this problem.
There were two different NUM_ENTRIES #defines for the framebuffer
tile cache and the texture tile cache. Rename the later to fix
the warnings:
In file included from sp_flush.c:40:0:
sp_tex_tile_cache.h:76:0: warning: "NUM_ENTRIES" redefined
sp_tile_cache.h:78:0: note: this is the location of the previous definition
In file included from sp_context.c:50:0:
sp_tex_tile_cache.h:76:0: warning: "NUM_ENTRIES" redefined
sp_tile_cache.h:78:0: note: this is the location of the previous definition
Also, replace occurances of NUM_ENTRIES with Element() macro to
be safer.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Untyped Atomic Operation messages are illegal for non-RAW formats. The
IVB hardware proceeds happily (after all, who cares what the format of the
surface is if you're doing untyped ops on it?), but later hardware
apparently doesn't. The simulator for gen7 does complain, though.
v2: Rebase against updates to previous patches. (by anholt)
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This is basically a copy and paste of gen7_create_constant_surface, but
with the parameters filled in to offer a simpler interface.
It will diverge shortly.
I didn't bother adding it to the vtable for now since shader time is only
exposed on Gen7+.
v2: Replace tabs in the new code (by anholt)
Add back dropped memset() and add a comment about HSW channel selects.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Haswell's "Data Cache" data port is a single unit, but split into two
SFIDs to allow for more message types without adding more bits in the
message descriptor.
Untyped Atomic Operations are now message 0010 in the second data cache
data port, rather than 6 in the first.
v2: Use the #defines from the previous commit. (by anholt)
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net> (v1)
We were sparsely using some of these message types, but I'll just fill
them all in now. It will be used for fixing shader_time on HSW.
v2: Add missing MEDIA_BLOCK_READ.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This avoids some snooping overhead between EUs processing separate shaders
(so VS versus FS).
Improves performance of a minecraft trace with shader_time by 28.9% +/-
18.3% (n=7), and performance of my old GLSL demo by 93.7% +/- 0.8% (n=4).
v2: Add a define for the stride with a comment explaining its units and
why.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
scons/llvm.py defines inline globally to workaround issues with LLVM C
binding headers, so the only way to is to avoid
aggravating xkeycheck.h errors is to set _ALLOW_KEYWORD_MACROS.
This fixes MSVC 2012 build with LLVM.
Reviewed-by: Brian Paul <brianp@vmware.com>
- each softpipe_tex_tile_cache 50*64*64*4*4 = 3,276,800 bytes
- each softpipe_context has 3*32 softpipe_tex_tile_cache, i.e, each softpipe
context is 314,572,800 bytes, i.e, 300MB
That is, in a 32bits process (around 3GB virtual memory max), we can
only fit 10 contexts.
This change is a short-term hack to shrink the context size. Longer
term we'll need to change how the texture cache works.
Reviewed-by: Brian Paul <brianp@vmware.com>
Framebuffer blitting operation should be skipped if any of the
dimensions (width/height) of src/dst rect is zero.
V2: Move the dimension check after error checking in _mesa_BlitFramebuffer.
Fixes: fbblit(negative.nullblit.zeroSize) in Intel oglconform
https://bugs.freedesktop.org/show_bug.cgi?id=59495
Note: Candidate for all the stable branches.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We can't handle them yet, however we can safely just warn (we will
just render to first layer, which is fine since we can't handle
rendertarget system value neither).
Also make behavior more predictable with buffer surfaces
(it would sometimes hit bogus asserts because of the union in the surface,
instead create the surface but assert when trying to set a buffer
in the framebuffer).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Just delete unused kernels rather than marking them as internal and
running the GlobalDCE pass.
Also implement this function in C and inline it into
radeon_llvm_get_kernel_module()
Actually use $DEFINES, so we can see if GLX_INDIRECT_RENDERING is defined
If GLX_INDIRECT_RENDERING is defined, _GLAPI_SKIP_PROTO_ENTRY_POINTS will
be defined, and libglapi won't contain the 'protocol entry points', so we
should provide stubs in check_table.cpp
It looks like this has been broken since commit
1a1db1746d "Standardize names of OpenGL
functions."
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Fixes this build error with make check.
CC collision.o
In file included from ../../../../../src/mesa/main/hash_table.h:34:0,
from collision.c:31:
../../../../../src/mesa/main/compiler.h:51:53: fatal error: c99_compat.h: No such file or directory
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
If geometry shader is present its stream output info should
be used instead of the vs and we shouldn't use the pre-clipped
corrdinates.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In cases where the vertex element size is smaller than the vertex buffer
stride, the previous calculation could end up 1 too low. This would result
in the GPU using index 0 instead of the maximum index for those elements,
which would be visible as intermittent distorted triangles.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
And remove non-working code for indirect sampler/resource selection.
Will be added back later.
Includes code from "nv50/ir/tgsi: Resource indirect indexing" by
Francisco Jerez (when mixing the R and S handles we can only specify
them via a register, i.e. indirectly, unless we upload all the used
handle combinations to c[] space, which we don't for now).
Squashed and (heavily) modified original patches by Francisco Jerez:
nv50/ir/tgsi: Implement resource LOAD/STORE (wip).
nv50/ir/tgsi: Emit SUST/SULD for surface access, and add CB LOAD/STORE support
nv50/ir/tgsi: Fix/clean up the LOAD/STORE handling code.
Left out for now:
nv50/ir/tgsi: Resource indirect indexing
Treating raw, read-only surfaces as constant buffers (CBs) was removed
because CBs are limited to a size of 64 KiB which isn't desireable, and
because this decision should probably be made by the state tracker.
If we used a number of CB slots for surfaces, it might find that we
cannot accomodate the advertised limit.
OpenGL is nice and makes the user specify a format with an image unit.
OpenCL is evil and doesn't, and what's better than adding a huge load
of functions that we call indirectly to handle the conversion ?
A live range [0, 0) counts as empty. For function inputs this can
be a problem, so insert a nop at the beginning to make it [0, 1).
This is a bit of a hack but also the most simple solution.
Currently works on a220. Others in the a2xx family look pretty similar
and should be pretty straightforward to support with the same driver.
The a3xx has a new shader ISA, and while many registers appear similar,
the register addresses have been completely shuffled around. I am not
sure yet whether it is best to support with the same driver, but
different compiler, or whether it should be split into a different
driver.
v1: original
v2: build file updates from review comments, and remove GPL licensed
header files from msm kernel
v3: smarter temp/pred register assignment, fix clear and depth/stencil
format issues, resource_transfer fixes, scissor fixes
Signed-off-by: Rob Clark <robdclark@gmail.com>
Previously, the derivatives were calculated and passed in a packed form
to the sample code (for implicit derivatives, explicit derivatives were
packed to the same format).
There's several reasons why this wasn't such a good idea:
1) the derivatives may not even be needed (not as bad as it sounds since
llvm will just throw the calculations needed for them away but still)
2) the special packing format really shouldn't be part of the sampler
interface
3) depending what the sample code actually does the derivatives will
be processed differently, hence there is no "ideal" packing. For cube
maps with explicit derivatives (which we don't do yet) for instance the
packing looked downright useless, and for non-isotropic filtering we'd
need different calculations too.
So, instead just pass the derivatives as is (for explicit derivatives),
or let the rho calculating sample code calculate them itself. This still
does exactly the same packing stuff for implicit derivatives for now,
though explicit ones are handled in a more straightforward manner (quick
estimates show performance should be quite similar, though it is much
easier to follow and also does the rho calculation per-pixel until the
end, which we eventually need for spec compliance anyway).
No piglit changes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
After the previous fix that almost removes an allocation of 4*n^2
bytes, we can use a bitset to reduce another allocation from n^2 bytes
to n^2/8 bytes.
Between the previous commit and this one, the peak heap size for an
oglconform ARB_fragment_program max instructions test on i965 goes from
4GB to 255MB.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55825
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were allocating an adjacency_list entry for every possible
interference that could get created, but that usually doesn't happen.
We can save a lot of memory by resizing the array on demand.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We're already walking the list, and we can easily know when something
has no reason to be in the list any longer, so take a brief extra step
to reduce our worst-case runtime (an oglconform test that emits the
maximum instructions in a fragment program). I don't actually know what
the worst-case runtime was, because it was too long and I got bored.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We can execute way fewer instructions by doing our boolean manipulation
on an "int" of bits at a time, while also reducing our working set size.
Reduces compile time of L4D2's slowest shader from 4s to 1.1s
(-72.4% +/- 0.2%, n=10)
v2: Remove redundant masking (noted by Ken)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were handling the the dependency workaround for the first written reg
of a send preceding the one we're fixing up, but didn't consider the other
regs. Thus if you had two sampler calls that got allocated to the same
set of regs, one might, rarely, ovewrite the other. This was occurring in
XBMC's GLSL shaders.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44567
NOTE: This is a candidate for the stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When forcing the compiler to always generate pull constants instead of
push constants (in order to have an easy to use testcase), improves
performance of my old GLSL demo 23.3553% +/- 1.42968% (n=7).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60866
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The lowering process creates a new vgrf on gen7 that should be represented
in live interval analysis. As-is, it was getting a conflicting allocation
with gl_FragDepth in the dolphin emulator, producing broken rendering.
NOTE: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61317
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I was going to fix the code above like the previous commit, but we already
had that covered (otherwise all our uniform access would have been broken,
unlike just pull constants).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were allowing a compressed instruction to write a register that
contained the last use of a uniform pull constant (either UBO load or push
constant spillover), so it would get half its values smashed.
Since we need to see the actual instruction to decide this, move the
pre-gen6 pixel_x/y logic here, which should improve the performance of
register allocation since virtual_grf_interferes() is called more than
once per instruction.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61317
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
I was looking at the list to see what might be interesting to document for
application developers, and it turns out some are completely dead.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were assuming that each emitted primitive had the same
number of vertices. That is incorrect. Emitted primitives
can have arbirtrary number of vertices. Simply increment
index on iteration to fix it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Whenever we're binding the shaders we're incrementing NumOutputs,
assuming the parser spots an output decleration, but we were never
reseting the variable. That means that each subsequent bind of
a geometry shader would add its number of output to the number
of output bound by all previously ran shaders and our indexes
would get completely messed up.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This is needed for handling the dx10-style sample opcodes.
This also simplifies the logic by getting rid of sampler variants
completely (sampler_views though OTOH have sort of variants because
some of their state is different depending on the shader stage they
are bound to).
No significant performance difference (openarena run:
840 frames in 459.8 seconds vs. 840 frames in 460.5 seconds).
v2: fix reference counting bug spotted by Jose.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Can handle them since the single sampler interface was introduced.
v2: simplify txf/sample_i handling a bit according to Brian's feedback.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Only the disassembler is used to dump shaders. Here's a few examples
how to use R600_DEBUG.
Log compute info:
R600_DEBUG=compute
Dump all shaders:
R600_DEBUG=fs,vs,gs,ps,cs
Dump pixel shaders only:
R600_DEBUG=ps
Disable Hyper-Z:
R600_DEBUG=nohyperz
Disable the LLVM backend:
R600_DEBUG=nollvm
Or use any combination of the above, or print all options:
R600_DEBUG=help
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Commit 67ef7559 added an || test "x$enable_dri" check in an attempt to
get the DRI common bits built in some necessary cases. That change was
inappropriate as it made these common DRI pieces be built
unconditionally, so some builds were broken.
Subsequently, commit 998d975e3 change the "|| test" to a "-a"
conjunction within the existing test invocation. This made the '-a
"x$enable_dri" = xyes' clause have no effect, (as it was inside an
enclosing test for the same condition). So the new breakage from
commit 67ef7559 was addressed, but the original problems were
regressed.
The immediately preceding commit removed the redundant condition.
Now, finally this commit fixes the original problem as described in
the commit message of 67ef7559: this code should be compiled when
using the DRI state tracker. In order to do so, the HAVE_*_DRI
conditionals must be moved after the last assignment of HAVE_COMMON_DRI.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61821
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
It fails on 32-bit systems (I only tested on 64-bit). Power of two
size isn't required, so just remove the assertion.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This fixes a crash when a display list is created in one context
but executed from a second one. The vbo_save_context::vertex_store
memeber will be NULL if we never created a display list with the
context. Just check for that before dereferencing the pointer.
Fixes http://bugzilla.redhat.com/show_bug.cgi?id=918661
Note: This is a candidate for the stable branches.
If the sampler object has been deleted on another context, an
alternative context may reference the old sampler. So ensure the sampler
object still exists.
Note: this is a candidate for the stable branch.
Signed-off-by: Alan Hourihane <alanh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
LICM stands for Loop Invariant Code Motion. Instructions that
does not depend of loop index are moved outside of loop body.
DCE is DeadCodeElimination.
v2: updated commit msg, thx to Vincent.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Vincent Lejeune <vljn at ovi.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
We can't clip and viewport transform the vertices before we let
the geometry shader process them. Lets make sure the generated
vertex shader has both disabled if geometry shader is present.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The geometry shader code seems to have been originally written with the
assumptions that there are the same number of VS outputs as GS outputs and
that VS outputs are in the same order as their corresponding GS inputs. Since
TGSI uses separate shader objects, these are both wrong assumptions. This
was causing several valid vertex/geometry shader combinations to either render
incorrectly or trigger an assertion.
Conflicts:
src/gallium/auxiliary/draw/draw_gs.c
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This change specifically unbinds a sampler object from the texture unit
if it's bound to a unit. The spec calls for default object when deleting
sampler objects which are currently bound.
Note: this is a candidate for the stable branches
Signed-off-by: Alan Hourihane <alanh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
We advertise a max texture/surfaces size of 8K x 8K but the old values
for these limits didn't actually allow us to handle that surface size.
For 8K x 8K we'll have 16384 bins. Each bin needs at least one cmd_block
object which was 2192 bytes in size. Since 16384 * 2192 exceeded
LP_SCENE_MAX_SIZE we'd silently fail in lp_scene_new_data_block() and not
draw the complete scene.
By reducing CMD_BLOCK_MAX to 29 we get nice 512-byte cmd_blocks. And
by increasing LP_SCENE_MAX_SIZE to 9 MB we can allocate enough command
blocks for 8K x 8K, plus a few regular data blocks.
Fixes the (improved) piglit fbo-maxsize test.
Note: This is a candidate for the stable branches.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
This was only necessary because our bounds checking was off by one, and
thus we read an extra pair of values.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
If we've written N pairs of values to the buffer, then last_index = N,
but the values are 0 .. N-1. Thus, we need to use <, not <=.
This worked anyway because we fill the buffer with zeroes, so we just
added an extra (0 - 0) to our results.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
We were allowing things like copying RG1616 to a user's ARGB8888
format, while we were denying anything that wasn't ARGB8888 or
RGB565.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This is similar code to intel_miptree_copy_slice, but the knobs
are all set differently.
v2: fix whitespace
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I'm trying to move us away from the region structure, and all the
callers are currently dereferencing a miptree to get the region.
In this change, the map_refcount is dropped. However, the bo->virtual is
itself map refcounted, so that's already dealt with.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
The point of tracking the value was removed in February 2012
(65b096aedd), and this should have
been removed at the same time.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I don't see any reason for it -- it was introduced with the DRI2
invalidate work by krh in 2010 with no explanation. I suspect it was
something about wanting the same drm_intel_bo struct underneath multiple
openings of the BO within one process, but that's covered by libdrm at
this point. As far as the struct region goes, it is not threadsafe, so
multiple contexts sharing a region could have mixed up the map_count and
assertion failed or worse.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Several commits on master for the 9.1 branch had "NOTE" messages in a
slightly different format.
NOTE: This is a candidate for stable branches
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Now all the per-message enums from mtypes are gone. Now we can extend
unique message IDs into all generators of debug output without having to
update mtypes.h for each one.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This ends up reusing the dynamic ID support, so a silly enum gets to go
away. We don't assign good IDs to different messages yet, but at least
that's tractable now.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
I was testing the ARB_debug_output code and wrote an obvious sample that
should have hit this, and got confused that my ARB_debug_output was
broken.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
I tried to ensure that performance in the non-debug case doesn't change
(we still just check one condition up front), and I think the impact is
small enough in the debug context case to warrant including all of it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This doesn't provide detailed error type information, but it's important
to get these relatively severe but rare error messages out to the
developer through whatever mechanism they are using.
v2: Rebase on new WARN_ONCE additions.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
We can emit messages now without always having to use the same ID for
each, or having a giant table of all possible errors in mtypes.h.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
I want to have dynamic IDs so that we don't need to add to mtypes.h for
every error we might want to add. To do so, I need to get rid of the
static arrays and actually support all the crazy filtering of dynamic IDs
that we already support for application-provided error sources.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This was apparently not noticed because we don't have any testing of
application-generated debug output. However, as I'm changing the
GL-generated debug output to use the same path as
application/middleware-generated debug output, this obviously became an
issue.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These will get reused by new ARB_debug_output messages in drivers/core,
instead of having the caller pass GL enums and have us immediately
switch-statement those into enums.
Add source enums will be handled in the next commit, because the way
different sources are handled at the moment is pretty strange.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The new one doesn't have the same behavior for GL_NO_ERROR, but we don't
produce errors with GL_NO_ERROR as the error type.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This partly reverts 6ace2e41da.
Apparently with GL_MESA_texture_array fixed-function texturing
with texture arrays is possible, and hence we have to handle TXP.
(Though noone seems to know the semantics, softpipe now does what
it did before, which is to NOT project the array coord, llvmpipe
for instance however indeed does project the array coord. Unlike
before it will project the comparison coord for shadow1d array, as
that clearly was an error.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=61828.
Reviewed-by: Brian Paul <brianp@vmware.com>
X11 is already checked conditionally below.
Fixes OSMesa-only configurations to not require X11.
Note: This is a candidate for the 9.1 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
This was hit on the glTexStorage2D() path.
Note: this is a candidate for the stable branches
Signed-off-by: Alan Hourihane <alanh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The second digit was off by one, which meant we accidentally treated
GTn as GT(n-1). This also meant no support for GT1 at all.
NOTE: This is a candidate for stable branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
We'll want to reuse this for non-occlusion queries in the future.
Plus, it's a single logical task, so having it as a helper function
clarifies the code somewhat.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Again, eliminating a global variable in favor of a per-query object
variable will help in a future where we have more queries in hardware.
Personally, I find this clearer: there's just the query object's BO,
rather than two variables that usually shadow each other.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The code a few lines above calls brw_emit_query_begin() if !query->bo,
and that creates query->bo. So it should always be non-NULL.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
If we haven't allocated a BO yet, we need to do that. Or, if there
isn't enough room to write another pair of values, we need to gather up
the existing results and start a new one. This is simple enough.
However, the old code was awkwardly split into two blocks, with a
write_depth_count() placed in the middle. The new depth count isn't
relevant to gathering the old BO's data, so that can go after the
reallocation is done. With the two blocks adjacent, we can merge them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Since we already have an index in the brw_query_object, there's no need
to also keep a global variable that shadows it.
Plus, if we ever add support for more types of queries that still need
the per-batch before/after treatment we do for occlusion queries, we
won't be able to use a single global variable. In contrast, per-query
object variables will work fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
brw->query.index is initialized to 0 just a few lines before it's
copied to first_index.
Presumably the idea here was to reuse the query BO for subsequent
queries of the same type, but since that doesn't happen, there's no need
to have the extra code complexity.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This code was really difficult to follow, for a number of reasons:
- Queries were handled in four different ways (TIMESTAMP writes a single
value, TIME_ELAPSED writes a single pair of values, occlusion queries
write pairs of values for the start and end of each batch, and other
queries are done entirely in software. It turns out that there are
very good reasons each query is handled the way it is, but
insufficient comments explaining the rationale.
- It wasn't immediately obvious which functions were driver hooks
and which were helper functions. For example, brw_query_begin() is
a driver hook that implements glBeginQuery() for all query types, but
the similarly named brw_emit_query_begin() is a helper function that's
only relevant for occlusion queries.
Extra explanatory comments should save me and others from constantly
having to ask how this code works and why various query types are
handled differently.
v2: Incorporate Eric's feedback: change "as soon as possible" to "the
results will be present when mapped."
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
For timestamp queries, we just write a single value to a BO. The
natural place to write that is element 0, so we should do that.
Previously, we wrote it into element 1 (the second slot) leaving
element 0 filled with garbage.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
In OpenGL, most queries record statistics about operations performed
between a defined beginning and ending point. However, TIMESTAMP
queries are different: they immediately return a single value, and there
is no start/stop mechanism.
Previously, Mesa implemented TIMESTAMP queries by calling EndQuery
without first calling BeginQuery. Apparently this is DirectX
convention, and Gallium followed suit. I personally find the asymmetry
jarring, however---having BeginQuery and EndQuery handle a different set
of enum values looks like a bug. It's also a bit confusing to mix the
one-shot query with the start/stop model.
So, add a new QueryCounter driver hook for implementing TIMESTAMP. For
now, fall back to EndQuery to support drivers that don't do the new
mechanism.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Something I never got around to implement, but this is the tgsi execution
side for implementing texel offsets (for ordinary texturing) and explicit
derivatives for sampling (though I guess the ordering of the components
for the derivs parameters is debatable).
There is certainly a runtime cost associated with this.
Unless there are different interfaces used depending on the "complexity"
of the texture instructions, this is impossible to avoid.
Offsets are always active (I think checking if they are active or not is
probably not worth it since it should mostly be an add), whereas the
sampler_control is extended for explicit derivatives.
For now softpipe (the only user of this) just drops all those new values
on the floor (which is the part I never implemented...).
Additionally this also fixes (discovered by accident) inconsistent
projective divide for the comparison coord - the code did do the
projection for shadow2d targets, but not shadow1d ones. This also
drops checking for projection modifier on array targets, since they
aren't possible in any extension I know of (hence we don't actually
know if the array layer should also be divided or not).
Reviewed-by: Brian Paul <brianp@vmware.com>
Similar fix to what is done for the non-llvm case, we could otherwise still
hit the stages (near certainly with gs) which crash. It is probably a much
better idea to skip trying to draw at that point anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>
It seems easiest (and best) if we simply skip all the later stages
(after stream output).
(This is different to the llvm case at least for now where we will
simply try to render garbage, though both behaviors should be correct.)
Fixes piglit glsl-1.40-tf-no-position with softpipe.
Reviewed-by: Brian Paul <brianp@vmware.com>
With glsl 1.40 writing position is not required (useful for transform
feedback, though in fact it's still possible to rasterize such geometry
even if the results aren't too well defined).
Prevents crashes in that case. Fixes piglit glsl-1.40-tf-no-position.
Not quite sure this is 100% correct as it also skips clipdistance
clipping which could still work (but not sure if the result would
really be needed?)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com
Reviewed-by: Brian Paul <brianp@vmware.com>
Since c8eb2d0e82 llvmpipe checks if it's
actually legal to create a surface. The opengl state tracker doesn't quite
obey this so for now just warn instead of assert.
Also warn instead of disabled assert when creating sampler views
(same reasoning).
Addresses https://bugs.freedesktop.org/show_bug.cgi?id=61647.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
texel offsets should have been the last missing feature for 130, and in
fact 140 as well (last there were texture buffers). In any case we still
don't do OpenGL 3.0 (missing MSAA which will be difficult,
plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB).
v2: bump to 140 instead - we have everything except we crash when not writing
to gl_Position (but softpipe crashes as well) so let's just say this is a bug
instead. Also (by Dave Airlie's suggestion) update llvm-todo.txt.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This was previously only handled for texelFetch (much easier).
Depending on the wrap mode this works slightly differently (for somewhat
efficient implementation), hence have to do that separately in all roughly
137 places - it is easy if we use fixed point coords for wrapping, however
some wrapping modes are near impossible with fixed point (the repeat stuff)
hence we have to normalize the offsets if we can't do the wrapping in
unnormalized space (which is a division which is slow but should still be
much better than the alternative, which would be integer modulo for wrapping
which is just unusable). This should still give accurate results in all
cases that really matter, though it might be not quite conformant behavior
for some apis (but we have much worse problems there anyway even without
using offsets).
(Untested, no piglit test.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Even when we don't have LLVM since there's other C++ code
in the resulting DRI driver object.
Note: This is a candidate for the stable branches.
Reviewed-by: Matt Turner <mattst88@gmail.com>
The problem is that we mix bo handles and flinked names in the hash
table. Because kms type handles are not flinked they should not be
added to the hash table. If we do that we will sooner or later
get a situation where we will overwrite a correct entry because
the bo handle was the same as a flinked name.
Note: this is a candidate for the stable branches.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. We don't support CMS yet for multisample
textures, so we just hardcode MCS=0. This is ignored for IMS and UMS
surfaces.
Note: If we do end up emitting specialized shaders based on the MSAA
layout, we can emit a slightly shorter message here in the UMS case.
Note: According to the PRM, `ld2dms` takes one more parameter, lod.
However, it's always zero, and including it would make the message too
long for SIMD16, so we just omit it.
V2: Reworked completely, added support for Gen7.
V3: - Introduce sample_index parameter rather than reusing lod
- Removed spurious whitespace change
- Clarify commit message
V4: - Fix comment style
- Emit SHADER_OPCODE_TXF_MS on Gen6. This was benignly wrong since
it lowers to `ld` anyway on this gen, but still wrong.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
On Gen6, lower this to `ld` with lod=0 and an extra sample_index
parameter.
On Gen7, use `ld2dms`. This takes an additional MCS parameter to support
compressed multisample surfaces, but we're not enabling them for
multisample textures for now, so it's always ignored and can be safely
omitted.
V2: Reworked completely, added support for Gen7.
V3: - Use new sample_index, sample_index_type rather than reusing lod
- Clarify commit message.
V4: - Fix comment style
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is very similar to the TXF opcode, but lowers to `ld2dms` rather
than `ld` on Gen7.
V4: - add SHADER_OPCODE_TXF_MS to is_tex() functions, so regalloc thinks
it actually writes the correct number of registers. Otherwise in
nontrivial shaders some of the registers tend to get clobbered,
producing bad results.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Gen7 has an erratum affecting the ld_mcs message, making it unsafe to
use when the surface doesn't have an associated MCS.
From the Ivy Bridge PRM, Vol4 Part1 p77 ("MCS Enable"):
"If this field is disabled and the sampling engine <ld_mcs>
message is issued on this surface, the MCS surface may be
accessed. Software must ensure that the surface is defined
to avoid GTT errors."
To allow the shader to treat all surfaces uniformly, force UMS if the
surface is to be used as a multisample texture, even if CMS would have
been possible.
V3: - Quoted erratum text
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
The surface_state setup for renderbuffers already worked; only the
texturing side needed work. BLORP does something similar, but does its
own surface_state setup.
On Gen6, we just need to set the correct sample count.
On Gen7: - set the correct sample count
- set the correct layout mode
- set GEN7_SURFACE_ARYSPC_LOD0 if it's set in the miptree.
V2: - Clarify commit message
- Rebased onto Paul's physical/logical dims cleanup
- Added Gen7 support
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2: - Fix for state moving from texobj to image
- Rebased onto Paul's logical/physical cleanup
- Fixed missing quantization of sample count
- Fold in IMS renderbuffer wrapper fixes from later in the series
- Use correct physical slice offset for UMS/CMS surfaces on Gen7
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
V2: - fix formatting issues
- generate GL_OUT_OF_MEMORY if teximage cannot be allocated
- fix for state moving from texobj to image
V3: - remove ridiculous stencil hack
- alter format check to not allow a base format of STENCIL_INDEX
- allow width/height/depth to be zero, to deallocate the texture
- dont forget to call _mesa_update_fbo_texture
V4: - fix indentation
- don't throw errors on proxy texture targets
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
- sample count must be the same on all attachments
- fixedsamplepositions must be the same on all attachments
(renderbuffers have fixedsamplepositions=true implicitly; only
multisample textures can choose to have it false)
V2: - fix wrapping to 80 columns, debug message, fix for state moving
from texobj to image.
- stencil texturing tweaks tidied up and folded in here.
V3: - Removed silly stencil hacks entirely; the extension doesn't
actually make stencil-only textures legal at all.
- Moved sample count / fixed sample locations checks into
existing attachment-type-specific blocks, as suggested by Eric
V4: - Removed stencil hacks which were missed in V3 (thanks Eric)
- Don't move the declaration of texImg; only required pre-V3.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[V2] Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Moves the definition of the sample positions out of
gen6_emit_3dstate_multisample, and unpacks them in
gen6_get_sample_position.
V2: Be consistent about `sample position` rather than `location`.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
V2: - fix multiline comment style
- stop using ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH since that
doesn't exist anymore.
V3: - check for the extension being enabled
- tidier flagging of _NEW_MULTISAMPLE
- fix weird indentation in get.c
V4: - move flush later in SampleMaski()
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Actual sample locations deferred to a driverfunc since only the driver
really knows where they will be.
V2: - pass the draw buffer to the driverfunc; don't fallback to pixel
center if driverfunc is missing.
- rename GetSampleLocation to GetSamplePosition
- invert y sample position for winsys FBOs, at Paul's suggestion
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
- GL_MAX_COLOR_TEXTURE_SAMPLES
- GL_MAX_DEPTH_TEXTURE_SAMPLES
- GL_MAX_INTEGER_SAMPLES
V2: initialize limits to 1 in _mesa_init_constants as suggested by Brian
and Paul
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
V2: - emit `sample` parameter properly for multisample texelFetch()
- fix spurious whitespace change
- introduce a new opcode ir_txf_ms rather than overloading the
existing ir_txf further. This makes doing the right thing in
the driver somewhat simpler.
V3: - fix weird whitespace
V4: - don't forget to include the new opcode in tex_opcode_strs[]
(thanks Kenneth for spotting this)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[V2] Reviewed-by: Eric Anholt <eric@anholt.net>
[V2] Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Adds the new texture targets, and per-image state for GL_TEXTURE_SAMPLES
and GL_TEXTURE_FIXED_SAMPLE_LOCATIONS.
V2: - Allow multisample texture targets in glInvalidateTexSubImage too.
This was already partly there, but I missed it the first time around
since the interaction is defined in a newer extension. Fixed weird
indentation.
- Allow multisample array textures in glFramebufferTextureLayer.
This was overlooked as the tests originally only used 2d
multisample textures.
V3: - Set min/mag filters sensibly for multisample textures. This
can't actually be changed by the user, so it's more sensible to
initialize it correctly than to hack around it being bogus later.
V4: - Tidy up initial min/mag filter setup. Setup in
_mesa_initialize_texture_object was bogus, but benign since
finish_texture_init() clobbered everything with correct values. For V4,
just do the setup in finish_texture_init().
V5: - Don't break glPopAttrib(GL_TEXTURE_BIT)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[V2] Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Adds new enums, dispatch machinery, and stubs for the 4 new entrypoints.
V2: - Drop placeholder
- Align enum values
- Remove explicit exec=mesa; it *is* the dispatch flavor we want,
but it's also the default. I misunderstood how this worked before;
after actually reading the generator it makes good sense.
V3: - Squash in stubs for new entrypoints, and dispatch_sanity tweaks,
so we don't get build breakage between those patches.
V4: - Fix various remaining whitespace issues
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
[1/3 V2] Reviewed-by: Matt Turner <mattst88@gmail.com>
[V3] Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The GLX extension lets you expose visuals that explicitly guarantee you
that the GL_FRAMEBUFFER_SRGB_CAPABLE flag will be set, but we can set
the flag even while the visual doesn't provide the guarantee. This
appears to be consistent with other implementations, as we've seen
several apps now that don't require an srgb visual and assume sRGB will
work without checking the GL_FRAMEBUFFER_SRGB_CAPABLE flag.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55783
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60633
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Now that we have W-tiled S8, we can't just region_map and poke at bits --
there has to be some swizzling. Rely on intel_miptree_map to get that job
done. This should also get the highest performance path we know of for the
mapping (interesting if I get around to finishing movntdqa some day).
v2: Fix stale name of the bit in a comment.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I want to reuse intel_miptree_map() to replace some region mapping that's
broken for separate stencil, but doing so would result in new demands on
ETC transcode that we actually don't want to happen.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Any driver can implement this simple and efficient optimization.
Team Fortress 2 hits it always. The DISCARD_RANGE codepath is not even used
with TF2 anymore, so we avoid a ton of useless buffer copies.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
v2: cosmetic changes based on Brian's review
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
NOTE: This is a candidate for the 9.1 branch. (the next patch depends on it)
The states were split because we thought it caused a hardlock. Now we know
the hardlock was caused by something else and has since been fixed.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
This doesn't fix any issue we know of, but there indeed is a week spot
in draw_vbo where streamout can fail. After streamout is enabled,
the need_cs_space call can flush the context, which causes the streamout
to be disabled right after it was enabled and bad things happen.
One way to fix it is to atomize the beginning part, so that no context flush
can happen between streamout enabling and the first drawing.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Without this set, dri_util.c:dri2CreateContextAttribs
will reject requests to create a context with
__DRI_API_OPENGL_CORE.
This prevents a 3.2 core profile context from being created
even when MESA_GL_OVERRIDE_VERSION=3.2 is used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the override is version is >= 3.1, then update the
max_gl_core_version. Otherwise, update max_gl_compat_version.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow other code to get access to the override
version before a context is available.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Although GLSL 1.50 compiler support is not available,
this change will allow MESA_GLSL_VERSION_OVERRIDE=150 to be
used while 1.50 support is being developed.
Since no drivers claim 1.50 GLSL support, this change should
only impact Mesa when MESA_GLSL_VERSION_OVERRIDE=150 is set.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Immediate operands can only be src2 in 2-source instructions. Fixes
piglit failures since 0a1d145e (oops!).
Spotted-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The field was equivalent to (etc_format != MESA_FORMAT_NONE), and
therefore duplicate information.
This patch removes field and replaces all references to it with
`etc_format != MESA_FORMAT_NONE`.
No Piglit ETC test regresses on Intel Sandybridge.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
v2 [mattst88]:
- Add BRW_OPCODE_LRP to list of CSE-able expressions.
- Fix op_var[] array size.
- Rename arguments to emit_lrp to (x, y, a) to clear confusion.
- Add LRP function to brw_fs.cpp/.h.
- Corrected comment about LRP instruction arguments in emit_lrp.
v3 [mattst88]:
- Duplicate MAD code for LRP instead of using a function pointer.
- Check for != GRF instead of == IMM in emit_lrp.
- Lower LRP on gen < 6.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
1
Many GPUs have an instruction to do linear interpolation which is more
efficient than simply performing the algebra necessary (two multiplies,
an add, and a subtract).
Pattern matching or peepholing this is more desirable, but can be
tricky. By using an opcode, we can at least make shaders which use the
mix() built-in get the more efficient behavior.
Currently, all consumers lower ir_triop_lrp. Subsequent patches will
actually generate different code.
v2 [mattst88]:
- Add LRP_TO_ARITH flag to ir_to_mesa.cpp. Will be removed in a
subsequent patch and ir_triop_lrp translated directly.
v3 [mattst88]:
- Move changes from the next patch to opt_algebraic.cpp to accept
3-src operations.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we had separate constructors for one, two, and four operand
expressions. This patch consolidates them into a single constructor
which uses NULL default parameters.
The unary and binary operator constructors had assertions to verify that
the caller supplied the correct number of operands for the expression,
but the four-operand version did not. Since get_num_operands for
ir_quadop_vector returns the number of vector_elements, we can safely
add that without breaking the semantics of ir_quadop_vector.
This also paves the way for expressions with three operands. Currently,
none can be constructed since get_num_operands() never returns 3.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
total instructions in shared programs: 346873 -> 346847 (-0.01%)
instructions in affected programs: 364 -> 338 (-7.14%)
(All affected shaders are from Lightsmark)
Reviewed-by: Eric Anholt <eric@anholt.net>
Gen6 has write-only MRF registers, and for ease of implementation we
paritition off 16 general purposes registers to act as MRFs on Gen7.
Knowing that our Gen7 MRFs are actually GRFs, we can do things we can't
do with real MRFs:
- read from them;
- return values directly to them from a send instruction; and
- compute directly to them with math instructions.
Reviewed-by: Eric Anholt <eric@anholt.net>
This requirement was added by ARB_fragment_program
When the Steam overlay is enabled, this fixes:
* Menu corruption with the Puddle game
* The screen going black on Rochard when
the Steam overlay is accessed
NOTE: This is a candidate for the 9.0 and 9.1 branches.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Motivated by wanting to see if GenTextures was called by an
application while debugging another Steam overlay issue.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Now that buffers can be used as textures or render targets
make sure they aren't skipped.
Fix suggested by Jose Fonseca.
v2: added a couple of assertions so we can actually guarantee
we check the resources and don't skip them. Also added some comments
that this is actually a lie due to the way the opengl buffer api works.
Unfortunately not usable from OpenGL, and no cap bit.
Pretty similar to a 1d texture, though allows specifying a start element.
v2: also fix up renderbuffer width (which will get promoted to fb width)
to be the number of elements
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For PIPE_BUFFER we need coord adjustments for the transfer.
And for pure integer formats util_pack_color just crashes,
need to handle that differently due to clear colors being ints/uints.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Use a single sampler adapter instead of per-sampler-unit samplers,
and just pass along texture unit and sampler unit in the calls.
The reason is that for dx10-style sample opcodes pre-wired
samplers including all the texture state aren't really feasible (and for
sample_i/sviewinfo we don't even have samplers).
Of course right now softpipe doesn't actually do anything more than
just look up all its pre-wired per-texunit/per-samplerunit sampler as
it did before so this doesn't really achieve much except one more
function call, however this is now all softpipe's fault (fixing that in
a way which doesn't suck is still an unsolved problem).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
glXCreateWindow() and glXCreatePbuffer() always fail when built without
GLX_DIRECT_RENDERING defined since commit 48331047.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Normally the application will own the main event queue and be responsible
for moving events. In case of EGL_DEFAULT_DISPLAY, EGL opens the display
and has to own the main queue so it can move the events itself.
Call wl_display_dispatch_pending() to take ownership.
Previously only the 32-bit X visual would match the 32-bit RGBA8888
configs. This resulted in every config with alpha getting the "magic"
visual whose alpha is used by the compositor. This also resulted in no
multisample visuals being advertised. How many ways could we lose?
This patch inverts the problem... now you can't get the visual with
alpha used by the compositor even if you want it. I think we need to
invent a new value for EGL_TRANSPARENT_TYPE that apps can use to get
this. I'm surprised that there isn't already a choice for
EGL_TRANSPARENT_ALPHA.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Tian Ye <yex.tian@intel.com>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59783
Streamout buffers need to be synchronized on r6xx as
well.
v2: Add DEST flush as well.
v3: drop DEST flush
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Since with llvm execution parts of sampler view and sampler state is baked into
the shader, we need to revalidate otherwise the wrong shader might get used.
(Not completely sure but I think this would not be required for non-llvm case,
along with everything else in these functions.)
This caused bugs in piglit arb_texture_buffer_object-formats, because we never
noticed that the view format changed.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This also fixes not honoring first/last_layer view parameters for array
textures, plus not honoring last_level view parameter for all textures
(neither is really used by OpenGL).
This mostly passes piglit arb_texture_buffer_object tests (it needs, however,
glsl 140 version override, plus GL 3.1 override, the latter only because
mesa does not allow ARB_tbo in non-core contexts).
Most arb_texture_buffer_object tests pass, with the exception of
arb_texture_buffer_object-formats. With "arb" parameter it passes most weirdo
formats before it segfaults in the state tracker, this looks to be some issue
with using legacy formats in core context (fails the same in softpipe).
With "core" parameter it passes with "fs", however fails with "vs" (for most
formats). This will be fixed later (debugging shows we're completely missing
the shader recompile depending on format).
v2: based on Jose's feedback, fix comments, variable/function names.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
When you didn't have a texcoord array bound (or a non-1 current w
attrib), we were telling the fragment shader that it could just use "1"
instead of doing expensive pre-gen6 math to invert it. If you drew the
point with a non-1 W value, then you'd get the right size (since all the
vertex computations worked), but we'd mis-interpolate the coordinate
across the face.
Fixes the mesa pointsprite demo on GM45.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30232
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Note: This is a candidate for the stable branches.
missing case GL_REQUIRED_TEXTURE_IMAGE_UNITS_OES is required
by OES_EGL_image_external extension.
Note: This is a candidate for the stable branches.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Previously when an input varying was optimized out of the
FS we would still retain it as an output of the VS.
We now build a hash of live FS input varyings rather
than looking in the FS symbol table. (The FS symbol table
will still contain the optimized out varyings.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We might want to revisit the normalized_coords semantics, but this is
the current expected behavior.
Fixes fdo bug 61091.
Reviewed-by: Brian Paul <brianp@vmware.com>
The llvm pipeline handles regular filled triangle offsets, but it
doesn't handle offsets for triangles drawn in point or line mode.
Fixes failures found with new piglit polygon-mode-offset test.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
There were several issues. We weren't handling different front/back
polygon fill modes. We weren't checking whether the offset applied to
fill mode vs. line mode vs. point mode.
Fixes problems found with the Visualization Toolkit (VTK) test suite.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The old logic was kind of twisted, but seemed to work in practice.
Note: This is a candidate for the stable branches.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
When we destroy an ARB vp/fp whose ID was gen'd but not otherwise used we
get a pointer to the dummy/placeholder program. We can't destroy that one
so just skip it. This only failed during context tear-down because
glDeleteProgramsARB() was already aware of dummy programs.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38086
Note: This is a candidate for the stable branches.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
We sometimes convert GL_QUAD_STRIP prims into GL_TRIANGLE_STRIP, but
that changes the results of the u_trim_pipe_prim() call. We need to
pass the original primitive type to the trim function.
Note that OpenGL's GL_x prim type values match Gallium's PIPE_PRIM_x values.
Fixes a failure in the new piglit degenerate-prims test.
Note: This is a candidate for the stable branches.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
So we don't emit it twice if we ever use the flag on
cayman.
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PS_PARTIAL flushes seems to be required in certain
cases to prevent hangs, especially on r6xx.
Note: this is a candidate for the 9.1 branch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Regardless of what we put in the screen structure, all of the extensions
that compute_version_es2 checks are present and 3.0 will be exposed
anyway.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Commit 86d30dea3c broke building with older
automake versions with this error:
Makefile:769: *** Recursive variable am__v_YACC_ references itself (eventually). Stop.
This patch fixes it. Fix stolen from xorg-macros.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
The recent change for GL core broke the older setup, which broke
gl_PointCoord on pre-gen6 (where gl_PointCoord is undefined if point
sprites are disabled). Fixes the new piglit GLES-2.0/glsl-fs-pointcoord
test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32429
Note: This is a candidate for the stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In a debug build this led to assertion failures, but on a non-debug
build the hardware would just reference the whole vec8 instead of the
same channel 8 times.
Fixes the new piglit glsl-1.40/uniform-buffer/fs-exp2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57121
Note: This is a candidate for the stable branches
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- zero temps/outputs instead of copying (otherwise we won't be able to see
the temps/outputs assignments for small shaders where nothing changes
across big areas
- also show the inputs (as it's often impossible to infer from the rest)
Reviewed-by: Brian Paul <brianp@vmware.com>
Mesa state tracker recently started using PIPE_FORMAT_X8B8G8R8_UNORM,
causing segfaults in texture-packed-formats, because swizze[chan] was
0xff for padding channel (X).
Signed-off-by: José Fonseca <jfonseca@vmware.com>
Now with buffer formats clarification don't need all that logic any longer.
(Note that it never would have worked in any case, because blockwidth and
blockheight were swapped any allocation with multi-byte format would have
had zero size.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This clarifies some things and gets rid of some old stuff.
The most significant one is probably that buffers cannot have formats
(nearly all drivers completely ignored format and used width0 as byte size
already in any case). There seems to be no use case for "structured" buffers.
(Note while d3d11 has new Structured Buffers, these still aren't associated
with a format, rather a byte stride, which we can't do yet either way.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Some parts calculated key size by using shader information, others by using
the pipe_vertex_element information. Since it is perfectly valid to have more
vertex_elements set than the vertex shader is using those may not be the same,
so we weren't copying over all vertex_element state - this caused the tgsi dump
to assert (iterates over all vertex elements). More importantly in this
situation it would also break vertex texturing completely (since the sampler
state derived from the key is at a different position than expected).
Fix thix by deriving key->nr_vertex_elements from the shader information
instead of the pipe_vertex_element state (unlike dx10, we can't have "holes"
in pipe_vertex_element state, so this should be safe).
(Note that actual llvm shader generation does not use the pipe_vertex_element
state from the key itself in any case (althogh I guess it could) but uses
the one from draw.pt (which should be the same though contains all elements)
instead.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The OMOD value was only being folded to one instruction in cases where
the MUL instruction was reading a value written by more than one
instruction.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Now you can convert assembly strings into a full struct radeon_compiler
object and use it to test individual compiler pases.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
This way make check can report whether or not the tests pass.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
These are all files that I authored, but forgot to add the license
headers.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Tom Stellard <thomas.stellard@amd.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
This fixes a bug introduced in commit 258453716f and
triggered whenever "rb" is NULL.
Fixes at least one cause bug #59445:
[SNB/IVB/HSW Bisected]Oglc draw-buffers2(advanced.blending.none) segfault
https://bugs.freedesktop.org/show_bug.cgi?id=59445
(Though segfaults are still possible in that test case, but they have been
present since before commit 258453716f which is what's being fixed here.)
Reviewed-by: Eric Anholt <eric@anholt.net>
It's the reciprocal of the register value.
Fixes piglit fragcoord_w and glsl-fs-fragcoord-zw-perspective.
NOTE: This is a candidate for the 9.1 branch.
Requires corresponding LLVM R600 backend fix to work correctly, but even
without that it doesn't hang anymore.
13 more little piglits.
Depends on LLVM: r175193, r175733
NOTE: This is a candidate for the 9.1 branch.
Pre-Gen6, the SF thread requires exact matching between VS output
slots (aka VUE slots) and FS input slots, even when the corresponding
VS output slot is unused due to being overwritten by point coordinate
replacement (glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE)).
As a result, we have a special hack in the VS to ensure when any
texture coordinate is subject to point coordinate replacement, it is
always allocated space in the VUE, even if it isn't written to by the
VS.
This hack isn't needed from Gen6 onwards, since SF (Gen7: SBE)
swizzling has the ability to insert the point coordinate into
gl_TexCoord[] without needing a corresponding unused VUE slot.
Note that no modification of SF setup code is required for this
patch--get_attr_override() already does the right thing. However, we
make a slight comment change to clarify why this works.
In addition to eliminating unnecessary VS recompiles and saving
precious URB space on Gen6+, this will save us the trouble of having
to adjust this hack when we implement geometry shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For constant and temporary register fetches, the bitcasts weren't done
correctly for the indirect case, leading to crashes due to type mismatches.
Simply do the bitcasts after fetching (much simpler than fixing up the load
pointer for the various cases).
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=61036
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
We don't need to flush resources for each layer, and since we don't actually
care about layer at all in the flush function just drop the parameter.
Also we can use util_copy_box instead of repeated util_copy_rect.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These used to be illegal a very long time ago, then for some more time
nothing really emitted these so this code path wasn't hit.
Just trivially iterate over box->depth.
(Might be worth refactoring at some point since nowadays all the code
doesn't really do much except for depth textures.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=61093
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This patch implements a stub for GL_EXT_discard_framebuffer with
required checks listed by the extension specification. This extension
is required by GLBenchmark 2.5 when compiled with OpenGL ES 2.0
as the rendering backend.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
Only compile tested, but should fix at least some piglit fbo-blending tests.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
That means we can map and read multiple slices with one transfer_map call.
[ Cherry-picked from r600g commit 1aebb6911e ]
11 more little piglits on master, 1 more on the 9.1 branch (Marek's
glTex(Sub)Image improvements on master broke the other 10).
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
GLX_INTEL_swap_event is broken on the server side, where it's
currently unconditionally enabled. This completely breaks
systems running on drivers which don't support that extension.
There's no way to test for its presence on this side, so instead
of disabling it uncondtionally, just disable it for drivers
which are known to not support it. It makes sense because
most drivers do support it right now.
We'll be able to remove this once Xserver properly advertises
GLX_INTEL_swap_event.
Note: This is a candidate for stable branch branches.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60052
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Improves on a major performance regression for the dolphin wii emulator
from its move to using UBOs. Performance in the UBO codepath (as
replayed through apitrace) is up 21.1% +/- 2.3% (n=26/29).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We could potentially do some CSE even when the dst types aren't the same
on gen6 where there is no implicit dst type conversion iirc, or in the
case of uniform pull constant loads where the dst type doesn't impact
what's stored. But it's not worth worrying about.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for the 9.1 branch.
This should fix the register allocation explosion on the GLES 3.0 test
on gen6. It also gives us an instruction that will fit our CSE handling.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for the 9.1 branch.
We were correctly relaying the smear from MOV's src, but if the MOV
didn't do a smear, we don't want to smash the smear value from the
instruction being propagated into. Prevents a regression in the
upcoming UBO change.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for the 9.1 branch.
brw_vs_prog_data::userclip hasn't been used since commit f0cecd4
(i965: Move VUE map computation to once at VS compile time).
brw_gs_prog_key::userclip_active hasn't been used since commit 9f3d321
(i965: Make the userclip flag for the VUE map come from VS prog data).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Otherwise, the PBuffer's size was never set. This also initializes
the buffer size for windows, pixmaps, etc.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61012
Note: This is a candidate for the stable branches.
A single element in a GLX reply is contained in the header itself.
The number of elements is denoted in the "n" field of the reply.
If "n" is 1, the length of additional data is 0.
The XXX_data_length() function of xcb does not return the length of
the (optional, n>1) data but the number of elements.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=59876
Note: This is a candidate for the stable branches.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We weren't mapping the PBO when using the bitmap cache (but we had
the PBO code for the non-cache path.)
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61026
Note: This is a candidate for the stable branches.
This fixes a regression from ab74fee5e1.
When we use the clip coordinate to compute the screen-space interpolation
factor, we need to first apply the divide-by-W step to the clip
coordinate.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=60938
Note: This is a candidate for the 9.1 branch.
It has become a bit messy.
Changes:
- finally correct checking for transfer ops depending on the base format
- making sure the base internal format and the texture format match
(we were ignoring it, but it's important for correctness)
- the way-too-strict rule that both src and dst base formats must be the same
was dropped; ensuring the simpler and more permissive rule mentioned above
is enough
- stop using util_blit_pixels; pipe->blit is flexible enough, and now that we
have RGBX and red-alpha formats, pipe->blit can be used for more cases
Reviewed-by: Brian Paul <brianp@vmware.com>
A temporary texture is created such that it matches the format and type
combination and pixels are copied to it using memcpy. Then the blit is used to
copy the temporary texture to the texture image being modified by TexImage or
TexSubImage. The blit takes care of the format and type conversion and
swizzling. The result is a very fast texture upload involving as little CPU
as possible.
This improves performance in apps which upload textures during rendering.
An example is the Wine OpenGL backend for DirectDraw, which I used to test
the game StarCraft. Profiling had shown that TexSubImage was taking 50% of
CPU time without this patch, which was the main motivation for this work, and
now TexSubImage only takes 14% of CPU time. I had to underclock my CPU to see
any difference in the game and this patch does make the game a lot faster
if the CPU is slow (or using the powersave cpufreq profile).
Reviewed-by: Brian Paul <brianp@vmware.com>
This is not easy to hit, because we have 3 code paths now
(tried in this order):
- memcpy-based (skips the blit) -> _mesa_tex_getimage
- blit-based
- slow pixel packing -> _mesa_tex_getimage
The main difference later in the code is the parameters of
_mesa_image_address3d.
Reviewed-by: Brian Paul <brianp@vmware.com>
Based on r600g commit 2b9659c9e6 .
Fixes crashes with 4 piglit tests which are now hitting these formats.
NOTE: This is a candidate for the 9.1 branch.
_mesa_delete_renderbuffer does not call the driver-specific
renderbuffer delete function, so the blorp code was leaking the
Intel-specific bits, including some GEM objects.
Call the renderbuffer's ->Delete() method instead, which does the
right thing.
Fixes Unity rapidly sending the machine into the arms of the OOM-killer
Note: This is a candidate for the 9.1 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
We need to encode them as Texture instructions since the NumOffsets field
is encoded there. However, we don't encode the actual target in there, this
is derived from the sampler view src later.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
v2: don't allow all modifiers on all type, in particular don't allow
absolute on non-float types and don't allow negate on unsigned.
Also treat UADD as signed (despite the name) since it is used
for handling both signed and unsigned integer arguments and otherwise
modifiers don't work.
Also add tgsi docs clarifying this.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The emulation of these if there's no rounding instruction available
is a bit more complicated than what the code did.
In particular, doing fp-to-int/int-to-fp will not work if the exponent
is large enough (and with NaNs, Infs). Hence such values need to be filtered
out and the original value returned in this case (which fortunately should
always be exact). This comes at the expense of performance (if your cpu
doesn't support rounding instructions).
Furthermore, floor/ifloor/ceil/iceil were affected by precision issues for
values near negative (for floor) or positive (for ceil) zero, fix that as well
(fixing this issue might not actually be slower except for ceil/iceil if the
type is not signed which is probably rare - note iceil has no callers left
in any case).
Also add some new rounding test values in lp_test_arit to actually test
for that stuff (which previously would have failed without sse41).
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=59701.
To help catch mixed up context pointer bugs in the future, add a
trace_context_check() function and some new assertions.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
When a trace_surface object is created in trace_surf_create() we
weren't correctly setting the surface's context pointer. Instead of
it being the trace context, it was the wrapped driver's context.
This caused things to blow up sometimes during surface deallocation.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The GL_ARB_texture_rg spec says that we need to support both texturing
and rendering for the GL_RED and GL_RG formats. So move the format
check up into the rendertarget_mapping[] list. Also, add
PIPE_FORMAT_R8_UNORM to the list of formats required.
Note: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
We'd been ad-hoc inserting instructions in some SEND messages with no
knowledge of when it was required (so extra instructions), but not all SENDs
(so not often enough). This should do much better than that, though it's
still flow-control-ignorant.
v2: Use BRW_MAX_MRF instead of magic numbers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58960
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: Candidate for the stable branches.
In GLSL, sampler indices are allocated contiguously from 0. But in the
case of ARB_fragment_program (and possibly fixed function), an app that
uses texture 0 and 2 will use sampler indices 0 and 2, so we were only
allocating space for samplers 0 and 1 and setting up sampler 0. We
would read garbage for sampler 2, resulting in flickering textures and
an angry simulator.
Fixes bad rendering in 0 A.D. and ETQW. This was fixed for pre-gen7 by
28f4be9eb9
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25201
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58680
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable branches.
I should say "fix", but it has never been used until now.
S8Z24 is the format equivalent to the GL_UNSIGNED_INT_24_8 packing,
so we'll start to see it more often with st/mesa now making smart decisions
about formats.
The DB<->CB copy can change the channel ordering for transfers, other than
that, the internal DB format doesn't really matter.
R600-R700 support is possible except shadow mapping.
FMT_24_8 is broken if the SAMPLE_C instruction is used (no idea why).
Also the sampler swizzling was broken in theory and the fact it worked was
a lucky coincidence.
radeonsi might need to port this.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
The code was rather broken for non-XYZW on 8-wide, but all of our
callers were using XYZW anyway. For my experiments with using writemask
on texturing, I've been using manual header setup in the compiler
backends, since we want to actually know what registers are written for
optimization and register allocation.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Detect a duplicate Shader type as and error instead of silently allowing
it, restrict to ES2 API.
v2: Tapani Pälli <tapani.palli@intel.com>
- make the check run time instead of compile time
v3: chadv
- Quote spec on which error to generate.
Signed-off-by: bma <Bo.Ma@windriver.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
The hardware just doesn't support it. I suspect this was a regression from
the move to fixed MESA_FORMATs for compressed textures and that previously we
were storing uncompressed for this or something.
Fixes GPU hangs in piglit "texwrap GL_EXT_texture_sRGB-s3tc bordercolor
swizzled" on my GM965.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
language requiring certain integer variables to be declared with the
"flat" keyword, but they differ in exactly *when* the rule is
enforced:
(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
type must be declared as "flat". There is no restriction on fragment
shader inputs.
(b) GLSL 1.50 through 4.30 say that fragment shader inputs having
integral type must be declared as "flat". There is no restriction on
vertex shader outputs.
(c) GLSL ES 3.00 says that both vertex shader outputs and fragment
shader inputs having integral type must be declared as "flat".
Previously, Mesa's behaviour was consistent with (a). This patch
makes it consistent with (b) when compiling desktop shaders, and (c)
when compiling ES shaders.
Rationale for desktop shaders: once we add geometry shaders, (b) really
seems like the right choice, because it requires "flat" in just the
situations where it matters. Since we may want to extend geometry
shader support back before GLSL 1.50 (via ARB_geometry_shader4), it
seems sensible to apply this rule to all GLSL versions. Also, this
matches the behaviour of the nVidia proprietary driver for Linux, and
the expectations of Intel's oglconform test suite.
Rationale for ES shaders: since the behaviour specified in GLSL ES
3.00 matches neither pre-GLSL-1.50 nor post-GLSL-1.50 behaviour, it
seems likely that this was a deliberate choice on the part of the GLES
folks to be more restrictive. Also, the argument in favor of (b)
doesn't apply to GLES, since it doesn't support geometry shaders at
all.
Some discussion about this has already happened on the Mesa-dev list.
See:
http://lists.freedesktop.org/archives/mesa-dev/2013-February/034199.html
Fixes piglit tests:
- glsl-1.30/compiler/interpolation-qualifiers/nonflat-*.frag
- glsl-1.30/compiler/interpolation-qualifiers/vs-flat-int-0{2,3,4,5}.vert
- glsl-es-3.00/compiler/interpolation-qualifiers/varying-struct-nonflat-{int,uint}.frag
Fixes oglconform tests:
- glsl-q-inperpol negative.fragin.{int,uint,ivec,uvec}
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
In the GLSL 1.30 spec, section 4.3.6 ("Outputs") says:
"If a vertex output is a signed or unsigned integer or integer
vector, then it must be qualified with the interpolation qualifier
flat."
The GLSL ES 3.00 spec further clarifies, in section 4.3.6 ("Output
Variables"):
"Vertex shader outputs that are, *or contain*, signed or unsigned
integers or integer vectors must be qualified with the
interpolation qualifier flat."
(Emphasis mine.)
The language in the GLSL ES 3.00 spec is clearly correct and should be
applied to all shading language versions, since varyings that contain
ints can't be interpolated, regardless of which shading language
version is in use.
(Note that in GLSL 1.50 the restriction is changed to apply to
fragment shader inputs rather than vertex shader outputs, to
accommodate the fact that in the presence of geometry shaders, vertex
shader outputs are not necessarily interpolated. That will be
addressed by a future patch).
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
From GLSL ES 3.00 section 4.5.4 ("Default Precision Qualifiers"):
"The precision statement
precision precision-qualifier type;
can be used to establish a default precision qualifier. The type
field can be either int or float or any of the sampler types, and
the precision-qualifier can be lowp, mediump, or highp."
GLSL ES 1.00 has similar language. GLSL 1.30 doesn't allow precision
qualifiers on sampler types, but this seems like an oversight (since
the intention of including these in GLSL 1.30 is to allow
compatibility with ES shaders).
Previously, Mesa followed GLSL 1.30 and only allowed default precision
qualifiers to be set for float and int. This patch makes it follow
GLSL ES rules in all cases.
Fixes Piglit tests default-precision-sampler.{vert,frag}.
Partially addresses https://bugs.freedesktop.org/show_bug.cgi?id=60737.
NOTE: This is a candidate for stable branches.
Reviewed-by: Eric Anholt <eric@anholt.net>
Otherwise, we fail to correctly handle GL_PRIMITIVE_RESTART_FIXED_INDEX.
Fixes gles3conform's primitive_restart_mode test.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This commit allows using glGetTexImage during rendering and still
maintain interactive framerates.
This improves performance of WarCraft 3 under Wine. The framerate is improved
from 25 fps to 39 fps in the main menu, and from 0.5 fps to 32 fps in the game.
v2: fix choosing the format for decompression
This is for glGetTexImage and it will be used for samplers only (which some
drivers already implement by reading util_format_description).
v2: incorporate Brian's suggestion
Reviewed-by: Brian Paul <brianp@vmware.com>
Seems that alpha test being enabled confuse the GPU on the order in
which it should perform the Z testing. So force the order programmed
throught db shader control.
v2: Only force z order when alpha test is enabled
v3: Update db shader when binding new dsa + spelling fix
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
In OpenGL 4.3, new language was added that would require
this check. But, if this check results in broken applications
then perhaps it will be reversed.
For now, remove this check and re-evaluate when
desktop GL 4.3 is closer.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
With the llvm patches, fixing 14 piglit tests in total.
v2: increase the const limit
v3: document the const limit
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
When the user specifies an unsupported GLSL version,
_mesa_glsl_parse_state::process_version_directive() nicely gives them
an error message telling them which GLSL versions are supported.
Previous to this patch, the logic for determining whether a given
language version was supported was independent from the logic to
generate this error message string; as a result, we had a bug where
GLSL 3.00 would never be listed in the error message as an available
language version, even if it was really available.
To make matters worse, the code for generating the error message
string assumed that desktop GL versions were always separated by 0.10,
an assumption that will be wrong as soon as we support GLSL 3.30.
This patch fixes both problems by adding a table of supported GLSL
versions to _mesa_glsl_parse_state; this table is used both to
generate the error message and to check whether a given version is
supported.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Discovered accidentally when changing SAMPLE_L definition.
Turns out the lod arguments were already correct for the new definition
but the compare and derivs were not.
Reviewed-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
It looks like using coord.w as explicit lod value is a mistake, most likely
because some dx10 docs had it specified that way. Seems this was changed though:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh447229%28v=vs.85%29.aspx
- let's just hope it doesn't depend on runtime build version or something.
Not only would this need translation (so go against the stated goal these
opcodes should be close to dx10 semantics) but it would prevent usage of this
opcode with cube arrays, which is apparently possible:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb509699%28v=vs.85%29.aspx
(Note not only does this show cube arrays using explicit lod, but also the
confusion with this opcode: it lists an explicit lod parameter value, but then
states last component of location is used as lod).
(For "true" hw drivers, only nv50 had code to handle it, and it appears the
code was already right for the new semantics, though fix up the seemingly
wrong c/d arguments while there.)
v2: fix comment, separate out other changes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
These were, at some point in the past, used to request that Xorg's
compiler.h export a static inline xf86ReadMmio32 instead of a function
pointer. compiler.h only has this option for DEC Alpha.
But Xorg's compiler.h isn't being included by either of these two files
and the radeon driver still works on Alpha, so the definitions are dead
and not needed.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
link up the fs outputs and blend inputs, and make sure the second blend source
is correctly loaded and converted (which is quite complex).
There's a slight refactoring of the monster generate_unswizzled_blend()
function where it makes sense to factor out alpha conversion (which needs
to run twice for dual source blend).
This passes piglit arb_blend_func_extended tests.
v2: remove new but ultimately not used function...
Reviewed-by: Brian Paul <brianp@vmware.com>
These are more recent additions, and no one remembered to update the
INTEL_DEBUG=state code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
This reorders the "brw_bits" array in brw_state_upload.c to match the
order of the #defines in brw_context.h.
Otherwise, it's really hard to see if any are missing.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
These don't need to be re-disabled on every batch if we're using
hardware contexts. (If we're not, this is equivalent.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
If the same context try to flink and open the object, use the
same bo struct instead of opening a new gem handle for the object.
This way we avoid avoid having 2 different handle pointing to the
same kernel object which can latter lead to trouble with virtual
address.
Fix:
https://bugs.freedesktop.org/show_bug.cgi?id=60200
Signed-off-by: Martin Andersson <g02maran@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
minecraft apparently has its piles of display lists each contain 6
instances of glBegin(GL_QUADS)/verts/glEnd(), which appear in the
compiled list as 6 prims of 4 verts each in one draw call. We can
reduce driver overhead even more by making that one prim of 24 verts.
Improves minecraft performance by 1.6% +/- .25% (n=446)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We used to have clip planes optionally included in the push constants,
resulting in a variable amount of data uploaded, but no more. This also
means less wasted space in the batch for our push constants.
v2: Update _NEW_TRANSFORM state bit information.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
It doesn't matter with our current implementation of MapBufferRange,
but it was wrong -- the result pointer is read by intel_upload_data().
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The Mesa format can be RGBA8888_REV, the format/type can be
GL_RGBA/GL_UNSIGNED_BYTE, but the actual texture internal format can be
LUMINANCE_ALPHA, INTENSITY, etc. Therefore we should look at the base
internal format as well.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
_mesa_base_tex_format doesn't accept GL_BGR and GL_ABGR_EXT, etc.
v2: add a (now hopefully complete) helper function to deal with this
NOTE: This is a candidate for the stable branches.
Reviewed-by: Brian Paul <brianp@vmware.com>
- swapBytes has no effect on 8-bit single-component formats
- GL_SHORT is in host byte order, so checking for littleEndian is unnecessary,
I decided to make the change for single-component formats only
Based on suggestions from Michel Dänzer.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This patch fixes the vertex_header mask bitfield store in big-endian
architectures by bit-swap the fields accordingly.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Older hardware cannot do ARB_texture_rgb10_a2ui, and the translation
code for OES_compressed_ETC1_RGB8_texture was never implemented in the
i915 driver.
NOTE: This is a candidate for all stable branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This should handle the new lod_zero modifier more correctly.
The runtime-conditional is a bit more complex however we now also do
scalar lod computation when appropriate which should more than make up for it.
The refactoring should also fix an issue with explicit lods
(lod clamp wasn't applied to them).
Also, always pass lod as the 5th element from tgsi executor, which simplifies
things (get rid of annoying conditionals later).
v2: based on Brian's feedback, use switch in a couple of places, fix up
some function parameter names, fix up comments.
Reviewed-by: Brian Paul <brianp@vmware.com>
There were several bugs how this was handled, most opcodes wouldn't even
have fetched the right arguments.
Also, the tex "target" is coming from the sampler view, hence it cannot
have information about shadow comparisons - fortunately this is not only
sampler state but also needs to have matching instruction, so just use this
instead to identify shadow comparisons.
Still untested (compiles...).
Note that sample_i and sviewinfo are still busted (just assert).
(The problem is that the interface for doing the opengl-equivalent functions
txf and txq is tied to the specific the sampler itself but these opcodes
have no sampler associated with them. Oops...)
Also, even the other sample instructions will not work correctly since
they always operate on samplers which include the texture state. Fixing
this wouldn't be that difficult but most likely make softpipe quite a bit
slower when using the OpenGL tex opcodes (as the samplers have pre-baked
function calls in the sampler state depending on texture state and that stuff
would need to be evaluated at runtime), so leave it for now.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Need to calculate the number of mip levels (if it would be worthwile could
store it in dynamic state).
While here, the query code also used chan 2 for the lod value.
This worked with mesa state tracker but it seems safer to use chan 0.
Still passes piglit textureSize (with some handwaving), though the non-GL
parts are (largely) untested.
v2: clarify and expect the sviewinfo opcode to return ints, not floats,
just like the OpenGL textureSize (dx10 supports dst modifiers with resinfo).
Also simplify some code.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
They are similar to old-style tex opcodes but with separate sampler and
texture units (and other arguments in different places).
Also adjust the debug tgsi dump code.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Fixes uninitialized scalar field defects reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
None of the filters used it (why would they). Maybe that param
was just there because some of the lines were considered to be
too short...
Reviewed-by: Dave Airlie <airlied@redhat.com>
This optimized filter (when using repeat wrap modes,
linear min/mag/mip filters, pot textures) only applies to 2d textures,
but nothing prevented it from being used for other textures (likely
leading to very bogus sample results).
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The signed case didn't do what the comment indicated. Should increase rounding
precision (at the expense of performance since the former code was effectively
a no-op).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This adds support of the additional blending factors to the blend function
itself, and also enables testing of it in lp_test_blend (which passes).
Still need to add the glue code of linking fs shader outputs to blend inputs
in llvmpipe, and probably need to add special handling if destination doesn't
include alpha (which lp_test_blend doesn't test).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
There can be other per-thread data than just vis_counter, so pass a struct
around instead (some of our non-public code uses this already and this
difference is a major cause of merge pain).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The exa core will already set the pointer to NULL prior calling
the callback function. So don't bail out in the callback if it's
already NULL.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
At eglSwapBuffer time, we blindly assume we have a back buffer, but the
back buffer only gets allocated when somebody tries to render something.
NOTE: This is a candidate for the 9.0 and 9.1 branches.
https://bugs.freedesktop.org/show_bug.cgi?id=60086
Previous to this patch, there were 13 identical definitions of this
macro in Mesa source. That's ridiculous. This patch consolidates 6
of them to a single definition in src/mesa/main/macros.h.
Unfortunately, I wasn't able to eliminate the remaining definitions,
since they occur in places that don't include src/mesa/main/macros.h:
- include/pci_ids/pci_id_driver_map.h
- src/egl/drivers/dri2/egl_dri2.h
- src/egl/main/egldefines.h
- src/gbm/main/backend.c
- src/gbm/main/gbm.c
- src/glx/glxclient.h
- src/mapi/mapi/stub.c
I'm open to suggestions as to how to deal with the remaining redundancy.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, the i965 driver enabled EXT_framebuffer_multisample even
on pre-gen6 chipsets. However, since we don't support multisampling
on these chips, we set GL_MAX_SAMPLES=1 (the minimum allowed by
EXT_framebuffer_multisample), and if the client ever requested a
multisample buffer, we quietly supplied them with a single-sampled
buffer instead.
After some discussion on the mailing list (see thread
"ext_framebuffer_multisample: check for num_samples<=1"), it's clear
that this was the wrong approach. The correct approach is to only
expose EXT_framebuffer_multisample when we truly support
multisampling; that frees us to set a sensible value of
GL_MAX_SAMPLES=0 on other chipsets, so that we never have to deal with
a client requesting a multisample buffer when multisampling isn't
supported.
This change causes the following piglit tests to be skipped on
chipsets prior to Gen6:
- "ARB_framebuffer_sRGB/blit {renderbuffer,texture}
{linear,linear_to_srgb,srgb,srgb_to_linear}
{downsample,msaa,upsample} {disabled,enabled}"
- EXT_framebuffer_multisample/blit-mismatched-formats
- EXT_framebuffer_multisample/blit-mismatched-sizes
- EXT_framebuffer_multisample/dlist
- EXT_framebuffer_multisample/interpolation 0 *
- EXT_framebuffer_multisample/minmax
- EXT_framebuffer_multisample/negative-copypixels
- EXT_framebuffer_multisample/negative-copyteximage
- EXT_framebuffer_multisample/negative-max-samples
- EXT_framebuffer_multisample/negative-mismatched-samples
- EXT_framebuffer_multisample/negative-readpixels
- EXT_framebuffer_multisample/renderbuffer-samples
- EXT_framebuffer_multisample/renderbufferstorage-samples
- EXT_framebuffer_multisample/samples
This is expected, since the above tests exercise MSAA functionality,
and shouldn't be run on systems prior to Gen6.
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously the loop_state was allocated in the loop_analysis
constructor, but not freed in the (nonexistent) destructor. Moving
the allocation of the loop_state makes this code appear less sketchy.
Either way, there is no actual leak. The loop_state is freed by the
single caller of analyze_loop_variables.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Dave Airlie <airlied@freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57753
In the documentation for BindBufferRange, OpenGL specs from 3.0
through 4.1 contain this language:
"The error INVALID_VALUE is generated if size is less than or
equal to zero or if offset + size is greater than the value of
BUFFER_SIZE."
This text was dropped from OpenGL 4.2, and it does not appear in the
GLES 3.0 spec.
Presumably the reason for the change is because come clients change
the size of the buffer after calling BindBufferRange. We don't want
to generate an error at the time of the BindBufferRange call just
because the old size of the buffer was too small, when the buffer is
about to be resized.
Since this is a deliberate relaxation of error conditions in order to
allow clients to work, it seems sensible to apply it to all versions
of GL, not just GL 4.2 and above.
(Note that there is no danger of this change allowing a client to
access data beyond the end of a buffer. We already have code to
ensure that that doesn't happen in the case where the client shrinks
the buffer after calling BindBufferRange).
Eliminates a spurious error message in the gles3 conformance test
"transform_feedback_offset_size".
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This matches the behavior of the Windows driver, but a bspec reference
should would be nice.
NOTE: This is a candidate for the 9.0 and 9.1 branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Should have been done in d9948e49 but I missed it because
MAX_VARYING_FLOATS doesn't appear in the ES 3 spec, but is the same
value as MAX_VARYING_COMPONENTS.
NOTE: Candidate for the 9.1 branch
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Append the overloaded vector type used for passing in the addressing
parameters.
Without this, LLVM uses the same function signature for all those types,
which cannot work.
Fixes problems e.g. with FlightGear and Red Eclipse.
Was using the pixel size instead of the number of block for the slice
tile max computation which resulted in dma writing at wrong address.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Now that we have support for overriding alpha to 1.0, we can handle
blitting between these formats in either direction.
For now, we only support two XRGB formats: MESA_FORMAT_XRGB8888 and
MESA_FORMAT_RGBX8888_REV. Most places only appear to worry about the
former, so ignore the latter for now. We can always add it later.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Martin Steigerwald <martin@lichtvoll.de>
Currently, Blorp requires the source and destination formats to be
equal. However, we'd really like to be able to blit between XRGB and
ARGB formats; our BLT engine paths have supported this for a long time.
For ARGB -> XRGB, nothing needs to occur: the missing alpha is already
interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha
channel to 1.0 when writing the destination colors. This is fairly
straightforward with blending.
For now, this code is never used, as the source and destination formats
still must be equal. The next patch will relax that restriction.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Martin Steigerwald <martin@lichtvoll.de>
The BLT engine has many limitations. Currently, it can only blit
X-tiled buffers (since we don't have a kernel API to whack the BLT
tiling mode register), which means all depth/stencil operations get
punted to meta code, which can be very CPU-intensive.
Even if we used the BLT engine, it can't blit between buffers with
different tiling modes, such as an X-tiled non-MSAA ARGB8888 texture
and a Y-tiled CMS ARGB8888 renderbuffer. This is a fundamental
limitation, and the only way around that is to use BLORP.
Previously, BLORP only handled BlitFramebuffer. This patch adds an
additional frontend for doing CopyTexSubImage. It also makes it the
default. This is partly to increase testing and avoid hiding bugs,
and partly because the BLORP path can already handle more cases. With
trivial extensions, it should be able to handle everything the BLT can.
This helps PlaneShift massively, which tries to CopyTexSubImage2D
between depth buffers whenever a player casts a spell. Since these
are Y-tiled, we hit meta and software ReadPixels paths, eating 99% CPU
while delivering ~1 FPS. This is particularly bad in an MMO setting
because people cast spells all the time.
It also helps Xonotic in 4X MSAA mode. At default power management
settings, I measured a 6.35138% +/- 0.672548% performance boost (n=5).
(This data is from v1 of the patch.)
No Piglit regressions on Ivybridge (v3) or Sandybridge (v2).
v2: Create a fake intel_renderbuffer to wrap the destination texture
image and then reuse do_blorp_blit rather than reimplementing most
of it. Remove unnecessary clipping code and conditional rendering
check.
v3: Reuse formats_match() to centralize checks; delete temporary
renderbuffers. Reorganize the code.
v4: Actually copy stencil when dealing with separate stencil buffers but
packed depth/stencil formats. Tested by a new Piglit test.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com> [v4]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v3]
Reviewed-and-tested-by: Carl Worth <cworth@cworth.org> [v2]
Tested-by: Martin Steigerwald <martin@lichtvoll.de> [v3]
I need to use this from C++ code.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These formats were added a few months after these tables were committed.
No idea why we have the table though. AFAIK, texstore always takes the slow path
for GL_RGBn.
Reviewed-by: Brian Paul <brianp@vmware.com>
The GLSL compiler can simplify clamp(v,0,1) to saturate. The state tracker
doesn't use it yet, but it will.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
I'd like to test Mesa OpenGL ES along side with NVIDIA libGL drivers. But
without this change, I get a NULL pointer dereference.
Reviewed-by: Brian Paul <brianp@vmware.com>
Fixes uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
We weren't emitting the SVGA_RS_OUTPUTGAMMA state so sRGB rendering
didn't work properly.
Fixes piglit's framebuffer-srgb test.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Strangely, the DRIimage interface we have passes the pitch in pixels
instead of bytes, which anholt missed in the change to using bytes for
region pitch.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Since transform feedback needs to be able to access individual fields
of varying structs, we can no longer match up the arguments to
glTransformFeedbackVaryings() with variables in the vertex shader.
Instead, we build up a hashtable which records information about each
possible name that is a candidate for transform feedback, and then
match up the arguments to glTransformFeedbackVaryings() with the
contents of that hashtable.
Populating the hashtable uses the program_resource_visitor
infrastructure, so the logic is shared with how we handle uniforms.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously, transform feedback varyings were parsed in an ad-hoc
fashion that wasn't compatible with structs (or array of structs).
This patch makes it use parse_program_resource_name(), which correctly
handles both.
Note that parse_program_resource_name()'s technique for handling
mal-formed input strings is to simply let them through and rely on the
fact that a future name lookup will fail. Because of this,
tfeedback_decl::init() no longer needs to return a boolean error
code--it always succeeds, and if the input was mal-formed the error
will be detected later.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
There's actually nothing uniform-specific in uniform_field_visitor.
It is potentially useful for all kinds of program resources (in
particular, future patches will use it for transform feedback
varyings).
This patch renames it to program_resource_visitor, and clarifies
several comments, to reflect the fact that it is useful for more than
just uniforms.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The parsing logic is moved to a new function in the GLSL module,
parse_program_resource_name(). This name was chosen because it should
eventually be useful for handling everything that OpenGL 4.3 calls
"program resources" (e.g. uniforms, vertex inputs, fragment outputs,
and transform feedback varyings).
Future patches will make use of this function for linking transform
feedback varyings.
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Previously we were relying on CFLAGS_FOR_BUILD to be the same as CFLAGS
when not cross compiling, but this assumption didn't take into
consideration 32-bit builds on 64-bit systems. More generally, not
honoring CFLAGS is bad.
Automake is evidently too stupid to accept
if CROSS_COMPILING
CC = @CC_FOR_BUILD@
...
else
CC = @CC@
endif
without warning that CC has been already defined. The warnings are
harmless, but I'd prefer to avoid future reports about them, so define
proxy variables, which are assigned inside the conditional and then
unconditionally assigned to CC et al.
NOTE: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59737
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60038
The glsl-to-tgsi translater will emit SQRT to implement GLSL's sqrt()
and distance() functions if the PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED
query says it's supported by the driver.
Otherwise, sqrt(x) is implemented with x*rsq(x). The problem with
this is sqrt(0) must be handled specially because rsq(0) might be
Inf/NaN/undefined (and then 0*rsq(0) is Inf/Nan/undefined). In the
glsl-to-tgsi code we use an extra CMP to check if x is zero and then
replace the result of x*rsq(x) with zero.
In the end, this makes sqrt() generate much more reasonable code for
drivers that can do square roots.
Note that many of piglit's generated shader tests use the GLSL
distance() function.
In particular, the LOD bias and depth comparison values are packed before the
'normal' texture coordinates, and the array slice and LOD values are appended.
NOTE: This is a candidate for the 9.1 branch.
In particular, rework the sRGB/linear format selection code.
There's no reason to mess with the Mesa format.
Just do everything in terms of the gallium pipe_format.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
The code before was getting a pipe format, then calling
st_pipe_format_to_mesa_format() and then converting back again with
st_mesa_format_to_pipe_format(). This removes one conversion step.
If we call gl[Copy]TexImage2D() with a generic compression format
(e.g. intFormat=GL_COMPRESSED_RGBA) we can't choose a DXT format if
we don't have the external DXT compression library.
We weren't actually enforcing this before since the
pipe_screen::is_format_supported(DXT) query has no dependency on
the DXT compression library.
Now if we're given a generic compressed format and we can't do DXT
compression we'll fall back to a non-compressed format.
v2: use util_format_is_s3tc() function and add more comments about
the allow_dxt parameter.
Note: This is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
When glCompressedTexImage is called the internalFormat is a specific
format for the incoming image and the the hardware format should be
the same (since we never do format transcoding). So use the simpler
_mesa_glenum_to_compressed_format() function. This change is also
needed for the next patch.
Note: This is a candidate for the stable branches.
Ivybridge doesn't appear to have the same errata as Sandybridge; no
corruption was observed by setting it to more than the minimal correct
value. It's possible that we were simply lucky, since the URB entries
are 1024-bit on Ivybridge vs. 512-bit Sandybridge. Or perhaps the
underlying hardware issue is fixed.
Either way, we may as well program the minimum value since it's now
readily available, likely to be more efficient, and possibly more
correct.
v2: Use GEN7_SBE_* defines rather than GEN6_SF_*. (A copy and paste
mistake.) They're the same, but using the right names is better.
NOTE: This is a candidate for all stable branches.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(This commit message was primarily written by Paul Berry, who explained
what's going on far better than I would have.)
Previous to this patch, we thought that the only restrictions on
3DSTATE_SF's URB read length were (a) it needs to be large enough to
read all the VUE data that the SF needs, and (b) it can't be so large
that it tries to read VUE data that doesn't exist. Since the VUE map
already tells us how much VUE data exists, we didn't bother worrying
about restriction (a); we just did the easy thing and programmed the
read length to satisfy restriction (b).
However, we didn't notice this erratum in the hardware docs: "[errata]
Corruption/Hang possible if length programmed larger than recommended".
Judging by the context surrounding this erratum, it's pretty clear that
it means "URB read length must be exactly the size necessary to read all
the VUE data that the SF needs, and no larger". Which means that we
can't program the read length based on restriction (b)--we have to
program it based on restriction (a).
The URB read size needs to precisely match the amount of data that the
SF consumes; it doesn't work to simply base it on the size of the VUE.
Thankfully, the PRM contains the precise formula the hardware expects.
Fixes random UI corruption in Steam's "Big Picture Mode", random terrain
corruption in PlaneShift, and Piglit's fbo-5-varyings test.
NOTE: This is a candidate for all stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56920
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60172
Tested-by: Jordan Justen <jordan.l.justen@intel.com> (v1/Piglit)
Tested-by: Martin Steigerwald <martin@lichtvoll.de> (PlaneShift)
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The maximum SF source attribute is necessary to compute the Vertex URB
read length properly, which will be done in the next commit.
NOTE: This is a candidate for all stable branches.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Tested-by: Martin Steigerwald <martin@lichtvoll.de>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The next patch will benefit from easy access to the source attribute
number and whether or not we're swizzling. It doesn't want the final
attr_override DWord form, however.
NOTE: This is a candidate for all stable branches.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Tested-by: Martin Steigerwald <martin@lichtvoll.de>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Back when ir_var_in and ir_var_out signified both function parameters
and shader input/outputs, we had trouble distinguishing the two when
looking at a dereference. Now that we have separate ir_var_shader_in
and ir_var_shader_out modes, we can determine this easily.
Removing the hash table saves memory and CPU overhead.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
The third argument of AC_ARG_WITH is evaluated for any provided value,
not only on --with-, so it must not force-enable the feature
Also, setting $with_llvm_shared_libs in the opencl check was overriding
the user switch
https://bugs.freedesktop.org/show_bug.cgi?id=59851
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Save miptree level info to DRIImage:
- Appropriately-aligned base offset pointing to the image
- Additional x/y adjustment offsets from above.
v8: -Bump intelImageExtension version
v9: -Don't use internal _eglError but implement error reporting in new DRI inteface
instead. This fixes Android build problems based on feedback from
Adrian M Negreanu and Chad Versace.
-Move the non-tile-aligned check and error-reporting to intel_set_texture_image_region
v10: -Don't #include "egl/main/eglcurrent.h". [chadv]
Reviewed-by: Eric Anholt <eric@anholt.net> (v6)
Acked-by: Chad Versace <chad.versace@linux.intel.com> (v10)
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
We need to take account the offset from original bo when using glTexSubImage()
and other functions that manipulate the subregion of an exported texture.
Offsets are appended to mapped region address and when blitting from a source
region.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
When binding a region to a texture image, re-create the miptree base-level
considering the offset and dimension information exported by DRIImage.
v8: - Move the alignment surface address checks from the image-from-texture
code to the texture-from-image side. This allows the error reporting to conform to
OES_EGL_Image and to prevent mixing up EGL and GL errors. Reported by Chad Versace.
- Addressed an existing issue in renderbuffer case where there is a
a possibility of creating EGL images out of depthstencil textures which isn't
really possible. This was spotted by Eric earlier.
Reviewed-by: Eric Anholt <eric@anholt.net> (v6)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v8)
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
If the offsets are present, this lets us specify a particular level and slice
in a shared region using the base level of an exported mip-map tree.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Add create image from texture extension and bump version.
v8: - Add appropriate image errors codes in DRI interface so we don't
have to use internal EGL functions in driver. Suggested by Chad Versace.
Reviewed-by: Eric Anholt <eric@anholt.net> (v6)
Reviewed-by: Chad Versace <chad.versace@linux.intel.com> (v8)
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Was broken since commit bf469f4edc
('gallium: add void *user_buffer in pipe_index_buffer').
Fixes 11 piglit tests and lots of missing geometry e.g. in TORCS.
NOTE: This is a candidate for the 9.1 branch.
The svga device doesn't handle them. Replace with zeros.
Fixes several piglit tests, such as "glsl-const-builtin-inversesqrt".
Reviewed-by: Reviewed-by: José Fonseca <jfonseca@vmware.com>
glRasterPos doesn't exist in the core profile.
NOTE: This is a candidate for the stable branches (9.0 and 9.1).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This along with the latest drm-fixes branch should help with bad performance
of MSAA. Remember: Nx MSAA can't be more than N times slower (where N=2,4,6).
Anyway, I recommend at least 512 MB of VRAM for Full HD 6x MSAA.
NOTE: This is a candidate for the 9.1 branch.
GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
If the user specified --enable-xlib-glx --disable-opengl, error out, as these
cannot be both observed at the same time. If the user just specified
--disable-opengl but not --disable-glx, print a warning and disable GLX as
well.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59364
Tested-by: Tom Stellard <thomas.stellard@amd.com>
R600_DUMP_SHADERS environment var now allows to choose dump method:
0 (default) - no dump
1 - full dump (old dump)
2 - disassemble
3 - both
v2: fix output for burst_count > 1
v3: use more human-readable output for kcache data in CF_ALU_xxx clauses,
improve output for ALU_EXTENDED, other minor fixes
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
v3: added some flags including condition codes for ALU,
fixed issue with CF reverse lookup (overlapping ranges of CF_ALU_xxx
and other CF instructions)
rebased on current master
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
The idea is to compute a gross estimate of memory requirement of
each draw call. After each draw call, memory will be precisely
accounted. So the uncertainty is only on the current draw call.
In practice this gave very good estimate (+/- 10% of the target
memory limit).
v2: Remove left over from testing version, remove useless NULL
checking. Improve commit message.
v3: Add comment to code on memory accounting precision
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
This reverts commit 2906e2034c.
Fixes a regression in the glean depthStencil test.
Reverting this does not affect any tests in es3conform, so a more recent
patch must have also fixed the failure this one was intended to fix.
Reported-by: lu hua <huax.lu@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59494
v2: Update to handle BufferSize being -1 and return a NULL sampler
view if the specified range would cause out of bounds access.
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
v3: Use extra GL_CORE-only section in get_hash_params.py for
TEXTURE_BUFFER_OFFSET_ALIGNMENT.
v4: Remove unnecessary check for profile in _mesa_TexBufferRange.
Add check for extension enable in get_tex_level_parameter_buffer.
v5: Fix position in gl_API.xml.
Add comment about meaning of BufferSize == -1.
v6: Add back checks for core profile and add a note about it.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Check that the return value from xcb_dri2_swap_buffers_reply is
non-NULL before accessing the struct members.
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
S8_UNORM was inadvertedly supported together with Z16_UNORM.
I tried to update the code to accomodate stencil-only -- it seemed a simple
thing to do -- but "fbo-stencil clear GL_STENCIL_INDEX8" still fails,
and it's not worth debugging.
Therefore although this change tries to update for S8_UNORM, it also
disables it completely.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
This special path hadn't been exercised by my earlier testing, and mask
values weren't being properly truncated to match the values.
This change fixes that.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The struct padding got broken by c789b981b2.
This caused serious performance regression because part of the key was
uninitialized and hence the shader always recompiled (at least on release
builds...).
While here also fix key size calculation when the number of samplers
and the number of sampler views are different.
v2: add comment
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
The swrast fragment program interpreter has trouble computing the
right texture LOD because it doesn't have easy access to input
derivatives. This causes the GLSL-based meta generate mipmap code
to fetch texels from the wrong mipmap level.
One possible fix would be to set the GL_TEXTURE_MIN/MAX_LOD parameters
to limit sampling from the right level. But let's just use the
_mesa_generate_mipmap() fallback since it's a lot faster than using
the fragment shader interpreter.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=54240
Note: This is a candidate for the 9.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
The gallium docs for pipe_screen::is_format_supported() says that
samples==0 or samples==1 both mean that multisampling is not supported.
Return GL_MAX_SAMPLES==0 instead of 1 for consistency with other drivers.
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Simply by adjusting the vector element width after/before
reading/writing the depth-stencil values.
Ran several GL_DEPTH_COMPONENT16 piglit tests without regressions.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The maximum number of URB entries come from the 3DSTATE_URB_VS and
3DSTATE_URB_GS state packet documentation; the thread count information
comes from the 3DSTATE_VS and 3DSTATE_PS state packet documentation.
NOTE: This is a candidate for the 9.0 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
The packet length may change at some point in the future. Specifying it
explicitly (rather than hardcoding it in the command #define) allows us
to change it much more easily in the future.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
I did not list the *_get_program_binary extensions since they're not
useful to anyone with their current implementation (that supports 0
binary formats).
Before, we were keeping a CPU-only buffer to accumulate the batchbuffer in,
which was an improvement over mapping the batch through the GTT directly
(since any readback or other failure to stream through write combining
correctly would hurt). However, on LLC-sharing architectures we can do better
by mapping the batch directly, which reduces the cache footprint of the
application since we no longer have this extra copy of a batchbuffer around.
Improves performance of GLBenchmark 2.1 offscreen on IVB by 3.5% +/- 0.4%
(n=21). Improves Lightsmark performance by 1.1 +/- 0.1% (n=76). Improves
cairo-gl performance by 1.9% +/- 1.4% (n=57).
No statistically significant difference in GLB2.1 on SNB (n=37). Improves
cairo-gl performance by 2.1% +/- 0.1% (n=278).
Fixes side effect in assertion defects reported by Coverity.
Note: This is a candidate for the 9.1 branch.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Currently a gralloc internal structure is exposed to Mesa,
Use a query function instead to maintain ABI compatibility.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Old kernel do not have dma support, patch pushed were missing some
of the check needed to not use dma.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Only drivers supporting DRI2 version >=4 support GLX_INTEL_swap_event.
So lets mark it as such otherwise applications which use this extension
(i.e. everything based on Clutter, e.g. gnome-shell) break horribly on
drivers supporting DRI2 versions only up to 3.
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
Get rid of special handling for reserved regs.
Use one intrinsic for all kinds of interpolation.
v2[Vincent Lejeune]: Rebased against current master
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
r600_bytecode::ar_chan stores the register channel for the value that
will be loaded into the AR register.
At the moment, this field is only used by the LLVM backend. The default
backend always sets ar_chan = 0.
We keep track of ring emission order in a stack, whenever we need to
flush we empty the stack in a fifo order. There is few helpers function
for bo mapping and other ring activities that will make sure that
the ring stack is properly flush and submitted.
v2: fix st flush path, and other flush path to properly flush all
rings if necessary
v3: - improve name of ring helpers
- make sure that each time a cs is gona be written it endup at
top of the stack to avoid any issue such as :
STACK[0] = dma (withbo A,B)
STACK[1] = gfx (withbo C,D)
Now if code try to emit a dma command relative to bo C or D
it will start writting cmd stream into the cs and once it
reach the point where it adds relocation it will flush.
At that point the cs will have cmd that don't have proper
relocation into the relocation buffer and kernel will just
refuse to run.
v4: - Drop the stack idea as it turn out there is no way to use it
or benefit from it. Any time the driver start command on other
ring, it always need to flush the previous ring. So make code
simpler by not using a stack.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Add ring support, you can create a cs for each ring. DMA ring is
bit special regarding relocation as you must emit as much relocation
as there is use of the buffer.
v2: - Improved comment on relocation changes
- Use a single thread to queue cs submittion this simplify driver
code while not impacting performances. Rational for this is that
you have to wait for all previous submission to have completed
so there was never a case while we could have 2 different thread
submitting a command stream at the same time. This code just
consolidate submission into one single thread per winsys.
v3: - Do not use semaphore for empty queue signaling, instead use
cond var. This is because it's tricky to maintain an even number
of call to semaphore wait and semaphore signal (the number of
cs in the stack would for instance make that number vary).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Make it obvious what "unit" this is (no change in functionality).
draw still uses "unit" in places where it changes the shader by adding
texture sampling itself - it seems like this can't work with shaders
using dx10-style sample opcodes (can't mix gl-style and dx10-style
sample instructions in a shader).
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Split the sampler interface to use separate sampler and texture (sampler_view)
state. This is needed to support dx10-style sampling instructions.
This is not quite complete since both draw/llvmpipe don't really track
textures/samplers independently yet, as well as the gallivm code not quite
using the right sampler or texture index respectively (but it should work
for the sampling codes used by opengl).
We are however losing some optimizations in the process, apply_max_lod will
no longer work, and we potentially could end up with more (unnecessary)
recompiles (if switching textures with/without mipmaps only so it shouldn't
be too bad).
v2: don't use different callback structs for sampler/sampler view functions
(which just complicates things), fix up sampling code to actually use the
right texture or sampler index, and similar for llvmpipe/draw actually
distinguish between samplers and sampler views.
v3: fix more of PIPE_MAX_SAMPLER / PIPE_MAX_SHADER_SAMPLER_VIEWS mismatches
(both in draw and llvmpipe), based on feedback from José get rid of unneeded
static sampler derived state.(which also fixes the only 2 piglit regressions
due to a forgotten assignment), fix comments based on Brian's feedback.
v4: remove some accidental unrelated whitespace changes
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
npix_x/y/z is wrong with NPOT textures, since it's always aligned to POT
if the level is non-zero, so we can't use that.
This fixes piglit/spec/EXT_texture_shared_exponent/fbo-generatemipmap-formats.
Fixes a crash when the Redway3D Turbine demo exits. We've made this
change in other places in the past. The root issue is texture objects
are being shared by multiple contexts and sampler views get shared too.
Sampler views have a context pointer and if that context gets deleted
we may try to reference that context when finally deleting the sampler
view.
pipe_sampler_view_release() avoids this problem because it takes
an explicit context.
Reviewed-by: Zack Rusin <zackr@vmware.com>
Check the return value of calls to u_upload_alloc() and
u_upload_data() and return early if needed.
Since we don't have a way to propagate errors all the way up to
Mesa through pipe_context::draw_vbo(), call debug_warn_once() so
the user might have some clue about OOM errors.
Note: This is a candidate for the 9.0 branch.
We weren't properly checking the return value of these calls (and
calls to u_upload_data()) to detect OOM errors.
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Some callers of this function were checking the 'ptr' result to see if
the function failed. But the correct way is to check the regular
return value for PIPE_ERROR_x. Now we initialize all the returned
values at the top of the function in case we do hit an error (like OOM).
Callers are more likely to detect OOM conditions now. But there
are some callers which don't do any error checking...
Note: This is a candidate for the 9.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
That is, evaluate constant expressions for the following functions:
packSnorm4x8, unpackSnorm4x8
packUnorm4x8, unpackUnorm4x8
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
For each function {pack,unpack}{Snorm,Unorm}4x8, add a corresponding
opcode to enum ir_expression_operation. Validate the new opcodes in
ir_validate.cpp.
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We were using the NEED_RADEON_GALLIUM conditional to decide whether or not
to build llvm_wrapper.cpp, which is required for using the LLVM backend.
llvm_wrapper.cpp needs to be linked against the LLVM IPO libary
and this library is only added to LLVM_LIBS if either opencl or the
r600-llvm-compiler is enabled.
The NEED_RADEON_GALLIUM conditional is set to true when enabling the
radeonsi driver, so if the radeonsi and r600 drivers are enabled without
also enabling opencl or r600-llvm-compiler, llvm_wrapper.cpp will be
built, but the IPO library won't be added to LLVM_LIBS. This was
causing unresolved symbol errors when buiding with this configuration.
https://bugs.freedesktop.org/show_bug.cgi?id=59831
Tested-by: Alex Deucher <alexander.deucher@amd.com>
Dereffing all the values in the two callers was just pointless, and
the function isn't inlined so there was actual code impact.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The core Mesa code has just one more case than this (GL_BITMAP), so I
don't see any cause to special-case it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This was added in b93684f5f3, but there's
no need for it -- get_size has to succeed, and it has an assert for us
in debug builds.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For our current types, the required alignment is actually just 1 byte.
When we get doubles, we have to worry (those have to be aligned to the
natural size), but we don't have doubles yet and they'll just be a
special case.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: A previous patch contained a spurious hunk that removed an
assignment to ir_variable::uniform_block. That hunk was moved to this
patch. Suggested by Carl Worth.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glGetActiveUniform is not supposed to report block members that are not
active even if they are included in the layout of the block. The block
layout is determined from the GLSL_TYPE_INTERFACE that defines the
block, so eliminating the ir_variables that correspond to the individual
fields is safe.
Fixes gles3conform test
uniform_buffer_object_getuniformindices_for_for_nonexistent_or_not_active_uniform_names.
This also fixes the assertion failures (added in the previous commit) in
gles3conform uniform_buffer_object_index_of_not_active_block,
uniform_buffer_object_inherit_and_override_layouts, and
uniform_buffer_object_repeat_global_scope_layouts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Use the function added in the previous commit.
This temporarily causes gles3conform
uniform_buffer_object_index_of_not_active_block,
uniform_buffer_object_inherit_and_override_layouts, and
uniform_buffer_object_repeat_global_scope_layouts to assertion fail.
This is fixed in the next commit.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Calculate all of the block member offsets, the IndexNames, and
everything else to do with every UBO.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Pretty much all of the compile-time, per-compilation unit block data is
about to get the axe.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
glGetUniformIndices requires that the block instance index not be
present in the name of queried uniforms. However,
gl_uniform_buffer_variable::Name will include the instance index. The
IndexName field is added to handle this difference.
Note that currently IndexName will always point to the same string as
Name. This will change soon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Pretty much all of the compile-time, per-compilation unit block data is
about to get the axe.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This flavor takes a type and a base name. It will be used to handle
cases where the block name (instead of the instance name) is used for an
interface block.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Inspite of the spell checker, spell recurse correctly. Suggested by
Carl Worth.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Eventually the gl_uniform_block information won't be calculated until
linking. Block names need to be checked for name clashes during
compiling, so we have to track it differently.
v2: Update the commit message. Suggested by Carl Worth.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Not used yet, but the UBO layout visitor will use this.
v2: Remove a spruious hunk. This is moved to the patch "glsl: Remove
ir_variable::uniform_block". Suggested by Carl Worth.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Not used yet, but the UBO layout visitor will use this.
v2: Add some commentary as to why row_major is always set to false in
process. Suggesed by Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For the first declaration below, there will be an ir_variable named
"instance" whose type and whose instance_type will be the same
glsl_type. For the second declaration, there will be an ir_variable
named "f" whose type is float and whose instance_type is B2.
"instance" is an interface instance variable, but "f" is not.
uniform B1 {
float f;
} instance;
uniform B2 {
float f;
};
v2: Copy the comment message documentation into the code. Suggested by
Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For variables that are in an interface block or are an instance of an
interface block, this is the GLSL_TYPE_INTERFACE type for that block.
Convert the ir_variable::is_in_uniform_block method added in the
previous commit to use this field instead of ir_variable::uniform_block.
v2: Fix the place-holder comment on ir_variable::interface_type.
Suggested by Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The way a variable is tested for this property is about to change, and
this makes the code easier to modify.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If the block has an instance name, add the instance name to the symbol
table instead of the individual fields.
Fixes the piglit test interface-name-access-without-interface-name.vert
for real.
v2: Update the comment before the assertion that interface block
definitions won't generate instructions. Suggested by Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Interfaces are structurally identical to structures from the compiler's
point of view. They have some additional restrictions, and generally
GPUs use different instructions to access them. Using a different base
type should make this a bit easier.
This commit also adds the glsl_type::interface_packing fields. For
GLSL_TYPE_INTERFACE types, this will track the specified packing mode.
It is analogous to gl_uniform_buffer::_Packing.
v2: Add serveral missing GLSL_TYPE_INTERFACE cases in switch-statements.
v3: Add information about glsl_type::interface_packing. Move row_major
checking in glsl_type::record_key_compare from this patch to the
previous patch. Both suggested by Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For now, this will always be false. In the near future, an "interface"
type will be added that shares a lot of infrastructure with structures.
v2: Move row_major checking in glsl_type::record_key_compare from the
next patch to this patch. Suggested by Paul Berry.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The size is parsed and stored in the AST, but it is not used yet.
Processing of the array size is added in the patch "glsl: Handle
instance array declarations"
v2: Update the commit message (suggested by Carl Worth). Add a comment
to ast_uniform_block::array_size (suggested by Paul Berry).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In GLSL ES 3.00 (and GLSL 1.50), uniform blocks can have an associated
"instance name", which essentially namespaces the variables inside.
This patch adds basic parsing for this new feature, but doesn't yet hook
it up to actually do anything yet.
It does not support for arrays of interface blocks; a later commit will
take care of that.
This change temporarily regresses the piglit test
interface-name-access-without-interface-name.vert. This shader failed
to compile before (the expected result), but it failed to compile for
the wrong reason. This is not a real regression.
v2: Add some comments to ast_uniform_block::instance_name. Suggested by
Paul Berry.
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The existing code has a lot of duplication; the only difference between
the two cases is whether we merge in an additional layout qualifier.
Apparently creating a layout_qualifieropt rule that can be empty causes
a lot of conflicts and confusion. However, refactoring out the guts of
the ast_uniform_block creation works fine.
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Also slightly change the compatibility test. Instead of comparing the
offsets of the block variables, compare the packing mode of the blocks.
Ideally we don't want to assign the offsets until a later stage of
linking.
This is put in a new file called link_uniform_blocks.cpp. Some new
functions related to uniform blocks are going to live in that file as
well.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This makes it easier to find switch-statements that need to be updated
after a new GLSL_TYPE_* is added because the compiler will generate a
warning.
Switch-statements that only had a small number of cases (e.g.,
everything in ir_constant_expression.cpp) were not modified. I may
regret that decision when we eventually add support for doubles.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Too much attention was paid to the first paragraphs, and not enough to
the last little note that "oh, by the way, the rendered things
themselves still have to be clipped to just 8192 wide/high".
Fixes GTF's clip.c test with 4096 or higher width on ivb, where one of
the triangles got the upper half of its pixels dropped.
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Khronos has apparently decided that depth textures with sized formats
(allowed with ARB_internalformat_query or ES 3.0) should be treated as
GL_RED, while unsized formats (an existing feature) should be treated
as GL_INTENSITY for compatibility with ES 2.0.
Ian is proposing changes to ARB_internalformat_query which will make
this actually legal and consistent.
A similar problem exists with GL 4.2, but we're going to ignore that
for the time being.
Tested on Ivybridge: no Piglit regressions; fixes 4 es3conform tests:
- depth_texture_fbo
- depth_texture_fbo_clear
- depth_texture_teximage
- depth_texture_texsubimage
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since patch "i965: Validate requested GLES context version in
brwCreateContext", we have been able to create ES 3.0 contexts due to the
max version check. So...bump the max version.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
v2: Add ARB_internalformat_query to the list of required extensions.
v3: Add OES_depth_texture_cube_map to the list of required extensions.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
s/src/src_w/
That little typo, which sneaked into v4 of the previous patch, generates
incorrect fs code.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
FIXME: This patch emits VS code that violates documented hardware
restrictions and then relies on undocumented behavior that results from
that violation. This patch passes all tests, but should be fixed ASAP to
conform to the hardware documentation.
v2: Explain undocumented hardware behavior. Improve comments.
v3: Use ALU1 helper methods F32TO16() and F16TO32(). [for anholt]
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The GLSL ES 3.00 operations packHalf2x16 and unpackHalf2x16 will emit
these opcodes.
- Define the opcodes BRW_OPCODE_{F32TO16,F16TO32}.
- Add the opcodes to the brw_disasm table.
- Define convenience functions brw_{F32TO16,F16TO32}.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
On gen < 7, we fully lower all operations to arithmetic and bitwise
operations.
On gen >= 7, we fully lower the Snorm2x16 and Unorm2x16 operations, and
partially lower the Half2x16 operations.
v2:
- Comment that scalarization is needed only for SOA code [for idr].
- Replace switch-statement with if-statement [for idr].
- Remove misplaced hunk from previous patch [found by idr].
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Tuner <mattst88@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Lower them to arithmetic and bit manipulation expressions.
v2: Rewrite using ir_builder [for idr].
v3: Comment typos. [for mattst88]
v4: Fix arithmetic error in comments.
Factor out a shift instruction.
Don't heap allocate factory.instructions.
[for paul]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v2)
Reviewed-by: Matt Tuner <mattst88@gmail.com> (v3)
Reviewed-by: Paul Berry <stereotype441@gmail.com> (v4)
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
In ir_expression's constructor, the cases for {bit,logic}_{and,or,xor}
failed to handle the case when both operands were vectors.
Note: This is a candidate for the stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Replace tabs with spaces. According to docs/devinfo.html, Mesa's
indetation style is:
indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
This patch prevents whitespace weirdness in the next patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Add two overloaded variants of
ir_if *if_tree()
The new functions allow one to chain together if-trees within a single C++
expression that resembles a real if-statement.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Using this enum improves the readibility of calls to assign(), whose third
argument is a writemask.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Add method ir_factory::constant. This little method constructs an
ir_constant using the factory's mem_ctx.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Add the following functions, each of which construct the similarly named
ir expression:
div, round_even, clamp
equal, less, greater, lequal, gequal
logic_not, logic_and, logic_or
bit_not, bit_or, bit_and, lshift, rshift
f2i, i2f, f2u, u2f, i2u, u2i
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
That is, evaluate constant expressions of the following functions:
packSnorm2x16 unpackSnorm2x16
packUnorm2x16 unpackUnorm2x16
packHalf2x16 unpackHalf2x16
v2: Reuse _mesa_pack_float_to_half and its inverse to evaluate
pack/unpackHalf2x16. [for idr]
v3: Whitespace fixes. [for mattst88]
Don't cast neg floats directly to uint16; use an intermediate cast to
int16. [for paul]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v2)
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Matt Tuner <mattst88@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Not all float32 values can be exactly represented as a float16.
_mesa_float_to_half() rounded such intermediate float32 values to zero by
truncating unrepresentable bits in the mantissa.
This patch improves _mesa_float_to_half() by rounding intermediate float32
values to the nearest float16; when the float32 is exactly between two
float16 values we round to the one with an even mantissa. This behavior is
preferred over the old behavior because:
- It has reduced bias relative to the old behavior.
- It reproduces the behavior of real hardware: opcode F32TO16 in
Intel's GPU ISA.
- By reproducing the behavior of the GPU (at least on Intel hardware),
compile-time evaluation of constant packHalf2x16 GLSL expressions will
result in the same value as if the expression were executed on the GPU.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Move round_to_even's definition to mesa/main so that _mesa_float_to_half()
can use it in order to eliminate rounding bias.
In additon to moving the fuction definition, prefix its name with "_mesa",
just as all other functions in mesa/main are prefixed.
v2: Fix Android build.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
A subsequent patch will add mesa/main/imports.c as a dependency to the
compiler, which in turn requires that _mesa_warning() be defined.
The real definition of _mesa_warning() is in mesa/main/errors.c, but to
pull that file into the standalone scaffolding would require transitively
pulling in the dispatch tables.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
For each function {pack,unpack}{Snorm,Unorm,Half}2x16, add a corresponding
opcode to enum ir_expression_operation. Validate the new opcodes in
ir_validate.cpp.
Also, add opcodes for scalarized variants of the Half2x16 functions. (The
code generator for the i965 fragment shader requires that all vector
operations be scalarized. A lowering pass, to be added later, will
scalarize the Half2x16 functions).
v2: Fix assertion message in ir_to_mesa [for idr].
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Tuner <mattst88@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
For each of the following functions, add a declaration to
builtins/profiles/300es.glsl and create new file
builtins/ir/${funcname}.ir:
packSnorm2x16 unpackSnorm2x16
packUnorm2x16 unpackUnorm2x16
packHalf2x16 unpackHalf2x16
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Tuner <mattst88@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
s/num_operands()/get_num_operands()/
Discovered because Eclipse failed to resolve the false reference.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The bug: The printed horizontal stride was the numerical value of the
BRW_HORIZONTAL_$N enum.
The fix: Translate the enum before printing.
Note: This is a candidate for the stable releases.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
When possible, glCopyTexSubImage calls are performed using the
hardware blitter. However, according to the Ivy Bridge PRM, Vol1
Part4, section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities of
graphics data. Any graphics data read from and written to the
destination is permitted to represent a number of pixels that
occupies up to 65,536 scan lines and up to 32,768 bytes per scan
line at the destination. The maximum number of pixels that may be
represented per scan line’s worth of graphics data depends on the
color depth.
With an RGBA32F color buffer (which has 16 bytes per pixel) this
imposes a maximum width of 2048 pixels. Other pixel formats have
accordingly larger limits.
To make matters worse, if the pitch of the buffer is 32k or greater,
intel_copy_texsubimage's call to intelEmitCopyBlit will overflow
intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are
16-bit signed integers).
We can conveniently avoid both problems by avoiding use of the blitter
when the miptree's pitch is >= 32k.
Fixes gles3conform "framebuffer_blit_functionality_magnifying_blit"
tests when the buffer width is equal to 8192.
Note: this is very similar to the recent patch "intel: Fix ReadPixels
on buffers whose width >= 32kbytes" except that it applies to
glCopyTexSubImage instead of glReadPixels. In a future patch it would
be nice to refactor the code so that (a) overflow is avoided, and (b)
intelEmitCopyBlit is responsible for checking whether the blitter can
handle the width, so that all callers of intelEmitCopyBlit work
properly, rather than just these two.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously I thought that varying structs had been added to GLSL ES
3.00 by mistake, because chapter 11 of the GLSL ES 3.00 spec
("Counting of Inputs and Outputs") failed to mention how structs
should be handled. Khronos has clarified
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9828) that varying
structs are indeed required, and that chapter 11 will be modified to
indicate that the minimal reference packing algorithm flattens varying
structs to their individual components.
Mesa doesn't flatten varying structs to their individual components,
but this is ok, since it packs varyings of all kinds with no wasted
space at all (except where this is impossible due to differing
interpolation modes), so it will outperform the minimal reference
packing algorithm in all but the most pathological cases.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
It is not clear from the GLSL ES 3.00 spec how transform feedback is
supposed to apply to varying structs:
- There is no specification for how the structure is to be packed when
it is recorded into the transform feedback buffer.
- There is no reasonable value for GetTransformFeedbackVarying to
return as the "type" of the variable.
We currently have a Khronos bug requesting clarification on how this
feature is supposed to work
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9856).
This patch just disables transform feedback of varying structs for
now; we can implement the proper behaviour once we find out from
Khronos what it is.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch adds code to lower_packed_varyings to handle varyings of
type struct. Varying structs are currently packed in the most naive
possible way (in declaration order, with no gaps), so there is a
potential loss of runtime efficiency. In a later patch it would be
nice to replace this with a "flattening" approach (wherein a varying
struct is flattened to individual varyings corresponding to each of
its structure elements), so that the linker can align each structure
element independently. However, that would require a significantly
more complex implementation.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch paves the way for allowing varying structs by generalizing
varying_matches::compute_packing_order to handle any type of varying.
Previously, we packed in the order (vec4, vec2, float, vec3), with
matrices being packed according to the size of their columns. Now, we
pack everything according to its number of components mod 4, in the
order (0, 2, 1, 3).
There is no behavioural change for vectors. Matrices are now packed
slightly differently:
- mat2x2 gets assigned PACKING_ORDER_VEC4 instead of
PACKING_ORDER_VEC2. This is slightly better, because it guarantees
that the matrix occupies a single varying slot.
- mat2x3 gets assigned PACKING_ORDER_VEC2 instead of
PACKING_ORDER_VEC3. This is kind of a wash. Previously, mat2x3 had
a 25% chance of having neither of its columns double parked, a 50%
chance of having exactly one of its columns double parked, and a 25%
chance of having both of its columns double parked. Now it always
has exactly one of its columns double parked.
- mat3x3 gets assigned PACKING_ORDER_SCALAR instead of
PACKING_ORDER_VEC3. This doesn't affect much, since in both cases
there is no guarantee of how the matrix will be aligned.
- mat4x2 gets assigned PACKING_ORDER_VEC4 instead of
PACKING_ORDER_VEC2. This is slightly better for the same reason as
in mat2x2.
- mat4x3 gets assigned PACKING_ORDER_VEC4 instead of
PACKING_ORDER_VEC3. This is slightly better for the same reason as
in mat2x2.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Previously, it didn't matter whether structure splitting tried to
split shader ins/outs, because structs were prohibited from being used
for shader ins/outs. However, GLSL 3.00 ES supports varying structs.
In order for varying structs to work, we need to make sure that
structure splitting doesn't get applied to them, because if it does,
then the linker won't be able to match up varyings properly.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch replaces the three ir_variable_mode enums:
- ir_var_in
- ir_var_out
- ir_var_inout
with the following five:
- ir_var_shader_in
- ir_var_shader_out
- ir_var_function_in
- ir_var_function_out
- ir_var_function_inout
This eliminates a frustrating ambiguity: it used to be impossible to
tell whether an ir_var_{in,out} variable was a shader in/out or a
function in/out without seeing where the variable was declared in the
IR. This complicated some optimization and lowering passes, and would
have become a problem for implementing varying structs.
In the lisp-style serialization of GLSL IR to strings performed by
ir_print_visitor.cpp and ir_reader.cpp, I've retained the names "in",
"out", and "inout" for function parameters, to avoid introducing code
churn to the src/glsl/builtins/ir/ directory.
Note: a couple of comments in the code seemed to indicate that we were
planning for a possible future in which geometry shaders could have
shader-scope inout variables. Our GLSL grammar rejects shader-scope
inout variables, and I've been unable to find any evidence in the GLSL
standards documents (or extensions) that this will ever be allowed, so
I've eliminated these comments.
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The case statement purported to handle the addition of ir_var_const_in
and ir_var_inout builtin variables. But no such variables exist.
This patch removes the unnecessary cases, and adds a comment
explaining why they're not needed.
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
For texelFetchOffset(), we just add the texel offsets to the coordinate
rather than using the message header's offset fields. So we don't
actually need a header on Gen5+.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
When possible, glReadPixels calls are performed using the hardware
blitter. However, according to the Ivy Bridge PRM, Vol1 Part4,
section 1.2.1.2 (Graphics Data Size Limitations):
The BLT engine is capable of transferring very large quantities of
graphics data. Any graphics data read from and written to the
destination is permitted to represent a number of pixels that
occupies up to 65,536 scan lines and up to 32,768 bytes per scan
line at the destination. The maximum number of pixels that may be
represented per scan line’s worth of graphics data depends on the
color depth.
With an RGBA32F color buffer (which has 16 bytes per pixel) this
imposes a maximum width of 2048 pixels.
To make matters worse, if the pitch of the buffer is 32k or greater,
intel_miptree_map_blit's call to intelEmitCopyBlit will overflow
intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are
16-bit signed integers).
We can conveniently avoid both problems by avoiding the readpixels
blit path when the miptree's pitch is >= 32k.
Fixes gles3conform "half_float" tests when the buffer width is greater
than 2048.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
This reverts commit 7824ab8070.
Now that we force linking with LLVM shared libs when building clover,
we can link against libgallium.la with no problems.
If we build clover with LLVM static libraries, then clover and also each
pipe_*.so driver that is built will contain their own static copy of
LLVM. The recent automake changes have uncovered a problem where
the pipe_*.so drivers try to use clover's LLVM symbols. This causes
LLVM's static registry objects to be initialized each time
a pipe_*.so driver is loaded by clover. Initializing these objects
multiple times is not allowed and leads to assertion failures in the
LLVM code.
We can avoid all these problems by having clover and all the pipe_*.so
drivers link against the same LLVM shared library.
https://bugs.freedesktop.org/show_bug.cgi?id=59334https://bugs.freedesktop.org/show_bug.cgi?id=59534
v2:
- Fix shared library detection when LLVM is built with CMake
In order to determine which static LLVM libraries are needed we pass
a list of components to llvm-config and it generates the list of
library dependencies for us. The advantage of only calling llvm-config
one time is that it can determine if two components depend on the same
library and then add it to the output list only once. The old practice
of having each driver call llvm-config to add its own dependencies to
$(LLVM_LIBS) caused many libraries to be added to this variable multiple
times.
Always enable the use of pre-compressed texture data. The ability to
perform on-line compression still requires the presence of libtxc_dxtn
or an explicit driconf over-ride. Applications that just want to submit
precompessed data when an on-line compressor is not available can look
for the GL_EXT_texture_compression_dxt1 and
GL_ANGLE_texture_compression_dxt[35] extensions.
v2: Only enable the extensions that do not require on-line compression
by default. The previous statement "This should not impact many (if
any) real applications." proved to be false for at least Sauerbraten.
This application mostly submits pre-compressed data, but it also can
submit uncompressed data that it asks the driver to compress.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [v1]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Acked-by: Eric Anholt <eric@anholt.net> [v1]
Acked-by: Lee Salzman <lsalzman@gmail.com>
This is technically outside the ANGLE spec, but it seems unlikely to
cause any harm.
v2: Simplify the extension checks by assuming the ANGLE extension will
always be enabled by any driver that enables the EXT. Suggested by
Eric Anholt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Lee Salzman <lsalzman@gmail.com>
For non-generic compressed format we assert two things:
1. The format has already been validated against the set of available
extensions.
2. The driver only enables the extension if it supports all of the
formats that are part of that extension.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Similar to the previous commit, we may be using a texture with actual RGBA
storage for the GL_ALPHA format, so force the color values to 0.0.
This commit fixes the following piglit (sub) tests:
EXT_texture_snorm/fbo-blending-formats
GL_ALPHA16_SNORM
GL_ALPHA8_SNORM
GL_ALPHA_SNORM
Note: Haswell bypasses this swizzle code, so may require an independent fix
for this bug.
Reviewed-by: Eric Anholt <eric@anholt.net>
We may be using a texture with actual RGBA storage for these formats, so force
the alpha value read to 1.0.
This commit fixes the following piglit (sub) tests:
ARB_texture_float/fb-blending-formats
GL_RGB16F_ARB
EXT_framebuffer_object/fbo-blending-formats
GL_RGB10
GL_RGB12
GL_RGB16
EXT_texture_snorm/fbo-blending-formats
GL_RGB16_SNORM
GL_RGB8_SNORM
GL_RGB_SNORM
These test improvements depend on the previous commit as well. That commit
smashes alpha to 1.0 for the case of ReadPixels (so fixes "FBO testing" as
reported by this test), while this commit smashes alpha to 1.0 for the case of
texturing (fixed the "window testing" as reported by this test).
Note: Haswell bypasses this swizzle code, so may require an independent fix
for this bug.
Reviewed-by: Eric Anholt <eric@anholt.net>
When performing a ReadPixels operation, we may be reading from a buffer that
stores alpha values, but that is actually representing a buffer with no alpha
channel. In this case, while rebasing the values, touch up all alpha values
read to 1.0.
This commit fixes the following piglit (sub) tests:
ARB_texture_float/fbo-colormask-formats
GL_RBG16F_ARB
EXT_texture_snorm/fbo-colormask-formats
GL_RGB16_SNORM
GL_RGB8_SNORM
GL_RGB_SNORM
It likely improves the results of other tests as well, but a PASS remains
elusive due to additional bugs.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The renderbuffer's Format field may have an alpha channel even when the
underlying _BaseFormat does not. This can happen when mesa chooses to use
RGBA16 for an RGB16 format, for example.
So look at _BaseFormat when deciding whether to fixup the blend factors.
This test improves the results of at least the following piglit tests:
EXT_frambebuffer_object/fbo-blending-formats
{GL_RGB10, GL_RGB12, GL_RGB16}
EXT_texture_snorm/fbo-blending-formats
{GL_RGB16_SNORM, GLRGB8_SNORM, GL_RGB_SNORM}
But none of these actually change from FAIL to PASS yet. The R, G, and B probe
values are fixed with this commit, but the tests still fail because the alpha
values are still wrong.
Reviewed-by: Eric Anholt <eric@anholt.net>
/ vs \ mismatch was causing .objs to be put in the source tree, causing
breakeage when doing different build types in the same tree (eg., debug
vs release).
Fix this by normalizing everything to / slashes.
It's probably a good idea to purge all .objs from source tree to prevent
issues completely.
Thanks to Fredrik Höglund, all the hard work was already done.
Tested using a modified oglconform (that actually runs these tests on
our driver); it looks like there may be some bugs when using client
arrays. All applicable non-compatibility tests passed.
For now, only enable it in core profiles.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ian Romanick <idr@freedesktop.org>
Squashed with two reverts:
Revert "android: Update for builtin_stubs.cpp move"
This reverts commit c0def90ede.
Revert "scons: Update for builtin_stubs.cpp"
This reverts commit 8ac4b82699.
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Tested-on-Android-by: Chad Versace <chad.versace@linux.intel.com>
I don't see how this could have ever worked right.
The screen-space interpolation code uses the vertex->data[pos_attr]
position which contain window coords. But window coords are only
computed for the unclipped vertices; the clipped vertices have
undefined window coords (see draw_cliptest_tmp.h).
Use the vertex clip coords instead which are always defined.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=55476
(piglit fbo-blit-stretch failure on softpipe)
Note: This is a candidate for the 9.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
In debug builds, set clipped vertex window coordinates to NaN values
to help debugging. Otherwise, we're just leaving the coordinate in clip
space and it's invalid to use it later expecting it to be a window coord.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Fixes piglit spec/ARB_sampler_objects/sampler-incomplete and
spec/EXT_texture_swizzle/depth_texture_mode_and_swizzle.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This error was added in the 3.0.1 update to the OpenGL ES 3.0 spec.
Fixes the updated gles3conform packed_depth_stencil_parameters test.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes gles3conform test CoverageES30. It temporarily regresses some
framebuffer_blit tests, but the failing subcases have been determined to
be invalid for OpenGL ES 3.0.
v2: Fix typo in depth (and stencil) RB checking. Noticed by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
These were introduced in 2000 during a rework of the TNL module (commit
cab974cf6c), though I'm having a hard time
finding an instance there of one of these Exec functions being changed
at runtime.
Regardless, as far as I can tell now, these functions don't get changed,
by grepping for calls to SET_* to change the dispatch table (we do change
functions in GLvertexformat at runtime, but those don't overlap with
this set of functions). Remove them and just let them be initialized to
the same functions as are in the Exec table.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This cuts out a ton of code to make functions not set to a save_ variant
match.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This will let us copy from the Exec dispatch to deal with our commands that
don't get compiled into display lists.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I want to drive the Save dispatch table setup from this same function.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
All callers are in Mesa core and all use _gloffset_COUNT, so just rely on
the already baked-in use of _gloffset_COUNT in the function.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We now have a separate dispatch table for begin/end that prevent these
functions from being entered during that time. The
ASSERT_OUTSIDE_BEGIN_END_WITH_RETVALs are left because I don't want to
change any return values or introduce new error-only stubs at this
point.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is a step toward getting rid of ASSERT_OUTSIDE_BEGIN_END() in Mesa.
v2: Finish create_beginend_table() comment, move loopback API init into it,
and add a const flag. (suggestions by Brian)
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
My change 7ca4f07b5b caused errors to not
be thrown when they should, because the new if statement for ExecuteFlag
made the CurrentSavePrimitive not get set. And on further review, we
shouldn't be validating our primitive in GL_COMPILE mode, since the
command shouldn't be executed yet.
Partially fixes piglit gl-1.0-beginend-coverage.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This reduces jitter slightly in a cleaner way, without desynchronizing mplayer2 as badly
when falling behind.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
It appears that scons implicit dependency scanners fail to chain
dependencies of generated headers when these are outside the build tree.
This patch ensures generated source files are _always_ put in the build
tree. I'm not 100% this will fix all depency issues, but from my
experiments it does seem to fix this.
NOTE: For this to be effective it is necessary to clean the source tree
from generated header/source files.
Reviewed-by: Brian Paul <brianp@vmware.com>
There really isn't any point. There is no resource savings, and we have
to do gymnastics in the driver to make it work.
There are also bad interactions with multisampling and OpenGL ES 3.0.
In ES3, a multisample-to-singlesample blit must have identical source
and destination format. This means a multisample RGBA8 to singlesample
RGB8 (window) blit will generate an error. Also in ES3, RGB8 is not a
renderable format. This means that the application CANNOT make an RGB8
multisample renderbuffer.
As a result, if an application gets an RGB8 window and wants to do
multisample FBO rendering, it will probably break.
"Fixes" gles3conform
framebuffer_blit_functionality_multisampled_to_singlesampled_blit test
on RGB8 visuals.
v2: Fix 'formats' array size. Suggested by Ken.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
[ Squashed port of the following r600g commits: - Michel Dänzer ]
commit 428e37c2da
Author: Marek Olšák <maraeo@gmail.com>
Date: Tue Oct 2 22:02:54 2012 +0200
r600g: add in-place DB decompression and texturing with DB tiling
The decompression is done in-place and only the compressed tiles are
decompressed. Note: R6xx-R7xx can do that only with Z16 and Z32F.
The texture unit is programmed to use non-displayable tiling and depth
ordering of samples, so that it can fetch the texture in the native DB format.
The latest version of the libdrm surface allocator is required for stencil
texturing to work. The old one didn't create the mipmap tree correctly.
We need a separate mipmap tree for stencil, because the stencil mipmap
offsets are not really depth offsets/4.
There are still some known bugs, but this should save some memory and it also
improves performance a little bit in Lightsmark (especially with low
resolutions; tested with Radeon HD 5000).
The DB->CB copy is still used for transfers.
commit e2f623f1d6
Author: Marek Olšák <maraeo@gmail.com>
Date: Sat Jul 28 13:55:59 2012 +0200
r600g: don't decompress depth or stencil if there isn't any
commit 43e226b6ef
Author: Marek Olšák <maraeo@gmail.com>
Date: Wed Jul 18 00:32:50 2012 +0200
r600g: optimize uploading depth textures
Make it only copy the portion of a depth texture being uploaded and
not the whole 2D layer.
There is also a little code cleanup.
commit b242adbe5c
Author: Marek Olšák <maraeo@gmail.com>
Date: Wed Jul 18 00:17:46 2012 +0200
r600g: remove needless wrapper r600_texture_depth_flush
commit 611dd52942
Author: Marek Olšák <maraeo@gmail.com>
Date: Wed Jul 18 00:05:14 2012 +0200
r600g: init_flushed_depth_texture should be able to report errors
commit 80755ff563
Author: Marek Olšák <maraeo@gmail.com>
Date: Sat Jul 14 17:06:27 2012 +0200
r600g: properly track which textures are depth
This fixes the issue with have_depth_texture never being set to false.
commit fe1fd67556
Author: Marek Olšák <maraeo@gmail.com>
Date: Sun Jul 8 03:10:37 2012 +0200
r600g: don't flush depth textures set as colorbuffers
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.
commit 5a17d8318e
Author: Marek Olšák <maraeo@gmail.com>
Date: Sun Jul 8 02:14:18 2012 +0200
r600g: flush depth textures bound to vertex shaders
This was missing/broken. There are also minor code cleanups.
commit dee58f94af
Author: Marek Olšák <maraeo@gmail.com>
Date: Sun Jul 8 01:54:24 2012 +0200
r600g: do fine-grained depth texture flushing
- 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)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Use r600_resource_texture::flished_depth_texture for GPU access, and
allocate it in the VRAM. For transfers we'll allocate texture in the GTT
and store it in the r600_transfer::staging.
Improves performance when flushed depth texture is frequently used by the
GPU, e.g. in Lightsmark
[ Ported from r600g commit 3770847960 ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
[ Squashed port of the following r600g commits: - Michel Dänzer ]
commit c1e8c845ea
Author: Marek Olšák <maraeo@gmail.com>
Date: Sat Jul 7 19:10:00 2012 +0200
r600g: inline r600_hw_copy_region
commit 4891c5dc64
Author: Marek Olšák <maraeo@gmail.com>
Date: Mon Jun 25 22:53:21 2012 +0200
r600g: inline r600_blit_push_depth and use resource_copy_region
We are going to have a separate resource for depth texturing and transfers
and this is just a transfer thing.
commit da98bb6fc1
Author: Marek Olšák <maraeo@gmail.com>
Date: Mon Jun 25 12:45:32 2012 +0200
r600g: split flushed depth texture creation and flushing
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Allow additional format/type combinations based on the
color render buffer to fix failures with gles3-gtf.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
For GLES2/3 allow reading of pixels with format/type based on:
* GL_IMPLEMENTATION_COLOR_READ_FORMAT
* GL_IMPLEMENTATION_COLOR_READ_TYPE
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
[mattst88] v2: Enable only for ES3 per spec.
[mattst88] v3: Use _mesa_is_gles3 since EXT_color_buffer_float is
ES3-only.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
For now I'm just enabling this on the same subset of hardware that has
OpenGL 3.0 enabled. This same functionality is part of OpenGL 3.0, and
there is no matching desktop extension.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
They're part of GL_OES_depth_texture_cube_map, and we'll always enable
that extension in ES3 contexts.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The vs part hasn't been wired up since tgsi_sse2 was disabled in:
commit 4eb3225b38
Author: José Fonseca <jose.r.fonseca@gmail.com>
Date: Tue Nov 8 00:10:47 2011 +0000
Remove tgsi_sse2.
And it would certainly not work correctly in its current state:
draw/draw_vs_ppc.c: In function ‘draw_create_vs_ppc’:
draw/draw_vs_ppc.c:190:24: warning: assignment from incompatible pointer
type [enabled by default]
As with the sse2 backend, this should be done in llvm anyway.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
configure should warn if libxml2 is not found.
libxml2 is needed by glapi/gen.
Fixes error during build in src/mapi/glapi/gen:
ImportError: No module named libxml2
NOTE: This is a candidate for the 9.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31598
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is required by OpenGL ES 3.0 and desktop OpenGL 4.2. Previous
version were ambiguous. This also matches the behavior of NVIDIA's
closed-source driver (version 304.64).
Fixed gles3conformance test uniform_buffer_object_getactiveuniformsiv
and uniform_buffer_object_structure_and_array_element_names (on my
in-progress branch that fixes a bunch of other stuff...YMMV).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is required by OpenGL ES 3.0 and desktop OpenGL 4.2. Previous
version were ambiguous. This also matches the behavior of NVIDIA's
closed-source driver (version 304.64).
Fixed gles3conformance test uniform_buffer_object_getactiveuniform.
Several piglit tests expect glGetActiveUniform to *not* include the [0]
on the end. These tests were already failing on NVIDIA, and this change
regresses them on Mesa. Patches have been sent to the piglit mailing
list to fix the tests.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We currently have a bug in this code, and I don't want to fix it in two
places.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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>
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>
Use this method in _mesa_GetInternalformativ for both GL_SAMPLES and
GL_NUM_SAMPLE_COUNTS.
v2: internalFormat may not be color renderable by the driver, so zero
can be returned as a sample count. Require that drivers supporting the
extension provide a QuerySamplesForFormat function. The later was
suggested by Eric Anholt.
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>
Though, I'm tempted to always expose this extension when
GL_ARB_framebuffer_object is exposed. In that case, it would share the same
enable bit.
v2: Correctly sort extension names. Suggested by Eric Anholt.
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>
This is for the GL_ARB_internalformat_query extension and GLES 3.0.
v2: Generate GL_INVALID_OPERATION if the extension is not supported.
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>
OpenGL 4.2 specification suggests rounding the float data to nearest
integer when the type of internal state is integer. Out of range floats
should be clamped to {INT_MIN, INT_MAX}. This is not specified anywhere
in gl/gles spec but below test expects this behavior. This patch makes
gles3 conformance sgis_texture_lod_basic_getter.test pass.
A GL spec bug will be raised to include clamping of out of range floats.
V2: Round float to nearest integer for all cases where
_mesa_Texparameterf() converts float param to int. Use the same block of
float to int conversion code for GL_TEXTURE_SWIZZLE_{R,G,B,A}_EXT cases
as well.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch fixes a blitting case when drawAttachment->Texture ==
readAttachment->Texture. It was causing an assertion failure in
intel_miptree_attach_map() with gles3 conformance test case:
framebuffer_blit_functionality_minifying_blit
Number of changes in this file look scary. But most of them are caused
by introducing a big for loop to support rendering to multiple color
draw buffers.
V2: Fixed a case when number of draw buffer attachments are zero.
V3: Put a for loop in blit_nearest() and blit_linear() functions in to
support blitting to multiple color draw buffers.
V4: Remove variable declaration in for loop to avoid MSVC compilation
issues.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch adds required error checking in _mesa_BlitFramebuffer() when
blitting to multiple color render targets. It also fixes a case when
blitting to a framebuffer with renderbuffer/texture attached to
GL_COLOR_ATTACHMENT{i} (where i!=0). Earlier it skips color blitting if
nothing is found attached to GL_COLOR_ATTACHMENT0.
V2: Fixed a case when number of draw buffer attachments are zero.
V3: Do compatible_color_datatypes() and compatible_resolve_formats()
check for all the draw renderbuffers in fbobject.c. Fix debug code
at bottom of _mesa_BlitFramebuffer() to handle MRTs. Combine error
checking code for linear blits with other color blit error checking.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This allows query on default framebuffer in
glGetFramebufferAttachmentParameteriv() for gles3. Fixes unexpected GL
errors in gles3 conformance test case:
framebuffer_blit_functionality_multisampled_to_singlesampled_blit
V2: Use _mesa_is_gles3() check to restrict allowed attachment types to
specific APIs.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch enables blitting to multiple color attachments of a
framebuffer. It also fixes a case when blitting to a framebuffer with
renderbuffer/texture attached to non-zero attachment point
i.e. GL_COLOR_ATTACHMENT{1, 2, ...}. Earlier we were incorrectly
blitting to GL_COLOR_ATTACHMENT0 by default.
V2: Use intel_copy_texsubimage() for blitting only if all the color
attachments can blit using it.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This patch rewrites _mesa_meta_BlitFrameBuffer() function to add support
for blitting with GLSL/GLSL ES shaders. These changes were required to
support glBlitFrameBuffer() in gles3. This patch, along with other
patches in this series, make 16 failing framebuffer_blit test cases in
gles3 conformance pass.
V2: Properly handle flipped blits for source and destination
renderbuffer / textures. Add support for GL_TEXTURE_RECTANGLE in
_mesa_meta_BlitFrameBuffer. Create a temp depth texture to support
depth buffer blitting.
V3: Remove unsupported / redundant shader code. Add an assertion to make
sure that we don't use rectangle texture in ES. Put API guard on
glTexEnvi().
V4: For gles3: Don't use ReadPixels or CopyTexImage2D to blit depth
buffer. gles3 spec says for CopyTexImage2D that "color buffer
components can be dropped during the conversion to internalformat,
but new components cannot be added." So, use the internal format of
read renderbuffer to create texture for color buffer blitting.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
V2:
If mask has GL_STENCIL_BUFFER_BIT set, the depth formats for
readRenderBuffer and drawRenderBuffer must match unless one of the two
buffers doesn't have depth, in which case it's not blitted, so the
format check should be ignored. Same comment goes for stencil formats
in depth renderbuffers if mask has GL_DEPTH_BUFFER_BIT set.
v3 (Kayden): Refactor code to be a bit more readable.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In ES 3.0, when calling glDrawBuffers() on the window system
framebuffer, the only valid targets are GL_NONE or GL_BACK. Since there
is no stereo rendering in ES 3.0, this is a single buffer, unlike
desktop where it may be two (and thus isn't allowed).
For single-buffered configs, GL_BACK ironically means the front (and
only) buffer. I'm not sure that it matters, however, as ES shouldn't
have front buffer rendering in the first place.
Fixes es3conform framebuffer_blit_coverage_default_draw_buffer_binding.
v2: Update GLES3 spec reference.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> [v2]
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
I didn't notice this due to a noobed piglit run. It wasn't previously
noticed because the patch was only run on a driver that supported GLES3.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
At process exit DLL_PROCESS_DETACH is signaled to DllMain(), where then
a final cleanup is triggered. In stw_cleanup() code is triggered that
tries to communicate a shutdown to the spawned threads -- however at
that time those threads have already been terminated by the OS and so
the process hangs.
v2: skip stw_cleanup_thread() too
Signed-off-by: José Fonseca <jfonseca@vmware.com>
Fixes error EGL_BAD_ATTRIBUTE in the tests below on Intel Sandybridge:
* piglit egl-create-context-verify-gl-flavor, testcase OpenGL ES 3.0
* gles3conform, revision 19700, when runnning GL3Tests with -fbo
This plumbing is added in order to comply with the EGL_KHR_create_context
spec. According to the EGL_KHR_create_context spec, it is illegal to call
eglCreateContext(EGL_CONTEXT_MAJOR_VERSION_KHR=3) with a config whose
EGL_RENDERABLE_TYPE does not contain the EGL_OPENGL_ES3_BIT_KHR. The
pertinent
portion of the spec is quoted below; the key word is "respectively".
* If <config> is not a valid EGLConfig, or does not support the
requested client API, then an EGL_BAD_CONFIG error is generated
(this includes requesting creation of an OpenGL ES 1.x, 2.0, or
3.0 context when the EGL_RENDERABLE_TYPE attribute of <config>
does not contain EGL_OPENGL_ES_BIT, EGL_OPENGL_ES2_BIT, or
EGL_OPENGL_ES3_BIT_KHR respectively).
To create this patch, I searched for all the ES2 bit plumbing by calling
`git grep "ES2_BIT\|DRI_API_GLES2" src/egl`, and then at each location
added a case for ES3.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
If the hardware/driver combo supports GLES3, then set the GLES3 bit in
intel_screen's bitmask of supported DRI API's. Neither the EGL nor GLX
layer uses the bit yet.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This enum corresponds to EGL_OPENGL_ES3_BIT_KHR.
Neither the GLX nor EGL layer use the enum yet.
I don't like the GLES bits. I'd prefer that all GLES APIs be exposed
through a single API bit, as is done in GLX_EXT_create_context_es_profile.
But, we need this GLES3 enum in order to do the plumbing necessary to
correctly support EGL_OPENGL_ES3_BIT_KHR as required by the
EGL_KHR_create_context spec.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Each driver (i830, i915, i965) used independent but similar code to
validate the requested context version. With the rececnt arrival of GLES3,
that logic has needed an update. Rather than apply identical updates to
each drivers validation code, let's just move the validation into the
shared routine intelInitContext.
This refactor required some incidental changes to functions
i830CreateContext and intelInitContext. For each function, this patch:
- Adds context version parameters to the signature.
- Adds a DRI_CTX_ERROR out param to the signature.
- Sets the DRI_CTX_ERROR at each early return.
Tested against gen6 with piglit egl-create-context-verify-gl-flavor.
Verified that this patch does not change the set of exposed EGL context
flavors.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Before this patch, intelInitScreen2 set DRIScreen::api_mask with the hacky
heuristic below:
if (gen >= 3)
api_mask = GL | GLES1 | GLES2;
else
api_mask = 0;
This hack was likely broken on gen2 (i830), but I don't care enough to
properly investigate. It appears that every EGLConfig on i830 has
EGL_RENDERABLE_TYPE=0, and thus eglCreateContext will never succeed.
Anyway, moving on to living drivers...
With the arrival of EGL_OPENGL_ES3_BIT_KHR, this heuristic is now
insufficient. We must enable the GLES3 bit if and only if the driver is
capable of creating a GLES3 context. This requires us to determine the
maximum supported context version supported by the hardware/driver for
each api *during initialization of intel_screen*.
Therefore, this patch adds four new fields to intel_screen which indicate
the maximum supported context version for each api:
max_gl_core_version
max_gl_compat_version
max_gl_es1_version
max_gl_es2_version
The api mask is now correctly set as:
api_mask = GL;
if (max_gl_es1_version > 0)
api_mask |= GLES1;
if (max_gl_es2_version > 0)
api_mask |= GLES2;
Tested against gen6 with piglit egl-create-context-verify-gl-flavor.
Verified that this patch does not change the set of exposed EGL context
flavors.
v2:
- Replace the if-tree on gen with a switch, for Ian.
- Unconditionally enable the DRI_API_OPENGL bit, for Ian.
v3:
- Drop max gl version to 1.4 on gen3 if !has_occlusion_query,
because occlusion queries entered core in 1.5. For Ian.
v4:
- Drop ES2 version back to 2.0 due to rebase (Ian).
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick.intel.com>
I'm not sure if this is the correct fix. The
_mesa_es_error_check_format_and_type function (used above in the ES 1
and 2 cases) was originally added for glTexImage checking and allows
GL_DEPTH_STENCIL/GL_UNSIGNED_INT_24_8 combinations. Using it in ES 3
causes other tests to regress.
Fixes es3conform's packed_depth_stencil_error test.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
INVALID_ENUM is for when the type is simply not known.
Fixes part of es3conform's packed_depth_stencil_error test.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
ES 3 specifies some formats as texture-only (i.e., not available for
renderbuffers).
See the "Required Texture Formats" section (pg 126) of the ES 3 spec.
v2: Allow RED and RG float rendering in core profiles The check used to
be (version > 30) || (compat profile w/extensions). Just deleting
<version > 30) broke 3.0+ core profiles.
Fixes es3conform's color_buffer_unsupported_format test.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
According to both the GL 3.0 and ES 3.0 specifications (table 2.7 for GL
and table 2.8 for ES), the default value of BUFFER_ACCESS_FLAGS is
supposed to be zero.
Note that there are two related quantities: the obsolete BUFFER_ACCESS
enum and the new BUFFER_ACCESS_FLAGS bitfield.
BUFFER_ACCESS can only be GL_READ_ONLY, GL_WRITE_ONLY, or GL_READ_WRITE;
BUFFER_ACCESS_FLAGS can easily represent all three via GL_MAP_WRITE_BIT,
GL_MAP_READ_BIT, and their logical or. It also supports more flags.
Thus, Mesa only stores the bitfield, and simply computes the old enum
when queried, via simplified_access_mode(bufObj->AccessFlags).
The tricky part is that, while BUFFER_ACCESS_FLAGS defaults to 0,
BUFFER_ACCESS defaults to GL_READ_WRITE for desktop [GL 3.0, table 2.8]
and GL_WRITE_ONLY_OES for ES [the GL_EXT_map_buffer_range extension].
Mesa tried to implement this by setting the default AccessFlags to
GL_MAP_READ_BIT | GL_MAP_WRITE_BIT on desktop, and GL_MAP_WRITE_BIT on
ES. But in all specifications, it needs to be 0.
This patch moves that logic into simplified_access_mode(): when
AccessFlags == 0, it now returns GL_READ_WRITE for desktop and
GL_WRITE_ONLY for ES 1/2. (BUFFER_ACCESS doesn't exist on ES 3.0,
so it's irrelevant there.)
With that in place, it changes the AccessFlags default to 0.
Fixes three es3conform tsets:
- copy_buffer_defaults
- map_buffer_range_modify_indices
- pixel_buffer_object_default_parameters
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Perhaps most importantly, this patch adds comments quoting the relevant
spec paragraphs above each error condition.
It also makes three changes:
- For FBOs, GL_COLOR_ATTACHMENTm where m >= MaxDrawBuffers is supposed
to generate INVALID_OPERATION (not INVALID_ENUM).
- Constants that refer to multiple buffers (such as FRONT, BACK, LEFT,
RIGHT, and FRONT_AND_BACK) are supposed to generate INVALID_OPERATION,
not INVALID_ENUM.
- In ES 3.0, for FBOs, buffers[i] must be NONE or GL_COLOR_ATTACHMENTi
or else INVALID_OPERATION occurs. (This is a new restriction.)
Fixes es3conform's draw-buffers-api test.
v2: The error path was missing a "return" like all the other error
paths. Also, we may as well call it glDrawBuffers in the error message
since the ARB suffix doesn't exist in ES 3.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The specification requires that query results are processed in order, (when
one query result is returned, all previous query of the same type must also be
available). The implementation was failing this requirement in the case of
BeginQuery and EndQuery with no intervening drawing, (the result would be made
available immediately without flushing previous queries).
This fixes the following es3conform test:
occlusion_query_query_order
as well as the following piglit test:
occlusion_query_order
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This allows for avoiding the occlusion query erroneously accumulating results
during the meta operation. This functionality is made conditional on a new
MESA_META_OCCLUSION_QUERY bit so that meta-operations which should generate
fragments can continue to get the current behavior.
The implementation of glClear is specifically augmented to request the flag
since glClear is specified to not generate fragments.
This fixes the following es3conform tests:
occlusion_query_draw_occluded.test
occlusion_query_clear
occlusion_query_custom_framebuffer
occlusion_query_stencil_test
occlusion_query_discarded_fragments
As well as the following piglit test:
occlusion_query_meta_no_fragments
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This flag allows for the specified behavior that GenQueries reserves a name,
but does not associate an object with it until BeginQuery. We allocate the
object immediately with the new EverBound flag set to false, and then set the
flag to true at the time of BeginQuery.
This allows us to implement a conformant IsQuery function by checking the
state of the new EverBound flag.
This fixes the following es3conform tests:
occlusion_query_genqueries
occlusion_query_is_query_nonzero
and the following piglit test:
occlusion_query_lifetime
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The reference to "correct, see spec" was a bit too vague to be useful,
(particularly since the language being referenced here changes between OpenGL
3.1 and OpenGL 4.3).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These are optimizations which make MSAA a lot faster.
The MSAA work is complete with this commit. (except for enablement of AA
optimizations for RGBA16F, for which a patch is ready and waiting until
the kernel CS checker fix lands)
MSAA can't be made any faster as far as hw programming is concerned.
The catch is only one process and one colorbuffer can use the optimizations
at a time. There usually is only one MSAA colorbuffer, so it shouldn't be
an issue.
Also, there is a limit on the size of MSAA colorbuffer resolution in terms
of megapixels. If the limit is surpassed, the AA optimizations are disabled.
The limit is:
- 1 Mpix on low-end and some mid-level chipsets (1024x768 and 1280x720)
- 2 Mpix on some mid-level chipsets (1600x1200 and 1920x1080)
- 3 or 4 Mpix on high-end chipsets (2048x1536 or 2560x1600, respectively)
It corresponds to the number of raster pipes (= GB pipes) available, each pipe
can hold 1 Mpix of AA compression data.
If it's enabled, the driver prints to stdout:
radeon: Acquired access to AA optimizations.
This reverts commit 4148a29ed8.
This is a work-around for bug:
https://bugs.freedesktop.org/show_bug.cgi?id=59334
We really should be linking against libgallium.la instead of
libgallium.a, but until we can figure why linking against libgallium.la
causes runtime failures in clover we will continue to link against
libgallium.a
Acked-by: Andreas Boll <andreas.boll.dev@gmail.com>
Tested-by: Aaron Watry <awatry@gmail.com>
I think the conditional always evaluates to false.
If I understand the code in core Mesa correctly, depthBits or stencilBits
is 0 if the depth or stencil renderbuffer is NULL, respectively.
Reviewed-by: Brian Paul <brianp@vmware.com>
Since automake changes, softpipe and llvmpipe are mutually exclusive at link
time. This doesn't make much sense to me as we can choose between them at
run-time using GALLIUM_DRIVER.
Creating library file: .libs/libGL.dll.a
.libs/xlib.o: In function `sw_screen_create_named':
/jhbuild/checkout/mesa/mesa/src/gallium/targets/libgl-xlib/../../../../src/gallium/auxiliary/target-helpers/inline_sw_helper.h:35:
undefined reference to `_softpipe_create_screen'
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Brian Paul <brianp@vmware.com>
Call Driver.AllocTextureImageBuffer rather than calling
Driver.TexImage with NULL data, format=GL_NONE and type=GL_NONE.
This avoids setting ctx->Unpack, which can lead to incorrectly
trying to upload data.
The GLES3 GTF program's packed_pixels_pbo test was triggering
an error for i965 with the previous code.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This function checks for ES3 compatible
format/type/internalFormat/dimension combinations.
[jordan.l.justen@intel.com: additional tweaks for gles3-gtf]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes a runtime error:
glxgears: symbol lookup error: /home/brian/mesa/lib/gallium/libGL.so.1: undefined symbol: clock_gettime
v2: use $(CLOCK_LIB) and $(PTHREAD_LIBS) per Andreas Boll.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
The hardware does not support a render target without an alpha channel.
So when the user creates a render buffer with no alpha channel, there actually
is storage available for alpha internally. It requires special care to
avoid these unwanted alpha bits from causing any problems.
Specifically, when blending, and when the blend factors would read the
destination alpha values, this commit coerces the blend factors to instead be
either 0 or 1 as appropriate.
A similar fix was made for pre-gen6 hardware in commit eadd9b8e and this
commit shares the fixup function written by Ian then.
This commit the following es3conform test:
rgb8_rgba8_rgb
As well as the following piglit (sub) tests:
EXT_framebuffer_object/fbo-blending-formats/3
EXT_framebuffer_object/fbo-blending-formats/GL_RGB
EXT_framebuffer_object/fbo-blending-formats/GL_RGB8
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We used to keep the color buffers in the dri_buffers array and
swap __DRI_BUFFER_BACK_LEFT and __DRI_BUFFER_FRONT_LEFT around there
and swap third_buffer in in case we needed to triple buffer. That
gets a little fidgety with all the swaps, so lets use the
color_buffers pool like the gbm platform does. We track the color buffers,
their corresponding wl_buffer and locked status here and just plug
a free one into dri2_surf->buffers when we need to.
This is a nice clean-up in itself, but it also sets us up to track
buffer age in the color_buffers structs.
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
RB3D_DEBUG_CTL doesn't help, so I resolve to a tiled temporary texture and
then blitting it to the destination one, which we also do in other situations.
The handling of the CAP is broken in st/mesa anyway. Let's just kill it.
This commit pretty much enables fast Z clear for FBOs with Z24S8.
The driver falls back to clearing with a quad if the fast clear cannot be
used. It can still do fast color clear, for example.
Effectively this path would always assert. Move the break statement to
the (probable) intended place.
Note: This is a candidate for the stable branches.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Include LLVM_LDFLAGS when building with LLVM. Fixes the following build
errors:
CXXLD swrast_dri.la
/usr/bin/ld: cannot find -lLLVMR600CodeGen
/usr/bin/ld: cannot find -lLLVMR600Desc
/usr/bin/ld: cannot find -lLLVMR600Info
/usr/bin/ld: cannot find -lLLVMR600AsmPrinter
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
According to bug #54524, I regressed oglconform's multicontext test
when I reenabled the fragment shader precompile.
However, these test cases only passed by miraculous coincedence. We
assign each fragment program a unique ID (brw_fragment_program::id which
becomes brw_wm_prog_key::program_string_id) which we obtain by storing a
per-context counter.
The test case uses GLX context sharing to access the same fragment
program from two different contexts. This means that we share a program
cache. Before the precompile, if both contexts happened to use the same
shaders in the same order, we'd obtain the same program_string_ids (by
virtue of doing the same computation twice). However, the more likely
scenario is that they completely disagree on program_string_id.
This meant that we'd have two completely different fragment shaders in
the cache with the same ID, tricking us to think they were the same
(aside from NOS), so we'd render using the wrong program.
This patch implements a simple fix suggested by Eric: it moves the
global counter out of brw_context and into intel_screen, which is shared
across all contexts. A mutex protects it from concurrent access.
This is also the first direct usage of pthreads in the i965 driver.
Fixes 10 subcases of oglconform's multicontext test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54524
Reviewed-by: Eric Anholt <eric@anholt.net>
Technically, variable sized arrays are a required feature of C99,
redacted to be optional in C11, and not actually part of C++ whatsoever.
Gcc allows using them in C++ unless you specify -pedantic, and Clang
appears to allow them for simple/POD types.
exec_list is arguably POD, since it doesn't have virtual methods, but I
can see why Clang would be like "meh, it's a C++ struct, say no", seeing as
it's meant to support C99.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58970
Reviewed-by: Matt Turner <mattst88@gmail.com>
The simulator gets very angry about our i2b code:
cmp.ne(16) g3<1>D g2<0,1,0>D 0F
We can't mix integer DWord and float types. The only reason to use 0F
here was to share code with f2b. Split it and use 0D instead.
While we don't believe anything bad will actually happen because of
this, it's nice to fix the warnings and easy enough to do.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Often when debugging, I don't want to see SIMD16 shaders. It makes
INTEL_DEBUG=vs/fs output much easier to read, especially when a program
dumps many shaders. Plus, I also want to verify that SIMD8 works before
even considering SIMD16.
v2: Fix the likeliness check (caught by Chris and Eric).
Reviewed-by: Eric Anholt <eric@anholt.net>
Choose MESA_FORMAT_ARGB2101010 when storing
GL_RGBA + GL_UNSIGNED_INT_2_10_10_10_REV or
GL_RGB + GL_UNSIGNED_INT_2_10_10_10_REV.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The ARB_get_program_binary spec says "OpenGL 3.0 is required." The
nearly identical OES_get_program_binary extension is available for
OpenGL ES 2.0, so I don't see how / why OpenGL 3.0 is a requirement for
the ARB version. Let's just enable whenever GL_ARB_shader_objects is
available.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
After recent changes in the XML, the dispatch generators will expect
this function to be named _mesa_ProgramParameteri.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There were two bugs here. First, this and several other queries were
not available in a desktop GL context with GL_ARB_ES2_compatibility.
Second, GL_NUM_SHADER_BINARY_FORMATS returns zero, but
GL_SHADER_BINARY_FORMATS writes one element of data to the buffer. If
NUM is zero, no data should be written.
Fixes piglit test 'arb_get_program_binary-overrun shader'.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This adds TBO support to r600g, and with GLSL 1.40 enabled,
we now get 3.1 core profiles advertised for r600g.
The r600/700 implementation is a bit different from the evergreen one,
as r6/7 hw lacks vertex fetch swizzles. So we implement it by passing 5
constants per sampler to the shader, the shader uses the first 4 as masks
for each component and the 5th as the alpha value to OR in.
Now TXQ is also broken so we have to pass a constant for the buffer size,
on evergreen we just pass this, on r6/7 we pass it as the 6th element
in the const info buffer.
v1.1: drop return as DDX doesn't use a texture type
v2: add r600/700 support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds 12 more constant buffers for use as UBOs,
along with adding relative constant fetching for 2D indices.
This with GLSL 1.40 enabled passes all the same tests as softpipe
on my evergreen system.
Signed-off-by: Dave Airlie <airlied@redhat.com>
First we test that line continuations are honored within a comment, (as
recently changed in glcpp), then we test that line continuations can be
disabled via an option within the context. This is tested via the new support
for a test-specific command-line option passed to glcpp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, we were only supporting line-continuation backslash characters
within lines of pre-processor directives, (as per the specification). With
OpenGL 4.2 and GLES3, line continuations are now supported anywhere within a
shader.
While changing this, also fix a bug where the preprocessor was ignoring
line continuation characters when a line ended in multiple backslash
characters.
The new code is also more efficient than the old. Previously, we would
perform a ralloc copy at each newline. We now perform copies only at each
occurrence of a line-continuation.
This commit fixes the line-continuation.vert test in piglit.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow testing of disabled line-continuation on a case-by-case basis,
(with the option communicated to the preprocessor via the GL context).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This will allow the test exercising disabled line continuations to arrange
for the --disable-line-continuations argument to be passed to the standalone
glcpp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
As the preprocessor becomes more sophisticated and gains more optional
behavior, it's easiest to just pass the GL context pointer to it so that
it can examine any fields there that it needs to (such as API version,
or the state of any driconf options, etc.).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This application is known to contain shaders that:
1. Have a stray backslash as the last line of comment lines
2. Have a declaration immediately following that line
Hence, interpreting that backslash as a line continuation causes the
declaration to be hidden and the shader fails to compile. Fortunately, the
shaders also:
3. Do not have any other intentional line-continuation characters
So disabling line continuations entirely for the application fixes this
problem without causing any other breakage.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is to enable a quirk for Savage2 which includes a shader with a stray '\'
at the end of a comment line. Interpreting that backslash as a line
continuation will break the compilation of the shader, so we need a way to
disable this.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously this was happening unconditionally, leading to some excessive
rebuilding/relinking during builds.
Note that the .po files are not automatically updated due to changes to the
t_options.h file. Instead, translators should continue to use "make po"
manually. This is because after new strings are merged into the existing .po
file, manual work is still required by translators to ensure that the
translations are correct.
Previously, the xmlpool directory had a lone Makefile to assist poeple in
manually invoking a deep make in order to update the translations in
options.h. We can observe that this wasn't happening in fact, (new
translations had been added to de.po without being generated into options.h,
and new options had been manually added directly to options.h rather than to
t_options.h).
Prevent both of these problems from occurring in the future by automatically
generating options.h as part of the standard build of mesa.
For this, the generated options.h is now removed from version control, (along
with Makefile in favor of Makefile.am).
[chadv: Port the Autotools changes to Android.]
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
As can be seen, many other translation strings already include a single
apostrophe just fine without any escaping. This strangely-escaped apostrophe
was causing a build failure ("invalid escape sequence") resulting in no "de"
translations in the final options.h file.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The gen_xmlpool.py script would work correctly only when executed from the
directory that contained the script. This shortcoming was due to some
hard-coded paths in the script.
In order to easily invoke the script from the Android build system, we
must be able to execute the script from an arbitrary directory. To enable
that, this patch replaces the two hard-coded paths with new command line
arguments.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
These translations have existed in the de.po file, but were not in the
generated options.h file. This was fixed by simply running "make options.h".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
For the last two most-recently-added driconf options, their definition was
manually added to options.h, a file which is intended to be automatically
generated, (as part of support for translated driconf option
descriptions). This means that these options would be eliminated if the
generation step were performed again.
Fix this by correctly adding the definitions of these options to t_options.h,
(the file used as input to the generator), and not the options.h file, which
is generated.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes several duplicate symbol errors.
libllvmradeon is a simple helper library. If it requires symbols in
other libraries, this should be taken care of by the gallium target that
uses it (e.g. libr600.la)
This requires some derived state. The cut vertex used is either the
value specified by glPrimitiveRestartIndex or it's hard-coded to ~0.
The derived state gl_array_attrib::_RestartIndex captures this value.
In addition, the derived state gl_array_attrib::_PrimitiveRestart is set
whenever either gl_array_attrib::PrimitiveRestart or
gl_array_attrib::PrimitiveRestartFixedIndex is set.
v2: Use _mesa_is_gles3.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The GLSL ES 3.0 spec (Section 12.17) says:
"GLSL ES 1.00 removed token pasting and other functionality."
NOTE: This is a candidate for the stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Simply emitting a nicely-formatted error message if any undefined macro is
encountered in a parser context expecting an expression.
With this commit, the following piglit test now passes:
spec/glsl-es-3.00/compiler/undefined-macro.vert
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This can be triggered either by creation of a GLES context (with
api == API_OPENGLES2) or else by a #version directive with version
value 100 or with a string of "es" following the version value.
There's no behavioral change with this commit—just preparation for ES-specific
behavior in the preprocessor in the future.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes the following build error:
CXXLD egl_gallium.la
g++: error: ../../../../src/egl/wayland/wayland-drm/.libs/.libs/libwayland-drm.a: No
such file or directory
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
We get int/uint clear color value in this case, and util_pack_color can't
handle these formats at all (even if it could, float input color isn't what
we want).
Pass through the color union appropriately and handle the packing ourselves
(as I couldn't think of a good generic util solution).
This gets piglit fbo_integer_precision_clear and
fbo_integer_readpixels_sint_uint from the ext_texture_integer test group from
segfault to pass (which only leaves fbo-blending from that group not working).
v2: fix up comments
Need to bitcast the float border color (luckily we already get
the color as int just disguised as float).
Fixes piglit texwrap GL_EXT_texture_integer bordercolor.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Change the texel type to int/uint instead of float throughout the sampling
code which makes it easier to catch errors (as llvm will complain about wrong
types if we mistakenly treat these values as real floats somewhere).
This should also get things like e.g. sampler swizzles (for unused channels)
right.
This fixes piglit texture_integer_glsl130 test.
Border color not working (crashing) yet.
(These formats are not exposed yet in llvmpipe.)
v2: couple cleanups according to José's comments
Reviewed-by: José Fonseca <jfonseca@vmware.com>
C++ linking (controlled by the nodist_EXTRA idiom) is needed
unconditionally for:
nouveau (uses C++ in the driver)
r300 (since LLVM is always required)
radeonsi (since LLVM is always required)
swrast (if builting LLVM pipe)
and conditionally (depends whether LLVM is enabled) for
i915
r600
vmwgfx
and never needed for swrast (softpipe).
Unfortunately, automake seems to *always* link with C++ if nodist_EXTRA
is specified, even inside a false conditional. Not sure if this is a
bug, but it does seem to be weird behavior.
v2: Johannes Obermayr <johannesobermayr@gmx.de>
- Fix some undefined symbols.
v3: Johannes Obermayr <johannesobermayr@gmx.de>
- Install pipe_* to $(libdir)/gallium-pipe.
v4: Johannes Obermayr <johannesobermayr@gmx.de>
- Build it only once on --enable-gallium-gbm / --enable-opencl.
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- add missing xvmc state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing xvmc state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing xvmc state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing xvmc state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing vdpau state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing vdpau state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing vdpau state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing vdpau state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Andreas Boll <andreas.boll.dev@gmail.com>
- Add missing vdpau state tracker to _LIBADD variable
v3: Andreas Boll <andreas.boll.dev@gmail.com>
- Provide compatibility with scripts for the old Mesa build system
v2: Johannes Obermayr <johannesobermayr@gmx.de>
Fix some undefined symbols.
v3: Johannes Obermayr <johannesobermayr@gmx.de>
Build it -shared to fix egl_gallium.so on r600/radeonsi builds.
The function was named badly and wasn't in the dispatch table,
making it hard to find.
Fixes transform_feedback2_states and gets a few other transform
feedback tests closer to working in es3conform.
Reviewed-by Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
For glGetIntegerv, add support for the following in an OpenGL ES 3.0
context:
GL_MAJOR_VERSION
GL_MINOR_VERSION
GL_NUM_EXTENSIONS
See Table 6.29 of the OpenGL ES 3.0 spec.
Fixes error GL_INVALID_ENUM in piglit egl-create-context-verify-gl-flavor,
testcase for OpenGL ES 3.0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The ES 3 spec says that the minumum allowable value is 2^24-1, but the
GL 4.3 and ARB_ES3_compatibility specs require 2^32-1, so return 2^32-1.
Fixes es3conform's element_index_uint_constants test.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
From GL/GLES/GL_CORE and GLES2 -> GL/GL_CORE/GLES2.
Yes, we really were exposing ES2_compatibility queries on ES 1.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes the transform_feedback2_init_defaults test from es3conform.
The ES 3 spec lists these as TRANSFORM_FEEDBACK_PAUSED and
TRANSFORM_FEEDBACK_ACTIVE.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
but an MSAA resource is bound. This effectively makes the MSAA disable switch
not affect rasterization, but it still affects the alpha-to-one and
alpha-to-coverage states. This hardware just lacks a proper MSAA disable
switch.
This fixes graphics corruption in sauerbraten.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59194
In most cases, the width, height, and depth of the physical surface
used by the driver to implement a texture or renderbuffer is equal to
the logical width, height, and depth exposed to the client through
functions such as glTexImage3D(). However, there are two exceptions:
cube maps (which have a physical depth of 6 but a logical depth of 1)
and multisampled renderbuffers (which have larger physical dimensions
than logical dimensions to allow multiple samples per pixel).
Previous to this patch, we accounted for the difference between
physical and logical surface dimensions at inconsistent places in the
call graph (multisampling was accounted for in
intel_miptree_create_for_renderbuffer(), and cubemaps were accounted
for in intel_miptree_create_internal()). As a result, it wasn't
always clear, when calling a miptree creation function, whether
physical or logical dimensions were needed. Also, we weren't
consistent about storing logical dimensions in the intel_mipmap_tree
structure (we only did so in the
intel_miptree_create_for_renderbuffer() code path, and we did not
store depth).
This patch refactors things so that intel_miptree_create_internal() is
responsible for converting logical to physical dimensions and for
storing both the physical and logical dimensions in the
intel_mipmap_tree structure. As a result, all miptree creation
functions interpret their arguments as logical dimensions, and both
physical and logical dimensions are always available to functions that
work with intel_mipmap_trees.
In addition, it renames the fields in intel_mipmap_tree used to store
the dimensions, so that it is clear from the name whether physical or
logical dimensions are being referred to.
This should fix the following bugs:
- When creating a separate stencil surface for a depthstencil cubemap,
we would erroneously try to convert the depth from 1 to 6 twice,
resulting in an assertion failure.
- When creating an MCS buffer for compressed multisampling, we used
physical dimensions instead of logical dimensions, resulting in
wasted memory.
In addition, this should considerably simplify the implementation of
ARB_texture_multisample, because it moves the code to compute the
physical size of multisampled surfaces out of renderbuffer-only code.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
This allows intel_miptree_alloc_mcs() to force Y tiling for the MCS
buffer. Previously we accomplished this by the hack of passing
INTEL_MSAA_LAYOUT_CMS as the msaa_layout parameter, but that parameter
is going to be going away soon.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
No functional change. This patch moves the compute_msaa_layout()
function earlier in intel_mipmap_tree.c so that it can be used by
other functions in that file.
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
I erroneously added this back in January 2011 in commit 88421589.
Looking at the commit message, I have no idea why I added it. It only
added non-array structure fields to the symbol table, so array structure
fields are treated correctly.
Fixes piglit tests structure-and-field-have-same-name.vert and
structure-and-field-have-same-name-nested.vert. It should also fix
WebGL conformance tests shader-with-non-reserved-words.
NOTE: This is a candidate for the stable release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57622
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
R6xx doesn't work - the issue seems to be with flushing (sometimes
the destination buffer contains garbage). There are no hangs, so we're good.
R7xx doesn't seem to have any alignment restriction despite our initial
thinking. Everything just works.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This patch enhances the varying packing code so that flat varyings of
uint, int, and float types can be packed together.
We accomplish this in lower_packed_varyings.cpp by making the type of
all flat varyings ivec4, and then using information-preserving type
conversions (e.g. ir_unop_bitcast_f2i) to convert all other types to
ints.
The varying_matches::compute_packing_class() function is updated to
reflect the fact that varying packing no longer needs to segregate
varyings of different base types.
Fixes piglit test varying-packing-mixed-types.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
v2: Split lower_packed_varyings_visitor::bitwise_assign into
pack/unpack variants.
The GLSL 1.30 spec only allows vertex shader outputs and fragment
shader inputs ("varyings" in pre-GLSL-1.30 parlance) to be of type
int, uint, float, or vectors, matrices, or arrays thereof. Bools,
bvec's, and structs are prohibited. (Integral varyings were
prohibited prior to GLSL 1.30).
Previously, Mesa only performed this check on variables declared with
the "varying" keyword, and it always performed the check according to
the pre-GLSL-1.30 rules. As a result, bools and structs were allowed
to slip through, provided they were declared using the new in/out
syntax.
This patch modifies the error check so that it occurs after "varying"
is converted to "in/out", and corrects it to properly account for GLSL
version.
Fixes piglit tests:
in-bool-prohibited.frag
in-bvec2-prohibited.frag
in-bvec3-prohibited.frag
in-bvec4-prohibited.frag
in-struct-prohibited.frag
out-bool-prohibited.vert
out-bvec2-prohibited.vert
out-bvec3-prohibited.vert
out-bvec4-prohibited.vert
out-struct-prohibited.vert
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This patch adds logic to allow the ast_to_hir function
apply_type_qualifier_to_variable() to tell whether it is acting on a
variable declaration or a function parameter. This will allow it to
correctly interpret the meaning of "out" and "in" keywords (which have
different meanings in those two contexts).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
linker.cpp is getting pretty big, and we're about to add even more
varying packing code, so split out the linker code that concerns
varyings to its own file.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously this macro existed in 3 separate places, some inside the
intel driver and some outside of it. It makes more sense to have it
in main/macros.h
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
When analyzing a loop where the loop condition is expressed in the
non-standard order (e.g. "4 > i" instead of "i < 4"), we were
reversing the condition incorrectly, leading to a loop bound that was
off by 1.
Fixes piglit tests {vs,fs}-loop-bounds-unrolled.shader_test.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Haswell and later support the GL_FIXED and 2_10_10_10_rev vertex formats
natively, and don't need shader workarounds.
Reviewed-by: Eric Anholt <eric@anholt.net>
* We have a symbol conflict as rtasm in
Mesa collides with rtasm in gallium.
* As us linking gallium and mesa together
is an edge case, lets just omit the rtasm
code from Mesa as we should be going
llvmpipe soon :)
This is not as optimized as r600g - the MSAA compression is missing,
so r300g needs a lot of bandwidth (more than r600g to do the same thing).
However, if the bandwidth is not an issue for you, you can enjoy this
unoptimized MSAA support.
The only other missing optimization for MSAA is the fast color clear.
MSAA is enabled on r500 only, because that's the only GPU family I tested.
That said, MSAA should work on r300 and r400 as well (but you must set
RADEON_MSAA=1 to allow it, then turn MSAA on in your app or set GALLIUM_MSAA=n,
n >= 2, n <= 6)
I will enable the support by default on r300-r400 once someone (other than me)
tests those chipsets with piglit.
The supported modes are 2x, 4x, 6x.
The supported MSAA formats are RGBA8, BGRA8, and RGBA16F (r500 only).
Those 3 formats are used for all GL internal formats.
Tested with piglit. (I have ported all MSAA tests to GL2.1)
Fixes this build error on platforms not using GNU indent.
indent: Command line: ``-T'' requires a parameter
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
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 <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
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 <ian.d.romanick@intel.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
2013-01-04 17:39:05 -08:00
2613 changed files with 217484 additions and 108942 deletions
<h1>Mesa 8.0.2 Release Notes / March 21, 2012</h1>
@@ -25,7 +25,7 @@ glGetString(GL_VERSION) depends on the particular driver being used.
Some drivers don't support all the features required in OpenGL 3.0.
</p>
<p>
See the <ahref="install.html">Compiling/Installing page</a> for prerequisites
See the <ahref="../install.html">Compiling/Installing page</a> for prerequisites
for DRI hardware acceleration.
</p>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
