Fix defects reported by Coverity Scan.
uninit_member: Non-static class member m_maxBaseAlign is not initialized in this constructor nor in any functions that it calls.
uninit_member: Non-static class member m_maxMetaBaseAlign is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7768>
For blit/compute non-draw batches, we are already emitting traces in the
draw cmdstream, which means we cannot also have traces in the GMEM ring
(as that breaks the FIFO ordering of traces)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7818>
This adds a mechanism, loosely inspired by the linux kernel's tracepoint
mechanism, to declare and emit tracepoints. A driver provided callback
is used to emit cmdstream to capture timestamps on the GPU, which are
used to later "render" the emitted tracepoints.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7818>
Add a helper to get debug options that specify a file path, with
additional checking for suid to prevent unintended file access via
mesa's debug features.
Unlike other DEBUG_GET_ONCE_*, this returns a new file ptr each time
it is called (although it only does the lookup of the path once).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7818>
This is completely untested!
In commit 3175b63a0d, Marek stopped
allocating the GLmatrix::inv field with malloc, instead embedding
it directly in the structure. So, we need to drop a level of
indirection here and use (matrix pointer + MATRIX_INV) as the
inverse matrix array directly, rather than reading a pointer at
that offset and chasing it.
Fixes: 3175b63a0d ("mesa: don't allocate matrices with malloc")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7889>
In commit 3175b63a0d, Marek stopped
allocating the GLmatrix::inv field with malloc, instead embedding
it directly in the structure. So, we need to drop a level of
indirection here and use (matrix pointer + MATRIX_INV) as the
inverse matrix array directly, rather than reading a pointer at
that offset and chasing it.
Fixes: 3175b63a0d ("mesa: don't allocate matrices with malloc")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7889>
Z scaling case without nearest filter needs a 3D texture, so add a 3D
texture path and use it to cover all scaling/mirroring cases.
The "rotation" argument for the clear/blit "setup" function is replaced
with a more generic "blit_param", which has a different meaning for the
3D blit path. (to avoid having too many arguments)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7781>
Building svgadrm module on window platform is not required.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7806>
Unlike the other drivers, the D3D12 driver is hardware accelerated, so
it's going to be a more reasonable choice. So let's prefer it.
This only matters for people who build with the D3D12 driver. And they
can set the GALLIUM_DRIVER environment variable as appropriate to
override it.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7534>
Setting these avoids a few warnings while running glxgears on Zink on
Lavapipe. There's a lot more flags to set here, but this is better than
nothing.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7879>
In the following sequence:
- transfer_map(buffer, DISCARD) // use staging upload
- memcpy(...)
- transfer_unmap
- draw
- transfer_map(buffer, UNSYNCHRONIZED) // non-staging upload
- memcpy(...)
- draw
Currently the order of operations is:
- map#1 - staging buffer
- memcpy to staging buffer
- map#2
- memcpy to buffer
- staging buffer copy to real buffer
- draw#1
- draw#2
When the 2nd map operation doesn't use UNSYNCHRONIZED, the tc_sync_msg() call
will make sure that the bo is unused before mapping it.
But, if it does use UNSYNCHRONIZED and the mapped intervals overlap this commit
clears the UNSYNCHRONIZED to make sure ordering is maintained.
This will affect performance, but correct output is better than fast output.
See https://gitlab.freedesktop.org/mesa/mesa/-/issues/3611.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7098>
This introduces a new flag in shader_info to know if a fragment
shader uses sample shading, even if there is no inputs.
During NIR linking, constants varyings are optimized and the
per-sample interpolation info (ie. the sample qualifier) might
be removed if nir_shader_gather_info() is called again.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7876>
It's a little unclear from the GLX_ARB_create_context spec whether the
list of supported extensions means what the client supports at all, or
what it knows an indirect GLX encoding for. You'd think it could only
really matter for indirect, since the only way the server would know
about GL commands (as opposed to GLX commands) is if the context was
indirect. And indeed for Xorg's GLX it doesn't matter, because it
doesn't check this, assuming that anything a direct client says works
works, and clamping the GL version based on the protocol it has code
for.
But if you're NVIDIA, apparently, you check this even for direct
contexts. And since drisw creates a nominally "direct" context, this
means llvmpipe and friends get clamped to 3.0 for desktop GL (since
that's as far as the protocol is defined) and can't do GLES at all.
So, whatever, just go ahead and claim to support everything. The wire
representation of the supported versions is strange (see comments in the
code) but it matches what NVIDIA does.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
This is Sort Of handled by nerfing GL_VERSION in __indirect_glGetString,
but that doesn't cover GLES contexts which we also don't have any
indirect support for. Xorg's GLX would reject this for us since it has
the same limitation, but NVIDIA's GLX seems to interpret a request for
ES 2.0 as desktop, despite having the ES2 profile bit set, leading to a
very confusing GL_VERSION string and probably not the ES2-compatible
context you were hoping for.
Since we may now return NULL from indirect_create_context_attribs for
reasons other than malloc failure, we need to reasonably handle the case
where gc == NULL by the time we get to the XCB call. We rely on the
server to generate correct return values in this case, but if it
succeeds despite our client-side failure we just throw GLXBadFBConfig
(chosen to keep piglit/glx-create-context-core-profile happy, since
nothing else seems to hit it).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
llvmpipe was reporting 32 max const buffers, while sizing its arrays to 16
according to gallivm's #define.
Fixes: 1d35f77228 ("gallivm,llvmpipe,draw: Support multiple constant buffers.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
If you dlclose your driver, the leak reports look like:
#0 0xffff9c7e5e7c in malloc (/lib/aarch64-linux-gnu/libasan.so.6+0x9ee7c)
#1 0xffff94aaaa48 (<unknown module>)
#2 0xffff94aa5ff4 (<unknown module>)
#3 0xffff94d1867c (<unknown module>)
#4 0xffff94d184f0 (<unknown module>)
#5 0xffff94c9a990 (<unknown module>)
#6 0xffff94c92e30 (<unknown module>)
#7 0xffff94c91d48 (<unknown module>)
#8 0xffff946eb800 (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0xfe800)
#9 0xffff94c72874 (<unknown module>)
#10 0xffff946ede68 (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0x100e68)
#11 0xffff94bf7134 (<unknown module>)
#12 0xffff9c686450 in dri2_create_screen ../src/egl/drivers/dri2/egl_dri2.c:1079
which is not terribly useful. Probe if we're building with asan and just
skip closing the driver in the happy path (which seems to be the standard
practice for loadable modules with this tool).
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
[[fallthrough]] is not a C17 feature, and MSVC does not support it.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Tony Wasserka <tony.wasserka@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7862>
This is only required for the DRI-path. For the swrast code-path, we
don't need this.
We also don't need to explicitly test for it in the DRI-path, because we
test for KHR_external_memory_fd, which depends on KHR_external_memory. So
no implementation will expose the former without the latter.
Fixes: f1432fd3e2 ("zink: generate extension infrastructure using a python script")
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7882>
Three things:
1. MSVC dislikes mismatching declaration/definition of __declspec(dllexport).
Since CL headers don't have the declspec, the implementations should't either.
2. An unnamed brace-initialization gets deduced as an initializer list, instead
of a brace-constructed string. Just add the type name.
3. posix_memalign doesn't exist on Windows.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680>
Constructing a class where the class name is wrapped in parens
doesn't work with MSVC. I see no good reason to do that so drop
the parens. Also, use a generic page size helper instead of hardcoding
something OS-specific.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680>
Two things:
1. While instantiating a template where clover::llvm and ::llvm are
both resolvable for unscoped llvm, MSVC complains about ambiguity.
Resolve by not using namespace clover, leaving only ::llvm as a
valid namespace.
2. LLVM headers (specifically Allocator.h) use __declspec(restrict),
but Mesa's util headers #define restrict to __restrict for C++.
Since __declspec(__restrict) is invalid, make sure we always include
Allocator.h first before the util header.
3. Change a uint/int to uint64_t to match the type returned from LLVM.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7680>
