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>
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>
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>
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>
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>
Samuel Pitoiset