This does the exact opposite of 06e96074 from !16129.
Before LLVM commit 702d5de4 opaque pointers were supported but not enabled
by default when building LLVM. They were made default in commit 702d5de4.
LLVM commit d69e9f9d introduced -opaque-pointers/-no-opaque-pointers cc1
options to enable or disable them whatever the LLVM default is.
Those two commits follow llvmorg-15-init and precede llvmorg-15.0.0-rc1 tags.
Since LLVM commit d785a8ea, the CLANG_ENABLE_OPAQUE_POINTERS build option of
LLVM is removed, meaning there is no way to build LLVM with opaque pointers
enabled by default.
It was said at the time it was still possible to explicitly disable opaque
pointers via cc1 -no-opaque-pointers option, but it is known a later commit
broke backward compatibility provided by -no-opaque-pointers as verified with
arbitrary commit d7d586e5, so there is no way to use opaque pointers starting
with LLVM 16.
Those two commits follow llvmorg-16-init and precede llvmorg-16.0.0-rc1 tags.
Since Mesa commit 977dbfc9 opaque pointers are properly implemented in Clover
and used.
If we don't pass -opaque-pointers to Clang on LLVM versions supporting opaque
pointers but disabling them by default, there will be an API mismatch between
Mesa and LLVM and Clover will not work.
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19290>
This reverts commit 06e9607478 from !16129.
Clover passed -no-opaque-pointers option to Clang to workaround the fact
the Clover code was not ported to opaque pointers yet.
Opaque pointers are now implemented thanks to !19103 so passing this
option to tell Clang to not do opaque pointers while Clover does
is actually breaking Clover.
Here is an example of what happens when using opaque pointers while
passing -no-opaque-pointers at the same time:
fatal error: cannot open file 'hawaii-amdgcn-mesa-mesa3d.bc':
Opaque pointers are only supported in -opaque-pointers mode
This fixes one of the last remaining bits to fully support opaque pointers
in Mesa as referenced in #7468, this is the last remaining bit to fully support
opaque points in Clover.
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19290>
[problem]
When decoding an av1 bitstream, it shows image corruption
in the middle of the bitstream around key frames.
[analysis]
in av1_spec.pdf page 38/669, there is a sentence below:
if ( frame_type == KEY_FRAME && show_frame ) {
for ( i = 0; i < NUM_REF_FRAMES; i++) {
RefValid[ i ] = 0
......
}
......
}
This shows that the condition of invalidating current
DPB frames should be the coming frame_type is KEY_FRAME plus
show_frame is equal to 1. Otherwise, some of the frames
in sequence after KEY_FRAME still refer to the reference frames
before KEY_FRAME, and if these before KEY_FRAME reference
frames were invalidated, these frames could not find their
reference frames, and it could cause image corruption.
[solution]
Add condition of show_frame, with the corresponding fix
in ffmpeg, we cannot see this issue any longer.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386>
Allows to make Clover devices appearing as cpu, gpu or accelerator
by setting the CLOVER_DEVICE_TYPE environment variable like
the RUSTICL_DEVICE_TYPE environment variable does.
For example it can make the CPU llvmpipe device appear as GPU or GPU devices
appear as CPU. This is useful for testing OpenCL with applications that may
use different code path given the OpenCL device is a CPU or a GPU.
The initial motivation for RUSTICL_DEVICE_TYPE implementation was to test
rusticl with llvmipe on applications ignoring CPU devices.
This brings Clover on par with rusticl on that topic.
CL_DEVICE_TYPE_CUSTOM isn't implemented or applications may crash when
iterating devices because CL_DEVICE_TYPE_CUSTOM is OpenCL 1.2 and Clover
is OpenCL 1.1.
Signed-off-by: Thomas Debesse <dev@illwieckz.net>
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18931>
As a memory object, the MemConstant check should be the same as
MemGlobal.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19352>
Replace tabs with spaces. Rename __ATTRIB macro to SIMPLE_CASE to
be a bit more readable.
NFC.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19329>
Replace tabs with spaces, fix indentation.
Move 'format' var decl and type (it's an integer array index, not
actually a mesa format).
NFC.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19329>
The usage of global constructor should be limited, only in absolutely needed case.
The call style of xlib_create_screen referenced to osmesa_create_screen
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19258>
For simple clients using the swap chain contention back pressure to regulate
their drawing and that don't query buffer age introduce a new DRI option with
which set to true (the default is false) we block the client until a new buffer
is available. This way we stall the client's execution until a new buffer is
available and the redrawing of the client starts only at this point and not
before.
The motivation for that is to reduce latency for clients that regulate their
drawing by swapchain contention back pressure. These clients draw whenever
possible and their drawing is implicitly stopping whenever we block. When we
block at the end of the swap and return only when a new buffer is available
the client can draw and we directly present. Otherwise the client would draw,
we block on the buffer becoming available, and only then show what the client
had drawn, usually one frame later.
Co-authored-by: Michel Dänzer <michel@daenzer.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14684>
this is supposed to return the address at the start of the buffer,
not the address at the start of the memory allocation
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19274>
This literal is consistence with st_api::name comes from global variable
st_gl_api that will be removed in following commits
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19197>
It's a global variable and have no need destroy
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19197>
So far `lengths` as been interpreted as a slice of usize. However, 0 is specified as a sentinel
value signalling that the corresponding string is nul terminated. Since checking for sentinel
values is frequently forgotten, Option types should be preferred if possible.
Option<NonZeroUsize> is layout compatible with usize. The None variant is then represented as 0,
which is exaclty what we need here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18978>
The code assumed that if the length of a string was specified and greater than zero, the string
would not contain a nul byte.
Legal or not, there are apparently applications which violate that assumption. Since the spec
doesn't say anything about this case, take the likely most compatible route and treat a nul byte as
terminating the string early.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7408
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18978>
