This is a tiny housekeeping patch which does the following:
* Replaced tabs with three spaces.
* Formatted oneline and multiline code comments. Some doxygen
comments weren't marked as such and some code comments were marked
as doxygen comments.
* Spaces between if- and while-statements and their parenthesis.
According to the mesa coding style guidelines.
Reviewed-by: Brian Paul <brianp@vmware.com>
With commit dc9ecf58c0,
we are now getting the sampler target from the sampler view
declaration. But since a sampler view declaration can be defined
after a sampler declaration, we need to emit the
sampler declarations in the pre-helpers function, otherwise,
the sampler target might not have defined yet for the sampler declaration.
Fixes viewperf maya-03 and various gl trace regressions in hwv11.
Reviewed-by: Brian Paul <brianp@vmware.com>
svga_shader_expand() will fall back to using non-malloced memory for
emit.buf if malloc fails. We should check if the memory is malloced
before freeing it in the error path of svga_tgsi_vgpu9_translate.
Original patch by Thomas Hindoe Paaboel Andersen <phomes@gmail.com>.
Remove trivial svga_destroy_shader_emitter() function, by BrianP.
Signed-off-by: Brian Paul <brianp@vmware.com>
Having all this code in a big switch is not really a good pratice.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Avoid using internal structures from another API.
v2: rebase and moved includes so they don't cause problem when VDPAU isn't installed.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Leo Liu <leo.liu@amd.com>
That should allow us to get away from passing internal structures around.
v2: rebased
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
We are going to need that in the Mesa state tracker as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Use DMA-buf for the VDPAU interop interface instead of using
internal structures.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Works around a bug in radeonsi and tiling is actually
not very beneficial in this use case.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Linear layout should work for all not compressed or depth/stencil formats.
v2: restrict it a bit more
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
OES_texture_buffer combines bits from a number of desktop extensions.
When they're all available, turn it on.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
A modest size savings:
text data bss dec hex filename
264143 15608 232 279983 445af libglx.so.before
254303 15608 232 270143 41f3f libglx.so.after
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
v2:
* Take into account out varyings too (Timothy Arceri)
* Fix style (Timothy Arceri)
* Use a new ast_expression variable, instead of an
ast_expression::hir new parameter (Timothy Arceri)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Useful to know if a expression is the recipient of an assignment
or not, that would be used to (for example) raise warnings of
"use of uninitialized variable" without getting a false positive
when assigning first a variable.
By default the value is false, and it is assigned to true on
the following cases:
* The lhs assignments subexpression
* At ast_array_index, on the array itself.
* While handling the method on an array, to avoid the warning
calling array.length
* When computed the cached test expression at test_to_hir, to
avoid a duplicate warning on the test expression of a switch.
set_is_lhs setter is added, because in some cases (like ast_field_selection)
the value need to be propagated on the expression tree. To avoid doing the
propatagion if not needed, it skips if no primary_expression.identifier is
available.
v2: use a new bool on ast_expression, instead of a new parameter
on ast_expression::hir (Timothy Arceri)
v3: fix style and some typos on comments, initialize is_lhs default value
on constructor, to avoid a c++11 feature (Ian Romanick)
v4: some tweaks on comments (Timothy Arceri)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94129
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Previously, the pass assumed that the entrypoint would be whatever function
happened to have the name "main". We really shouldn't trust in the
function names.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Allow ES 3.1 contexts to access the texture buffer functionality.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Expose the samplerBuffer/imageBuffer types, and allow the various
functions to operate on them.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We need to add a new bit since the GL ES exts require functionality from
a combination of texture buffer extensions as well as images (for
imageBuffer) support. Additionally, not all GPUs support all the texture
buffer functionality (e.g. rgb32 isn't supported by nv50).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This fixes all failures with dEQP tests in this area. While
ARB_texture_buffer_object explicitly says that GetTexLevelParameter & co
should not be supported, GL 3.1 reverses this decision and allows all of
these queries there.
Conversely, there is no text that forbids the buffer-specific queries
from being used with non-buffer images.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
The only place this was used was in a gallium debug function that
had to be manually enabled.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
To not overwrite buffers and surfaces information, we need to use
a different offset in the driver constant buffer. Currently, OP_SUQ
is only supported for buffers but this will be slightly updated for
images support.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Yuanhan Liu decided these were useful for linear filtering in
commit 76669381 (circa 2011). Prior to that, we never set them;
it seems he tried to preserve that behavior for nearest filtering.
It turns out they're useful for nearest filtering, too: setting
these fixes the following dEQP-GLES3 tests:
functional.fbo.blit.rect.nearest_consistency_mag
functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_y
functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_x
functional.fbo.blit.rect.nearest_consistency_mag_reverse_dst_y
functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_x
functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_dst_y
functional.fbo.blit.rect.nearest_consistency_min
functional.fbo.blit.rect.nearest_consistency_min_reverse_src_x
functional.fbo.blit.rect.nearest_consistency_min_reverse_src_y
functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_x
functional.fbo.blit.rect.nearest_consistency_min_reverse_dst_y
functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_x
functional.fbo.blit.rect.nearest_consistency_min_reverse_src_dst_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_dst_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_mag_reverse_src_dst_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_dst_y
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_x
functional.fbo.blit.rect.nearest_consistency_out_of_bounds_min_reverse_src_dst_y
Apparently, BLORP has always set these bits unconditionally.
However, setting them unconditionally appears to regress tests using
texture projection, 3D samplers, integer formats, and vertex shaders,
all in combination, such as:
functional.shaders.texture_functions.textureprojlod.isampler3d_vertex
Setting them on Gen4-5 appears to regress Piglit's
tests/spec/arb_sampler_objects/framebufferblit.
Honestly, it looks like the real problem here is a lack of precision.
I'm just hacking around problems here (as embarassing as it is).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When using seamless cube map mode and NEAREST filtering, we explicitly
overrode the wrap modes to CLAMP_TO_EDGE. This was to implement the
following spec text:
"If NEAREST filtering is done within a miplevel, always apply apply
wrap mode CLAMP_TO_EDGE."
However, textureGather() ignores the sampler's filtering mode, and
instead returns the four pixels that would be blended by LINEAR
filtering. This implies that we should do proper seamless filtering,
and include pixels from adjacent cube faces.
It turns out that we can simply delete the NEAREST -> CLAMP_TO_EDGE
overrides. Normal cube map sampling works by first selecting the
face, and then nearest filtering fetches the closest texel. If the
nearest texel was on a different face, then that face would have been
chosen. So it should always be within the face anyway, which
effectively performs CLAMP_TO_EDGE.
Fixes 86 dEQP-GLES31.texture.gather.basic.cube.* tests.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Suggested-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Our driver uses the brw_render_cache mechanism to track buffers we've
rendered to and are about to sample from.
Previously, we did a single PIPE_CONTROL with the following bits set:
- Render Target Flush
- Depth Cache Flush
- Texture Cache Invalidate
- VF Cache Invalidate
- Instruction Cache Invalidate
- CS Stall
This combined both "top of pipe" invalidations and "bottom of pipe"
flushes, which isn't how the hardware is intended to be programmed.
The "top of pipe" invalidations may happen right away, without any
guarantees that rendering using those caches has completed. That
rendering may continue altering the caches. The "bottom of pipe"
flushes do wait for the rendering to complete. The CS stall also
prevents further work from happening until data is flushed out.
What we wanted to do was wait for rendering complete, flush the new
data out of the render and depth caches, wait, then invalidate any
stale data in read-only caches. We can accomplish this by doing the
"bottom of pipe" flushes with a CS stall, then the "top of pipe"
flushes as a second PIPE_CONTROL. The flushes will wait until the
rendering is complete, and the CS stall will prevent the second
PIPE_CONTROL with the invalidations from executing until the first
is done.
Fixes dEQP-GLES3.functional.texture.specification.teximage2d_pbo
subtests on Braswell and Skylake. These tests hit the meta PBO
texture upload path, which binds the PBO as a texture and samples
from it, while rendering to the destination texture. The tests
then sample from the texture.
For now, we leave Gen4-5 alone. It probably needs work too, but
apparently it hasn't even been setting the (G45+) TC invalidation
bit at all...
v2: Add Sandybridge post-sync non-zero workaround, for safety.
Cc: mesa-stable@lists.freedesktop.org
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
dEQP-GLES31.functional.fbo.no_attachments.* draws a quad with no
framebuffer attachments, using a shader that discards based on
gl_FragCoord. It uses occlusion queries to inspect whether pixels
are rendered or not.
Unfortunately, the hardware is not dispatching any pixel shaders,
so discards never happen, and the full quad of pixels increments
PS_DEPTH_COUNT, making the occlusion query results bogus.
To understand why, we have to delve into the WM_INT internal
signalling mechanism's formulas.
The "WM_INT::Pixel Shader Kill Pixel" signal is defined as:
3DSTATE_WM::ForceKillPixel == ON ||
(3DSTATE_WM::ForceKillPixel != Off &&
!WM_INT::WM_HZ_OP &&
3DSTATE_WM::EDSC_Mode != PREPS &&
(WM_INT::Depth Write Enable || WM_INT::Stencil Write Enable) &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(3DSTATE_PS_EXTRA::PixelShaderKillsPixels ||
3DSTATE_PS_EXTRA:: oMask Present to RenderTarget ||
3DSTATE_PS_BLEND::AlphaToCoverageEnable ||
3DSTATE_PS_BLEND::AlphaTestEnable ||
3DSTATE_WM_CHROMAKEY::ChromaKeyKillEnable))
Because there is no depth or stencil buffer, writes to those buffers
are disabled. So the highlighted condition is false, making the whole
"Kill Pixel" condition false. This then feeds into the following
"WM_INT::ThreadDispatchEnable" condition:
3DSTATE_WM::ForceThreadDispatch != OFF &&
!WM_INT::WM_HZ_OP &&
3DSTATE_PS_EXTRA::PixelShaderValid &&
(3DSTATE_PS_EXTRA::PixelShaderHasUAV ||
WM_INT::Pixel Shader Kill Pixel ||
WM_INT::RTIndependentRasterizationEnable ||
(!3DSTATE_PS_EXTRA::PixelShaderDoesNotWriteRT &&
3DSTATE_PS_BLEND::HasWriteableRT) ||
(WM_INT::Pixel Shader Computed Depth Mode != PSCDEPTH_OFF &&
(WM_INT::Depth Test Enable || WM_INT::Depth Write Enable)) ||
(3DSTATE_PS_EXTRA::Computed Stencil && WM_INT::Stencil Test Enable) ||
(3DSTATE_WM::EDSC_Mode == 1 && (WM_INT::Depth Test Enable ||
WM_INT::Depth Write Enable ||
WM_INT::Stencil Test Enable)))
Given that there's no depth/stencil testing, no writeable render target,
and the hardware thinks kill pixel doesn't happen, all of these
conditions are false. We have to whack some bit to make PS invocations
happen. There are many options.
Curro suggested using the UAV bit. There's some precedence in doing
that - we set it for fragment shaders that do SSBO/image/atomic writes
when no color buffer writes are enabled. We can simply include discard
here too.
Fixes 64 dEQP-GLES31.functional.fbo.no_attachments.* tests.
v2: Add a comment suggested and written by Jason Ekstrand.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Found with grep and inspection. Test compiled on RPi hw.
Assists any future effort to remove TGSI as an intermediate stage.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Meaning, always rebuild them when asked instead of bothering to look at
timestamps (and then wondering why nothing happened when you said make).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Broken by:
commit 9ace0b5422
Author: Dylan Baker <baker.dylan.c@gmail.com>
Date: Wed May 20 15:49:11 2015 -0700
glapi: glX_proto_size.py: use argparse instead of getopt
Which changed most, but not all, callers to use --header-tag instead of
-h.
Reviewed-by: Dylan Baker <baker.dylan.c@gmail.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We disable the vertex attributes, but also disable the VBO fetch details
as well, just in case. Not known to fix anything.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Back in the dawn of time, we used to do immediate uploads for the vertex
data, and all was well. However Maxwell dropped support for immediate
vertex data, so we started feeding in a VBO (in all cases). But we
forgot to disable some things that apply in such cases, specifically
primitive restart and index bias. The latter was causing WoW and other
Blizzard games trouble as they use a pattern where they draw with a base
vertex (aka index bias), followed by texture uploads (aka blits,
internally).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91526
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Karol Herbst <nouveau@karolherbst.de>
On Fermi, there's an argument in front of the coords that combines array
and indirect handle, while on Kepler the array and the indirect handle
are separate (and in front of the coords). We were previously only
accounting for the array bit of it, if there were an indirect access it
wouldn't be counted in the formula.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Apparently there's no post-FS clamping logic, so we have to do this by
hand. The depth will never be outside of the 0..1 range, even on
floating point zeta buffers, so this should be safe.
Fixes dEQP-GLES3.functional.fbo.depth.*clamp.* which tests writing
invalid values on various zeta buffer formats.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
