This just stubs things out. Real external semaphore support will come
with VK_KHX_external_semaphore_fd.
Reviewed-by: Chad Versace <chadversary@chromium.org>
This commit just exposes the memory handle type. There's interesting we
need to do here for images. So long as the user doesn't set any crazy
environment variables such as INTEL_DEBUG=nohiz, all of the compression
formats etc. should "just work" at least for opaque handle types.
v2 (chadv):
- Rebase.
- Fix vkGetPhysicalDeviceImageFormatProperties2KHR when
handleType == 0.
- Move handleType-independency comments out of handleType-switch, in
vkGetPhysicalDeviceExternalBufferPropertiesKHX. Reduces diff in
future dma_buf patches.
Co-authored-with: Chad Versace <chadversary@chromium.org>
Reviewed-by: Chad Versace <chadversary@chromium.org>
This is the trivial implementation that just exposes the extension
string but exposes zero external handle types.
Reviewed-by: Chad Versace <chadversary@chromium.org>
This is a complete but trivial implementation. It's trivial becasue We
support no external memory capabilities yet. Most of the real work in
this commit is in reworking the UUIDs advertised by the driver.
v2 (chadv):
- Fix chain traversal in vkGetPhysicalDeviceImageFormatProperties2KHR.
Extract VkPhysicalDeviceExternalImageFormatInfoKHX from the chain of
input structs, not the chain of output structs.
- In vkGetPhysicalDeviceImageFormatProperties2KHR, iterate over the
input chain and the output chain separately. Reduces diff in future
dma_buf patches.
Co-authored-with: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We're about to have more UUIDs for different things so this one really
needs to be properly labeled.
Reviewed-by: Chad Versace <chadversary@chromium.org>
This prevents a user from using a cache created on one hardware
generation on a different one. Of course, with Intel hardware, this
requires moving their drive from one machine to another but it's still
possible and we should prevent it.
Reviewed-by: Chad Versace <chadversary@chromium.org>
Cc: mesa-stable@lists.freedesktop.org
Instead of just advertising the aperture size, we do something more
intelligent. On systems with a full 48-bit PPGTT, we can address 100%
of the available system RAM from the GPU. In order to keep clients from
burning 100% of your available RAM for graphics resources, we have a
nice little heuristic (which has received exactly zero tuning) to keep
things under a reasonable level of control.
Reviewed-by: Kristian H. Kristensen <krh@bitplanet.net>
This commit adds support for using the full 48-bit address space on
Broadwell and newer hardware. Thanks to certain limitations, not all
objects can be placed above the 32-bit boundary. In particular, general
and state base address need to live within 32 bits. (See also
Wa32bitGeneralStateOffset and Wa32bitInstructionBaseOffset.) In order
to handle this, we add a supports_48bit_address field to anv_bo and only
set EXEC_OBJECT_SUPPORTS_48B_ADDRESS if that bit is set. We set the bit
for all client-allocated memory objects but leave it false for
driver-allocated objects. While this is more conservative than needed,
all driver allocations should easily fit in the first 32 bits of address
space and keeps things simple because we don't have to think about
whether or not any given one of our allocation data structures will be
used in a 48-bit-unsafe way.
Reviewed-by: Kristian H. Kristensen <krh@bitplanet.net>
When a client causes a GPU hang (or experiences issues due to a hang in
another client) we want to let it know as soon as possible. In
particular, if it submits work with a fence and calls vkWaitForFences or
vkQueueQaitIdle and it returns VK_SUCCESS, then the client should be
able to trust the results of that rendering. In order to provide this
guarantee, we have to ask the kernel for context status in a few key
locations.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's possible that the device could have been lost while we were
waiting. We should let the user know if this has happened.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If we know the device has been lost we should return this error code for
any command that can report it before we attempt to do anything with the
device.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The Vulkan specs say:
"A logical device may become lost because of hardware errors, execution
timeouts, power management events and/or platform-specific events. This
may cause pending and future command execution to fail and cause hardware
resources to be corrupted. When this happens, certain commands will
return VK_ERROR_DEVICE_LOST (see Error Codes for a list of such commands).
After any such event, the logical device is considered lost. It is not
possible to reset the logical device to a non-lost state, however the lost
state is specific to a logical device (VkDevice), and the corresponding
physical device (VkPhysicalDevice) may be otherwise unaffected. In some
cases, the physical device may also be lost, and attempting to create a
new logical device will fail, returning VK_ERROR_DEVICE_LOST."
This means that we need to track if a logical device has been lost so we can
have the commands referenced by the spec return VK_ERROR_DEVICE_LOST
immediately.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
So that we don't have to do things like rolling back address relocations in
case that we ran into OOM after computing them, etc
Also, make sure that if the queue submission comes with a fence, we set it up
correctly so it behaves according to the spec after returning
VK_ERROR_DEVICE_LOST.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The query is a properties query so it needs to be handled in
GetPhysicalDeviceProperties2, not GetPhysicalDeviceFeatures2.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
In the end, pipeline statistics queries look a lot like occlusion
queries only with between 1 and 11 begin/end pairs being generated
instead of just the one.
Reviewed-By: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Now that there's a timebase_scale in gen_device_info which is
effectively the 'period' this switches anv_GetPhysicalDeviceProperties
to using this common device info to initialize the timestampPeriod
device limit.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Older versions of GCC don't like compound literals in static const
variable declarations because they don't think it's an actual constant
value.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Any errors that may have happened during the command buffer recording are
reported by vkEndCommandBuffer() and it is the application's reponsibility
to not submit broken commands to a queue.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
drmGetDevices2() provides us with enough flexibility to build heuristics
upon. Opening a random node on the other hand will wake up the device,
regardless if it's the one we're interested or not.
v2: Rebase, explicitly require/check for libdrm
v3: Return VK_ERROR_INCOMPATIBLE_DRIVER for no devices (Ilia)
v4: Rebase
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Tested-by: Mike Lothian <mike@fireburn.co.uk>
This patch adds missing error-checking and fixes resource leak in
allocation failure path on anv_CreateDevice()
v2: Fixes from Jason Ekstrand's review
a) Add missing destructors for all of the state pools on allocation
failure path
b) Add missing destructor for batch bo pools on allocation failure path
v3: Fixes from Emil Velikov's review
Add missing destructor for queue and scratch_pool on allocation failure
path
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
No intended change in behavior. Just a refactor.
v2: Replace vk_outarray_is_incomplete() with vk_outarray_status(). For
Jason.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The number of dynamic descriptors is limited by both the number of
descriptors and the total number of dynamic things. Because there isn't
a single "maximum dynamic things" limit, we need to divide by two so
that they can create the maximum of both UBOs and SSBOs.
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Cc: "17.0 13.0" <mesa-stable@lists.freedesktop.org>
Except for a few unimplemented things on gen7, we don't really have
stubs anymore so we should drop this. This commit replaces the few gen7
stub() calls with explicitly labeled finishme's and makes the sparse
binding stuff silently no-op or return a FEATURE_NOT_PRESENT error.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
We're about to use the build-id as the starting point for another SHA1
hash in the Intel Vulkan driver, and returning a pointer is far more
convenient.
Reviewed-by: Chad Versace <chadversary@chromium.org>
We've been following the spec changes.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
This allows the helper to check for llc instead of having to do it
manually at all the call sites.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
All this cache line address calculation stuff is tricky. Let's not
duplicate it more places than we have to.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
It's a bit shorter and easier to work with. Also, we're about to add a
helper called clflush which does the clflush but without any memory
fencing.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4c9dec80ed ("anv: Get rid of the ANV_CALL macro")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
This adds support to radv_GetPhysicalDeviceXlibPresentationSupportKHR
and radv_GetPhysicalDeviceXcbPresentationSupportKHR to check if the
local device file descriptor is compatible with the descriptor
retrieved from the X server via DRI3.
This will stop radv binding to an X server until we have prime
support in place. Hopefully apps use this API before trying
to render things.
v2: drop unneeded function, don't leak memory. (jekstrand)
v3: also check in surface_get_support callback.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The --build-id=... ld flag has been present since binutils-2.18,
released 28 Aug 2007.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
