This patch makes sure there is a valid fd before merging it
to the context's fd in vmw_svga_winsys_fence_server_sync().
This fixes the assert running webot.
No regression running kmscube.
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
This is the second patch needed to fix the following piglit tests:
tests/spec/arb_gl_spirv/linker/uniform/multisampler.shader_test
tests/spec/arb_gl_spirv/linker/uniform/multisampler-array.shader_test
Although in this case it doesn't affect so many borrowed tests, as
there aren't too many tests using multisamplers on Intel.
It is worth to note that this patch is also needed when those tests
are run on GLSL mode (using the --glsl option). Although most Intel
drivers would not be able to run/execute tests using multisamplers, as
GL_MAX_IMAGE_SAMPLES is zero, technically those tests are expected to
link correctly, so linking tests should pass.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
At this moment that lowering is using info coming from the
UniformStorage, so for the ARB_gl_spirv codepath, it needs to be done
after calling gl_nir_link_uniforms. As for the GLSL codepath it can
also be called later, we just move the call on both cases, to avoid
adding several shader->spirv_data checks, and keep the patch as small
as possible.
This is the first patch needed to fix the following piglit tests:
tests/spec/arb_gl_spirv/linker/uniform/multisampler.shader_test
tests/spec/arb_gl_spirv/linker/uniform/multisampler-array.shader_test
but fixes thousands of tests when borrowing the tests from other specs
(that needs to be done manually right now).
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
To brw_nir_lower_gl_images, as it will be also used on the
ARB_gl_spirv codepath, that doesn't involves GLSL at all. So the
lowering is about images following the OpenGL semantics. In any case
"brw_nir_lower_opengl_images" seemed too long to me, so I just used
gl. That shortening is already used on other parts of the code.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The resource bo array must already extended when the target index is
equal to the current size of the array.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Silences:
Conditional jump or move depends on uninitialised value(s)
at 0xB72F2C0: virgl_drm_winsys_create (virgl_drm_winsys.c:854)
by 0xB72F2C0: virgl_drm_screen_create (virgl_drm_winsys.c:926)
by 0xB21C885: pipe_virgl_create_screen (drm_helper.h:275)
by 0xB7201F0: pipe_loader_create_screen (pipe_loader.c:137)
by 0xB639C91: dri2_init_screen (dri2.c:2112)
by 0xB634F68: driCreateNewScreen2 (dri_util.c:153)
by 0x63023E6: dri3_create_screen (dri3_glx.c:893)
by 0x62D35BD: AllocAndFetchScreenConfigs (glxext.c:820)
by 0x62D35BD: __glXInitialize (glxext.c:946)
by 0x62CECB3: GetGLXPrivScreenConfig (glxcmds.c:174)
by 0x62CF69C: glXQueryExtensionsString (glxcmds.c:1304)
by 0x60AA7D9: ??? (in /usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.5.2)
by 0x4F81450: wfl_checked_display_connect (piglit-util-waffle.h:74)
by 0x4F829E0: piglit_wfl_framework_init (piglit_wfl_framework.c:627)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Fixes crash with
piglit/bin/map_buffer_range-invalidate CopyBufferSubData \
increment-offset -auto -fbo
* Resize the resource storage already when the count is equal to the
allocated size, fixes:
Invalid write of size 8
at 0xB72E4CF: virgl_drm_add_res (virgl_drm_winsys.c:629)
by 0xB72E4CF: virgl_drm_emit_res (virgl_drm_winsys.c:663)
by 0xB72A44A: virgl_encode_resource_copy_region (virgl_encode.c:776)
by 0xB40CD12: st_copy_buffer_subdata (st_cb_bufferobjects.c:585)
by 0xB244A3B: _mesa_CopyBufferSubData (bufferobj.c:2940)
by 0x109A1E: upload (invalidate.c:169)
by 0x109C2F: piglit_display (invalidate.c:215)
by 0x4F80FBE: run_test (piglit_fbo_framework.c:52)
by 0x4F66E5F: piglit_gl_test_run (piglit-framework-gl.c:229)
by 0x10949D: main (invalidate.c:47)
Address 0xbe07d30 is 0 bytes after a block of size 4,096 alloc'd
at 0x4C31B25: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0xB72DAAF: virgl_drm_cmd_buf_create (virgl_drm_winsys.c:567)
* Also resize the space allocated for the handles, fixes:
Invalid write of size 4
at 0xB72E4F0: virgl_drm_add_res (virgl_drm_winsys.c:631)
by 0xB72E4F0: virgl_drm_emit_res (virgl_drm_winsys.c:663)
by 0xB72A44A: virgl_encode_resource_copy_region (virgl_encode.c:776)
by 0xB40CD12: st_copy_buffer_subdata (st_cb_bufferobjects.c:585)
by 0xB244A3B: _mesa_CopyBufferSubData (bufferobj.c:2940)
by 0x109A1E: upload (invalidate.c:169)
by 0x109C2F: piglit_display (invalidate.c:215)
by 0x4F80FBE: run_test (piglit_fbo_framework.c:52)
by 0x4F66E5F: piglit_gl_test_run (piglit-framework-gl.c:229)
by 0x10949D: main (invalidate.c:47)
Address 0xbe08570 is 0 bytes after a block of size 2,048 alloc'd
at 0x4C2FB0F: malloc (
in /usr/lib/valgrind/vgpreload_memcheck-amd64- linux.so)
by 0xB72DAC8: virgl_drm_cmd_buf_create (virgl_drm_winsys.c:572)
Fixes: 4b15b5e803 ("virgl: resize resource bo allocation if we need to.")
v2: - Use REALLOC macro and avoid memory leak when re-allocation fails
- add Fixes tag (both Emil Velikov)
- reorder commit message
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Emulating atomics on top of ssbos can lead to too small max SSBO count,
so let's use the hw-atomics mechanism to expose atomic buffers instead.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
virgl_protocol.h is considered to have it's upstream in the
virglrenderer repository, and somehow these minor differences has
crept in.
Let's sync with the upstream to avoid this.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This moves the evergreen-specific max-sizes out as a driver-cap, so
other drivers with less strict requirements also can use hw-atomics.
Remove ssbo_atomic as it's no longer needed.
We should now be able to use hw-atomics for some stages and not for
other, if needed.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This gets rid of a r600 specific hack in the state-tracker, and prepares
for other drivers to be able to use hw-atomics.
While we're at it, clean up some indentation in the various drivers.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
MaxAtomicCounters has already been assigned in the loop above in the
ssbo_atomic = true case, so this will calculate the same value as the
default.
While we're at it, fixup indentation on the MaxAtomicBufferBindings
assign.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This makes the code a bit easier to follow; we first set up
MaxShaderStorageBlocks, then we either set up a dedicated
MaxAtomicBuffers, or we split MaxShaderStorageBlocks in two.
While we're at it, also make the SSBO-splitting code tolerate the
hypothetical case of having an odd number of SSBOs without incorrectly
dropping the last SSBO.
This has the nice result that the SSBOs and atomic buffers are dealt
with almost completely orthogonally, easing some upcoming patches.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We're doing full c99 now, so there's no point in using the old boolean
type.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
GL_STENCIL_INDEX uses GL_INTENSITY for the border color, which is nicer
to hardware that doesn't read the stencil border value from the X channel.
This fixes a bunch of dEQP tests on Vega & Raven.
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Reported by Coverity: arr_live_ranges is freed in a different branch
than the one in which it was allocated.
Signed-off-by: Ernestas Kulik <ernestas.kulik@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reported by Coverity: data is heap-allocated, but only freed in the
info->index_size != 0 branch.
Signed-off-by: Ernestas Kulik <ernestas.kulik@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Cc: 18.2 <mesa-stable@lists.freedesktop.org>
Now that we have the util function for the default values, we can get rid
of the boilerplate.
v2: Rebase on new gallium caps
Reviewed-by: Rob Clark <robdclark@gmail.com> (v1)
Now that we have the util function for the default values, we can get rid
of the boilerplate.
v2: drop GLSL level in favor of defaults.
v3: Rebase on new gallium caps
One of the pains of implementing a gallium driver is filling in a million
pipe caps you don't know about yet when you're just starting out. One of
the pains of working on gallium is copy-and-pasting your new PIPE_CAP into
each driver. We can fix both of these by having each driver call into the
default helper from their default case, so that both sides can ignore each
other until they need to.
v2: fix i915g build, revert swr change to avoid breaking scons build
(https://travis-ci.org/anholt/mesa/jobs/419739857)
v3: Rebase on 3 new gallium caps.
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Cc: Bruce Cherniak <bruce.cherniak@intel.com>
Cc: George Kyriazis <george.kyriazis@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
As of 07a2098a70, brw_nir_optimize calls nir_remove_dead_variables as
the last optimization. Doing it again is just pointless.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :
testfw_app: ../src/compiler/nir_types.cpp:551: void glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*, unsigned int*): Assertion `!"type does not have a natural size"' failed.
Since this particular variable isn't used, it can be eliminated by
removing unused local variables at the end of the optimization loop.
This makes sense also for valid local variables.
v2: Move additional local variable removal out of optimization loop,
but before large constant removal (Jason/Lionel)
v3: Move the removal at the end of brw_nir_optimize()
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107806
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The "gen_group_get_length" function can return a negative value
and it can lead to the out of bounds group_iter.
v2: printing of "unknown command type" was added
v3: just the asserts are added
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Mirrors
1e40f69483 "ac/surface: fix CMASK fast clear for NPOT textures with mipmapping on SI/CI/VI"
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
No clue what gets fixed by this but both radeonsi and amdvlk do it.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Just mirror the radeonsi bits. Since this is just adding the extra
switch entries for new HW I think this should be fine for stable.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
ac_surface.c: gfx6_compute_surface says
/* DB doesn't support linear layouts. */
Now if we expose linear depth and create a linear depth image
and use CmdCopyImage to copy into it, we can't map the underlying
memory and read it linearly which I think should work.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Page 190 of "Volume 7: 3D Media GPGPU Engine (Haswell)" says the valid
range of the offset is [0, 0FFFFFFFh].
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Fixes failure in the new piglit test
tes-patch-input-array-vec2-index-invalid-rd.shader_test.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Due to having 2 additional RCs for 18.2.
Cc: Dylan Baker <dylan.c.baker@intel.com>
Cc: Juan A. Suarez <jasuarez@igalia.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Andres Gomez <agomez@igalia.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Acked-by: Juan A. Suarez <jasuarez@igalia.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Amber Lake uses the same gen graphics as Kaby Lake, including a id
that were previously marked as reserved on Kaby Lake, but that
now is moved to AML page.
This follows the ids and approach used on kernel's commit
e364672477a1 ("drm/i915/aml: Introducing Amber Lake platform")
Reported-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Many new platforms got added to gen_device_name_to_pci_device_id()
but the error message inside aubinator didn't reflected those
changes. So syncing on the same order to be sure that we are not
missing any now.
Cc: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
According to internal docs, some gen9 platforms have a pixel shader push
constant synchronization issue. Although not listed among said
platforms, this issue seems to be present on the GeminiLake 2x6's we've
tested.
We consider the available workarounds to be too detrimental on
performance. Instead, we mitigate the issue by applying part of one of
the workarounds. Re-emit PUSH_CONSTANT_ALLOC at the top of every batch
(as suggested by Ken).
Fixes ext_framebuffer_multisample-accuracy piglit test failures with the
following options:
* 6 depth_draw small depthstencil
* 8 stencil_draw small depthstencil
* 6 stencil_draw small depthstencil
* 8 depth_resolve small
* 6 stencil_resolve small depthstencil
* 4 stencil_draw small depthstencil
* 16 stencil_draw small depthstencil
* 16 depth_draw small depthstencil
* 2 stencil_resolve small depthstencil
* 6 stencil_draw small
* all_samples stencil_draw small
* 2 depth_draw small depthstencil
* all_samples depth_draw small depthstencil
* all_samples stencil_resolve small
* 4 depth_draw small depthstencil
* all_samples depth_draw small
* all_samples stencil_draw small depthstencil
* 4 stencil_resolve small depthstencil
* 4 depth_resolve small depthstencil
* all_samples stencil_resolve small depthstencil
v2: Include more platforms in WA (Ken).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106865
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93355
Cc: <mesa-stable@lists.freedesktop.org>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Gets rid of hard-coded gpu device path.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This helper is almost a 1:1 copy of tegra_open_render_node().
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Though the SARGB8888 format is used internally through its FourCC value,
it is not a real format as defined by drm_fourcc.h; it cannot be used
with KMS or other interfaces expecting drm_fourcc.h format codes.
Ensure we don't advertise it through the dmabuf format/modifier query
interfaces, preventing us from tripping over an assert.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes: 8c1b9882b2 ("egl/dri2: Guard against invalid fourcc formats")
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Fixes Vulkan CTS CL#2849. Similar to the ANV driver.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
