Freshly allocated BOs from libdrm have to be zeroed. Since the libdrm/iris
caches VRAM allocations, we don't want to attach/detach parts of dataspaces at
every allocation. Some objects are used long (through caching in the iris
Gallium driver). Therefore, zero object on release where the region might
already be mapped.
issue #5224
Prerequisites for Mesa 24.0.1
* generic:
* add patch to retrieve PCI/Platform information from Genode side of the DRM
interface (in drmGetDevice2)
* add generated 'fourcc' file
* iris:
* report back-end (currently 'i915', 'xe' is unsupported)
* add various I915_CONTEXT_PARAM* and I915_PARAM*
* allocate 'Buffer's starting with ID 1 (0 is invalid)
* enforce 48-bit-address limit on unmap also
* disable I915_EXEC_FENCE_ARRAY array check, because we do not support
sync objects right now and rendering in synchronous
* etnaviv:
* create 'Fenceobj' only *once* for each GPU context
issue #5224
This commits updates the contrib sources to version 8.7.1.
This version requires more random entropy as it queries OpenSSL
about the current random state and will bail if it is not sufficient.
Doubling the content of the '<inline>' VFS plugin as used in static
configurations seems satisfactory.
Furthermore DNS resolving needs a configured '<pipe>' plugin to work
properly.
Fixes#5184.
This patch was back ported from upstream Mesa and generalizes the memory
management of buffer objects used by the binder. Before this patch the
binder was treated as a special case where buffer objects were allocated
with a simple "next block or wrap" allocator. With this commit the
binder now uses the vm_heap allocators as done by all other buffer
allocations which leads to issues with reference counting and object
destruction being resolved.
Original commit message:
We're moving towards a path where all contexts share the same virtual
memory - because this will make implementing vm_bind much easier - ,
and to achieve that we need to rework the binder memzone. As it is,
different contexts will choose overlapping addresses. So in this patch
we adjust the Binder to be 1GB - per Ken's suggestion - and use a real
vma_heap for it. As a bonus the code gets simpler since it just reuses
the same pattern we already have for the other memzones.
Internally libyuv uses malloc & free for short time dynamic memory
allocation during image transformation. The converted images are
such large, that the Libc allocator will create and destroy new Genode
dataspace per image. In time sensitive code paths, the overhead can be
noticeable by the caller of the image transformation.
The patch adds the option to register callbacks in the libyuv library to
implement the image allocation by users of the library. They may implement
caching strategies to avoid the overhead, e.g. as seen with qemu-usb and
the webcam model.
The main user of libsparkcrypto in the past was the CBE block encryption
ecosystem. However, the CBE was replaced with the Tresor block encryption that
uses libcrypto instead.
Ref #4819
The original size of 16K impedes the batched processing of network
packets. Changing the value to 256K reduces the number of context
switches when downloading large files and thereby improves the
throughput by more than 25% (base-hw on qemu_x86_64, using fetchurl
to download a file of 100 MiB via the NIC router from lighttpd).
Issue #4697
