I was getting a random GPU hang in the renderpass simple tests,
it turns out sometimes radv emitted the wrong thing "last".
This fixes the logic to emit Z/stencil last if they occur,
and not mark a color output as last. Also this relies on the
Z/STENCIL being the first two fragment outputs, which they are
so yay.
Fixes: dEQP-VK.renderpass.simple.color_depth (random hangs)
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The first IF statement disabled the second one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98599
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Some of the details of this function are very confusing and have a long
history. We should document that history and this seems like the best
place to do it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
At least on Sky Lake, after emitting 3DSTATE_CONSTANT_*, you are required
to re-emit the 3DSTATE_BINDING_TABLE_POINTERS packet for the corresponding
stage. If you don't, double-buffering may fail and you may get the wrong
constants. It turns out that you need to do this even if you have no push
constants to speak of or else the next 3DSTATE_CONSTANT packet you emit for
that stage may not work correctly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
For gen9+ this will indicate when we should allow hiz based sampling
during rendering.
Improves performance in :
- Synmark's OglDeferred by 2.2% (n=20)
- Synmark's OglShMapPcf by 0.44% (n=20)
v2 by Ben: Add spec reference, and make it fix with some of the changes made on
the previous patches
Change the check from mt->aux_buf to mt->num_samples. The presence of an aux_buf
isn't enough to determine there isn't a HiZ buffer to use.
v3: It seems all depth surface end up with num_samples = 0 by default,
so allow sampling from depth HiZ if num_samples <= 1. (Lionel)
Allow sampling from HiZ only if all LOD are available from the HiZ
buffer. (Lionel)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v2)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v3)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The original functionality this patch introduces was authored by a patch from
Ken (the commit subject was the same). Since I ended up changing so many patches
in the code before this one, I had some non-trivial decisions to make, and I
didn't feel it was appropriate to keeps Ken's name as author (mostly because he
might not like what I've done). Ken's original patch was like 2 LOC :-)
In either case, some credit needs to go to Ken, and to Jordan for a few small
other changes in that original patch.
v2: Back to a smaller diff now that ISL handles most of the actual
programming (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Currently it indicates that this is never supported, but soon it will
be supported for gen8+^w gen9+
v2 by Ben:
- Explicitly disable aux_hiz for gen < 9 (with comment)
- squashed in next patch to avoid unused and useless functions
i965: Support sampling with hiz during rendering
For gen8, we can sample from depth while using the hiz buffer. This
allows us to sample depth without resolving from hiz to the depth
texture.
To do this we must resolve to hiz before drawing so we can use the hiz
buffer to sample while rendering. Hopefully the hiz buffer will
already be resolved in most cases because it was previously rendered,
meaning the hiz resolve is a no-op.
Note that this is still controlled by the
intel_miptree_sample_with_hiz function, and we will enable hiz
sampling for gen8 in a separate patch.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This seems counter to the goal of consolidating hiz, mcs, and later ccs buffers.
Unfortunately, hiz on gen6 is a thing the code supports, and this wart will be
helpful to achieve that. Overall, I believe it does help unify AUX buffers on
gen7+.
I updated the size field which I introduced in the previous patch, even though
we have no use for it.
XXX: As I mentioned in the last patch, the height given to the MCS buffer
allocation in intel_miptree_alloc_mcs() looks wrong, but I don't claim to fully
understand how the MCS buffer is laid out.
v2: rebase on master (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This patch will preserve the BO & offset, and not the miptree for the
aux_mcs buffer. Eventually it might make sense to pull put the sizing
function in miptree creation, but for now this should be sufficient
and not too hideous.
v2: Save BO's offset too (Lionel)
v3: Squash previous patch storing the size of the allocated aux buffer
(Lionel)
Fix memory leak with mcs_buf->bo (Lionel)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The next patch will change the map type, and this will make sure there are no
regressions as a result of the other stuff. Since the miptree is newly created,
I believe it is always safe to just map.
It is possible to CPU map this buffer on LLC platforms (it additionally requires
rounding up to tile size). I did experiment with that patch, and found no
performance gains to be had.
I've added in error handling while here. Generally GTT mapping is an operation
which is highly unlikely to fail, but we may as well handle it when it does.
v2: rebase on master (Lionel)
v3: print out error if gtt mapping fails (Topi)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v2)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This will allow us to treat HiZ and MCS the same when using as an
auxiliary surface buffer.
v2: (Ben) Minor rebase conflict resolution.
Rename mcs_buf to aux_buf to address upcoming change for hiz specific buffers.
That second thing is essentially a squash of:
i965/gen8: Use intel_miptree_aux_buffer for auxiliary buffer - which didn't need
to be separate in my opinion.
v3: rebase on master (Lionel)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> (v1)
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>a (v2)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v3)
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This patch does two things:
1. It separates the host-CPU code generation from the generic code
generation. This guards against accidently breaking things for
radeonsi in the future.
2. It makes sure we actually use both arguments and don't just compute
a square :-p
Fixes a regression introduced by commit 29279f44b3
Cc: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Instead of doing all the math with scalars, use vectors. This means the
overflow math needs to be done manually, albeit that's only really
problematic for the stride/index mul, the rest has been pretty much
moved outside the shader loop (albeit the mul could actually be optimized
away too), where things are still scalar. Because llvm is complete fail
with the zero-extend widening mul, roll our own even...
To eliminate control flow in the main shader loop fetch, provide fake
buffers (so index 0 is always valid to fetch).
Still uses aos fetch though in the end - mostly because some more code
would be needed to handle unaligned fetches in that path, and because for
most formats it won't make a difference anyway (we generate some truly
horrendous code for things like R16G16_something for instance).
Instanced fetch however stays roughly the same as before, except that
no longer the same element is fetched multiple times (I've seen a reduction
of ~3 times in main shader loop size due to apparently llvm not being able
to deduce it's really all the same with a couple instanced elements).
Also, for elts gathering, use vectorized code as well - provide a fake
elt buffer if there's no valid one bound.
The generated shaders are smaller and faster to compile (not entirely sure
about execution speed, but generally unless there's just single vertices
to handle I would expect it to be faster - there's more opportunities
for future improvements by using soa fetch).
No piglit change.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is used by shader umul_hi/imul_hi functions (and soon by draw).
It's actually useful separating this out on its own, however the real
reason for doing it is because we're using an optimized sse2 version,
since the code llvm generates is atrocious (since there's no widening
mul in llvm, and it does not recognize the widening mul pattern, so
it generates code for real 64x64->64bit mul, which the cpu can't do
natively, in contrast to 32x32->64bit mul which it could do).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
In the event that multiple threads attempt to install a graph
concurrently, protect the shared list.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
We're missing the closedir() to the matching opendir().
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Instead of trying to maintain a reference counted list of valid HUD
objects, and freeing them accordingly, creating race conditions
between unanticipated multiple threads, simply accept they're
allocated once and never released until the process terminates.
They're a shared resource between multiple threads, so accept
they're always available for use.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes a problem seen with gallium drivers vs android wallpaper.
Basically, what happens is:
EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay, mEglConfig, attribs);
mEgl.eglMakeCurrent(mEglDisplay, tmpSurface, tmpSurface, mEglContext);
int[] maxSize = new int[1];
Rect frame = surfaceHolder.getSurfaceFrame();
glGetIntegerv(GL_MAX_TEXTURE_SIZE, maxSize, 0);
mEgl.eglMakeCurrent(mEglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
mEgl.eglDestroySurface(mEglDisplay, tmpSurface);
... check maxSize vs frame size and bail if needed ...
mEglSurface = mEgl.eglCreateWindowSurface(mEglDisplay, mEglConfig, surfaceHolder, null);
... error checking ...
mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext);
When the window-surface is created, it ends up with the same ptr address
as the recently freed tmpSurface pbuffer surface. Which after many
levels of indirection, results in st_framebuffer_validate() ending up with
the same/old framebuffer object, and in the end never calling the
DRIimageLoaderExtension::getBuffers(). Then in droid_swap_buffers(), the
dri2_surf is still the old pbuffer surface (with dri2_surf->buffer being
NULL, obviously, so when wallpaper app calls eglSwapBuffers() nothing
gets enqueued to the compositor). Resulting in a black/blank background
layer.
Note that at the EGL layer, when the context is unbound, EGL drops it's
references to the draw and read buffer as well.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Robert Foss <robert.foss@collabora.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
v3 [Francisco Jerez]: Loosely based on Serge's v1 of this patch in
order to avoid CL-specific enums in the clover module binary
format. In addition to other changes made in v2: Represent the CL
program binary type as the section type instead of adding a CL
API-specific enum, check that the binary types of the input objects
are valid during clLinkProgram(), pass section type as argument to
build_module_library() instead of using separate function.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Instead, hardcode group sigsel because there are a bunch of unknown
groups, especially on SM50/SM52.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This is similar to NVC0 and GK110 emitters where we emit
reduction operations instead of atomic operations when the
destination is not used.
Found after writing some tests which check if performance counters
return the expected value. In that case, gred_count returned 0
on gm107 while at least gk106 returned the correct value.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes random crashes with MSVC release builds. It seems the
members are implicitly initialized to zero with gcc, but not MSVC.
In particular, the tex_offset_num_offset field was non-zero causing
a loop over the NULL tex_offsets array to crash.
Zero-init those fields and a few others to be safe.
The regression began with acc23b04cf "ralloc: remove memset from
ralloc_size".
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes the following building error introduced with commit 7115e56
and related amd/common dependencies:
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: error: undefined reference to 'ac_is_sgpr_param'
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: error: undefined reference to 'ac_is_sgpr_param'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
GL_ARB_ES3_compatibility brings ETC2/EAC formats to desktop GL.
The meaning of the GL compressed format list is pretty vague - it's
supposed to return formats for "general-purpose usage". (GL 4.2
deprecates the list because of this.) Basically everyone interprets
this as "linear RGB/RGBA".
ETC2/EAC meets that criteria, so while we shouldn't be required to add
it to the list, there's also little harm in doing so, at least on
platforms with native support. I doubt anyone is using this list for
much anyway, so even on platforms without native support, it's probably
not a big deal.
Makes the following GL45-CTS.gtf43 tests pass:
* GL3Tests.eac_compression_r11.gl_compressed_r11_eac
* GL3Tests.eac_compression_rg11.gl_compressed_rg11_eac
* GL3Tests.eac_compression_signed_r11.gl_compressed_signed_r11_eac
* GL3Tests.eac_compression_signed_rg11.gl_compressed_signed_rg11_eac
* GL3Tests.etc2_compression_rgb8.gl_compressed_rgb8_etc2
* GL3Tests.etc2_compression_rgb8_pt_alpha1.gl_compressed_rgb8_pt_alpha1_etc2
* GL3Tests.etc2_compression_rgba8.gl_compressed_rgba8_etc2
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
The 1/W was apparently not accurate enough, and we were getting sparklies
in the distance. The closed driver also did a N-R step here.
Cc: <mesa-stable@lists.freedesktop.org>
The hardware always treats the alpha channel as unsigned, so add a shader
workaround. This is rare enough that we'll just build a monolithic vertex
shader.
The SINT case cannot actually happen in OpenGL, but I've included it for
completeness since it's just a mix of the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
A (latent) bug in VDPAU interop was exposed by commit
e5cc84dd43.
Before that commit, the st_vdpau code created samplers with
first_layer == last_layer == 1 that the general texture handling code
would immediately delete and re-create, because the layer does not match
the information in the GL texture object.
This was correct behavior at least in the DMABUF case, because the imported
resource is supposed to have the correct offset already applied. In the
non-DMABUF case, this was just plain wrong but apparently nobody noticed.
After that commit, the state tracker assumes that an existing sampler is
correct at all times. Existing samplers are supposed to be deleted when
they may become invalid, and they will be created on-demand. This meant
that the sampler with first_layer == last_layer == 1 stuck around, leading
to rendering artefacts (on radeonsi), command stream failures (on r600), and
assertions (in debug builds everywhere).
This patch fixes the problem by simply not creating a sampler at all in
st_vdpau_map_surface. We rely on the generic texture code to do the right
thing, adding the layer_override to make the non-DMABUF case work.
v2: add the layer_override
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98512
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Cc: Christian König <deathsimple@vodafone.de>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Christian König <christian.koenig@amd.com>
This reverts commit d180de3532.
This is a radeon specific hack that causes problems on nouveau
when combined with the SHARED flag later. If radeonsi needs a fix
for this, please fix it in the driver.
[chk]
Using linear surfaces for this makes sense because tilling isn't
beneficial and the surfaces can potentially be shared with other GPUs
using the VDPAU OpenGL interop.
[airlied]
I think we need a flag that isn't SHARED/LINEAR that is more
SHARED_OTHER_GPU.
[mareko]
Does radeonsi need PIPE_BIND_VIDEO_DECODE_OUTPUT that it would translate
into linear ?
[mareko]
My only concern is decoding performance. If the decoder works in 64x1
blocks, tiling will hurt. That's the theory. I don't know how the
decoder works.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Tested-by: Nayan Deshmukh <nayan26deshmukh@gmail.com> (I+A)
This fixes a crash in Deus Ex: Mankind Divided. Release builds were
unaffected, so it's not too serious.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This was broken when the GLAPI use was removed from mesa_glinterop.h.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This was broken when the GLAPI use was removed from mesa_glinterop.h.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
I need the definition of PUBLIC.
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
When splitting up loads, we have to add 16 bytes to the offset for
the high components, just like already happens for stores.
Fixes arb_gpu_shader_fp64@shader_storage@layout-std140-fp64-shader.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
From the manpage of asprintf:
"If memory allocation wasn't possible, or some other error occurs,
these functions will return -1, and the contents of strp are
undefined."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Fixes valgrind warnings about using uninitialized memory when starting X.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Fixes spurious assertion failure in surf_level_drm_to_winsys when
starting X, due to processing a miplevel which was never initialized.
Fixes: e9c76eeeaa ("gallium/radeon: remove radeon_surf_level::pitch_bytes")
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Mesa uses limits.h elsewhere, and this makes is possible to
compile anv_allocator.c on Android.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
We were leaving an undefined value since the ralloc zeroing changes.
Fixes nir_validate() failures on vc4.
v2: Fix the color-index case of drawpixels as well.
Reviewed-by: Rob Clark <robdclark@gmail.com> (v1)
Previous fixes were incomplete - some code still iterated through the number
of elements provided by velem layout instead of the number stored in the key
(which is the same as the number defined by the vs). And also actually
accessed the elements from the layout directly instead of those in the key.
This mismatch could still cause crashes.
(Besides, it is a very good idea to only use data stored in the key anyway.)
v2: move null format check, remove now unnecessary function parameter,
some minor prettify
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Invalidate a "new" surface before it is bound to a render target view or
depth stencil view in order to avoid the unnecessary host side copy
of the surface data before it is rendered to.
Note that, recycled surface is already invalidated before it is reused.
Reviewed-by: Brian Paul <brianp@vmware.com>
Using untyped surface formats causes huge performance degradation on Fusion.
This reverts commit eb0ced74f6 until
the backend has a better solution to address typeless surface formats.
Currently blitter will fail if the blit format is different and
view-incompatible to the resource format. Instead of punting
to software blit which will stall the pipeline, we will
create temporary resource to allow blitter to work.
Fixes piglit test arb_copy_image-formats.
Also tested with MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
Currently we adjust the view format when we are asked to create a
BGRA render target view for BGRX surface. But we only look for
SVGA3D_B8G8R8X8_TYPELESS surface format.
With this patch, we will also check for SVGA3D_B8G8R8X8_UNORM surface format,
and use SVGA3D_B8G8R8X8_UNORM as the view format for that case.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch adds a helper function svga_format_is_typeless() which
returns TRUE if the specified format is typeless.
Reviewed-by: Brian Paul <brianp@vmware.com>
We may need to re-emit texture bindings when the framebuffer state
changes. In particular, emitting the texture binding can also involve
updating a texture from its backing copy during sampler view validation.
The backing copy is made during framebuffer validation.
This helps to fix an issue with Photoshop on VGPU9 (VMware bug 1723971).
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
With this patch, we will allow blit with copy_region if the
source and destination textures have the same sample counts.
Fixes failures with piglit tests
spec@arb_texture_float@multisample-formats 2 gl_arb_texture_float
spec@arb_texture_rg@multisample-formats 2 gl_arb_texture_rg-float
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch sets the rendered-to flag for the subresource after it is
updated using the PredCopyRegion command. This is to ensure that the GB surface
will be sync up properly before it will be directly mapped to.
Tested with MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch adds a flag "can_use_upload" to svga_texture structure
to avoid some checking of the upload availability at each transfer map time.
Tested with Lightsmark2008, Tropics, MTT glretrace, piglit.
Reviewed-by: Brian Paul <brianp@vmware.com>
As Thomas suggested, we'll first try to map directly to a GB surface.
If it is blocked, then we'll use texture upload buffer.
Also if a texture is already "rendered to", that is, the GB surface
is already out of sync, then we'll use the texture upload buffer
to avoid syncing the GB surface.
Tested with Lightsmark2008, Tropics, MTT piglit, glretrace.
Reviewed-by: Brian Paul <brianp@vmware.com>
This patch sets the rendered_to flag for the texture subresource that
is uploaded using the TransferFromBuffer command. This is to ensure that
the subresource will be read back or invalidated before it will be
directly mapped to. This makes sure that the content of the GB surface
will not be accidentally overwritten by the device at suspend/resume time.
Reviewed-by: Brian Paul <brianp@vmware.com>
set render_condition flag when driver performs conditional rendering.
Blit using DXPredCopyRegion command gets affected by conditional rendering so
We should check this flag while performing blit operation
Tested with piglit tests.
v2: As per Charmaine's comment, setting render_condition flag if svga_query is valid.
Tested with pigit tests.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
DXPredCopyRegion supports copy between src and dst for depth_and_stencil
formats if src and dst have same formats.
tested ith piglit
v2: As per Brian's comment, allow DXPredCopyRegion for depth+stencil buffers
if the blit mask is PIPE_MASK_ZS.
Tested with piglit tests and added new piglit test
arb_framebuffer_object-depth-stencil-blit to test this particular testcase.
Reviewed-by: Brian Paul <brianp@vmware.com>
Piglit tests which uses arb_clear_texture extension, have memory leak issue.
pipe_surface created in svga_clear_texture() was not deleted which happens to be
the cause for memory leak.
tested all arb_clear_texture-* piglit tests with valgrid.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: Accounted for the fact that svga_try_clear_render_target also
honors conditional rendering.
Testing done: Excercised all functions in a separate feature branch. Forced
emission of conditional rendering commands when necessary.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Assuming the hardware is set up to use a screen coordinate system
flipped vertically with respect to the GL's window coordinate system,
the SYSTEM_VALUE_SAMPLE_POS vector will also be flipped vertically
with respect to the value expected by the GL, so we need to give it
the same treatment as gl_FragCoord. Fixes the following CTS tests on
i965:
ES31-CTS.functional.shaders.multisample_interpolation.interpolate_at_offset.at_sample_position.default_framebuffer
ES31-CTS.functional.shaders.sample_variables.sample_pos.correctness.default_framebuffer
when run with any multisample configuration, e.g. rgba8888d24s8ms4.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Such a surface is not possible on our hardware. Without this change, ISL
surface creation would fail with the next patch.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Valgrind reports that we use cfg.cycle_count uninitialised, so zero the
cfg_t on construction.
Fixes: 52d2b28f7f ("ralloc: use rzalloc where it's necessary")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This fixes a build regression of commit 7115e56c21.
Sorry for the breakage, this second location for link dependencies escaped
my build tests.
Bugzilla: https://patchwork.freedesktop.org/patch/119816/
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Otherwise it won't be picked in the tarball and the build will fail.
Fixes: 533b3530c1 ("direct-to-native-GL for GLX clients on Cygwin
("Windows-DRI")")
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
commit cc6aa1d161 changed to using rzalloc
for gl_program creation but one instance for program creation was still
using calloc.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Fixes GL45-CTS.geometry_shader.adjacency.adjacency_indiced_triangle_strip and
others.
This leaves the case of triangle strips with adjacency and primitive restarts
open. It seems that the only thing that cares about that is a piglit test.
Fixing this efficiently would be really involved, and I don't want to use the
hammer of degrading to software handling of indices because there may well
be software that uses this draw mode (without caring about the precise
rotation of triangles).
v2:
- skip the GS prolog entirely if workaround is not needed
- only check for TES (TES is always non-null when tessellation is used)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The copy shader only depends on the selector. This change avoids creating
separate code paths for monolithic vs. non-monolithic geometry shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For fixed function TCS, we keep the copying of VS outputs to TES inputs inside
the main function; the call to si_copy_tcs_inputs is moved accordingly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This helps to achieve a gradual transition towards building monolithic shaders
via inlining.
no_prolog and no_epilog will be removed by the end of the series,
separate_prolog remains in use to control the PS input mapping.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Change the pass manager as well, since this is a module-level pass. No
noticeable run-time difference on shader-db.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The incompatible signature becomes an issue when the VS epilog gets merged
with the main vertex shader at the IR level.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
At least when LLVM is used, which is basically always (unless you're only
building r600 without OpenCL).
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When a UBO reference has the form block_name.foo where block_name refers
to a block where the first member has a non-zero offset, the base offset
was incorrectly added to the reference.
Fixes an assertion triggered in debug builds by
GL45-CTS.enhanced_layouts.uniform_block_layout_qualifier_conflict. That test
doesn't properly check for correct execution in this case, so I am also
going to send out a piglit test.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
At link time, we resolve the size of implicitly sized arrays.
When doing so, we update the type of the ir_variables. However,
we neglected to update the type of ir_dereference nodes which
reference those variables.
It turns out array_resize_visitor (for GS/TCS/TES interface array
handling) already did 2/3 of the cases for this, so we can simply
refactor the code and reuse it.
This fixes:
GL45-CTS.shader_storage_buffer_object.basic-syntax
GL45-CTS.shader_storage_buffer_object.basic-syntaxSSO
which have an SSBO containing an implicitly sized array, followed
by some other members. setup_buffer_access uses the dereference
types to compute offsets to fields, and it had a stale type where
the implicitly sized array's length was still 0 instead of the
actual length.
While we're here, we can also fix update_array_sizes to properly
update deref types as well, fixing a FINISHME from 2010.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This moves the delete linked shaders call to
_mesa_clear_shader_program_data() which makes sure we delete them
before returning due to any validation problems.
It also reduces some code duplication.
From the OpenGL 4.5 Core spec:
"If LinkProgram failed, any information about a previous link of
that program object is lost. Thus, a failed link does not restore
the old state of program.
...
If one of these commands is called with a program for which
LinkProgram failed, no error is generated unless otherwise noted.
Implementations may return information on variables and interface
blocks that would have been active had the program been linked
successfully. In cases where the link failed because the program
required too many resources, these commands may help applications
determine why limits were exceeded."
Therefore it's expected that we shouldn't be able to query the
program that failed to link and retrieve information about a
previously successful link.
Before this change the linker was doing validation before freeing
the previously linked shaders and therefore could exit on failure
before they were freed.
This change also fixes an issue in compat profile where a program
with no shaders attached is expect to fall back to fixed function
but was instead trying to relink IR from a previous link.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97715
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
These were broken in e1af20f18a when the info field in nir_shader was
turned into a pointer.
Clone was copying the pointer rather than the data and nir_sweep was
cleaning up shader_info rather than claiming it.
Reviewed-by: Eric Anholt <eric@anholt.net>
This will allow use to use ralloc_parent() on the info field and fix
a regression in nir_sweep() caused by e1af20f18a.
This is intended to be a temporary requirement that will be removed
when we finish separating shader_info from nir_shader.
Reviewed-by: Eric Anholt <eric@anholt.net>
This allows us to use ralloc_parent() to see which data structure owns
shader_info which allows us to fix a regression in nir_sweep().
This will also allow us to move some fields from gl_linked_shader to
gl_program, which will allow us to do some clean-ups like storing
gl_program directly in the CurrentProgram array in gl_pipeline_object
enabling some small validation optimisations at draw time.
Also it is error prone to depend on the gl_linked_shader for
programs in current use because a failed linking attempt will free
infomation about the current program. In i965 we could be trying
to recompile a shader variant but may have lost some required fields.
Reviewed-by: Eric Anholt <eric@anholt.net>
This limitation was initially here because AMD_performance_monitor
doesn't allow to expose the real number of hardware counters. But
this actually really annoying when profiling with qapitrace.
Anyways, performance counters are mostly for developers and
failures are expected if you try to monitor more queries than
supported.
This breaks amd_performance_monitor_measure but it's expected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Event not_predicated_off_thread_inst_executed is SM35+.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Dolphin tried to use this, but we hadn't had any tests for it properly.
All that is required is the shader output format needs to be set
for 0 and 1 exports.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
As this array was not actually sorted, FindGLXFunction's binary search
would only sometimes work.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Before we were caching the prog data but we weren't doing anything with
brw_stage_prog_data::param so anything with push constants wasn't getting
cached properly. This commit fixes that.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
While we can simply calculate offsets to get to things such as the
prog_data and the key, it's much more user-friendly if there are just
pointers. Also, it's a bit more fool-proof.
While we're at it, we rework the pipeline cache API to use the
brw_stage_prog_data type directly.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The case where we just want the loop to continue is INCOMPATIBLE_DRIVER
because that simply means that whatever FD we opened isn't a supported
Intel chip. Other error codes such as OUT_OF_HOST_MEMORY are actual errors
and we should be returning early in that case.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Without this fix, the function would still end up returning NULL but it
would put that NULL connection in the hash table which would be bad.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
This is required when an out argument involves an array index that is either
a global variable modified by the function or another out argument in the
same function call.
Fixes the shaders/out-parameter-indexing/vs-inout-index-inout-* tests.
v2:
- modify the ir_dereference_array nodes in place
- use ir_hierarchical_visitor
v3: use base_ir (Ian Romanick)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
As previously written, these opcodes use the SM5 semantics which is
incompatible with GLSL when bits == 0, offset == 32.
At some point we may want to add BFI_SM5 etc. opcodes, but all users
currently either want (and expect!) the GLSL semantics or don't care.
Bitfield inserts are generated by the GLSL lower_instructions and
lower_packing_builtins passes with constant bits and offset arguments,
so any workaround code that drivers may have to emit to follow GLSL
semantics should be optimized away easily for those uses.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
I missed this when I added the xlib code, this allows
dolphin emu to start and crash later.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This makes more sense than OUT_OF_HOST_MEMORY. Technically, you can
recover from a failed execbuf2 but the batch you just submitted didn't
fully execute so things are in an ill-defined state. The app doesn't want
to continue from that point anyway.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The emission of vertex attributes corresponding to dvec3 and dvec4
vertex shader input variables was not correct when the <size> passed
to the VertexAttribL* commands was <= 2.
This was because we were using the vertex array size when emitting vertices
to decide if we uploaded a 64-bit floating point attribute as 1 slot (128-bits)
for sizes 1 and 2, or 2 slots (256-bits) for sizes 3 and 4. This caused problems
when mapping the input variables to registers because, for deciding which
registers contain the values uploaded for a certain variable, we use the size
and type given to the variable in the shader, so we will be assigning 256-bits
to dvec3/4 variables, even if we only uploaded 128-bits for them, which happened
when the vertex array size was <= 2.
The patch uses the shader information to only emit as 128-bits those 64-bit floating
point variables that were declared as double or dvec2 in the vertex shader. Dvec3 and
dvec4 variables will be always uploaded as 256-bits, independently of the <size> given
to the VertexAttribL* command.
From the ARB_vertex_attrib_64bit specification:
"For the 64-bit double precision types listed in Table X.1, no default
attribute values are provided if the values of the vertex attribute variable
are specified with fewer components than required for the attribute
variable. For example, the fourth component of a variable of type dvec4
will be undefined if specified using VertexAttribL3dv or using a vertex
array specified with VertexAttribLPointer and a size of three."
We are filling these unspecified components with zeros, which coincidentally is
also what the GL44-CTS.vertex_attrib_binding.basic-inputL-case1 expects.
v2: Do not use bitcount (Kenneth Graunke)
Fixes: GL44-CTS.vertex_attrib_binding.basic-inputL-case1 test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97287
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We require 12 bytes of headers but in some cases we just need 4.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
3DSTATE_WM_CHROMAKEY isn't programmed anywhere else.
3DSTATE_WM_HZ_OP is programmed, then cleared by blorp during a
HZ op, so repeatedly clearing it after every blorp execution is
redundant.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This packet is non-pipelined and doesn't ever change across emissions.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
When the video coded size is different from frame size, we need the result
buffers are same as coded size, which are not size compatible with encode
required size, so that simply use no tunnel for this case instead of frame
by frame converting.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Otherwise fails the check of matching between decoder size and buffers
size in kernel.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Add frontend dependency concept in the DRAW_CONTEXT, which
allows serialization of frontend work if necessary.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This allows the post-processor to easily detect the API thread and to
process frame information. The frame information is needed to
optimized how data is processed from worker threads.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
only do it in rzalloc_size as it was supposed to be
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.
Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values
I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
this fixes some of the regressions with
"ralloc: remove memset from ralloc_size"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Switch to use memory allocations which zero memory for places
where needed.
v2: modify and rebase on top of Marek's series (Tapani)
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
time GALLIUM_NOOP=1 ./run shaders/private/alien_isolation/ >/dev/null
Before (2 takes):
real 0m8.734s 0m8.773s
user 0m34.232s 0m34.348s
sys 0m0.084s 0m0.056s
After (2 takes):
real 0m8.448s 0m8.463s
user 0m33.104s 0m33.160s
sys 0m0.088s 0m0.076s
Average change in "real" time spent: -3.4%
calloc should only do 2 things compared to malloc:
- check for overflow of "n * size"
- call memset
I'm not sure if that explains the difference.
v2: clear "parent" and "next" in the caller of add_child.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended to the options
specified in clCompileProgram and clLinkProgram function calls,
respectively.
v2:
* rename to CLOVER_EXTRA_COMPILER_OPTIONS
* use debug_get_option
* append to linker options as well
v3: code cleanups
v4: separate CLOVER_EXTRA_LINKER_OPTIONS options
v5:
* fix documentation typo
* use CLOVER_EXTRA_COMPILER_OPTIONS in link stage
v6:
* separate in CLOVER_EXTRA_{BUILD,COMPILE,LINK}_OPTIONS
* append options in cl{Build,Compile,Link}Program
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by[v1]: Edward O'Callaghan <funfunctor@folklore1984.net>
v7 [Francisco Jerez]: Slight simplification.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.
If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.
v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
v3: simplify parsing logic, use more C++11
v4: restore error throwing, clarify a comment
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The address immediate field is only 9 bits and, since the value is in
bytes, the highest GRF we can point to with it is g15. This makes it
pretty close to useless for MOV_INDIRECT. There were already piles of
restrictions preventing us from using it prior to Broadwell, so let's get
rid of the gen8+ code path entirely.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97779
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>