`d3d12_destroy_screen` is called by `d3d12_create_dxcore_screen` after
`d3d12_init_screen_base` fails and attempts to call `util_dl_close` on
a NULL pointer, leading to an abort.
To fix this, only close the library after if it was actually opened.
Cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20145>
D3D12_REQ_TEXTURE3D_U_V_OR_W_DIMENSION is 2^11, not 2^10 like the
comment said, and the code assumed. We need to add one to account for
the base-level.
Let's add a static_assert here to prove that this is the right value.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
We used to need this, because we incorrectly multiplied the cube array
sizes by 6. Now that this has been fixed, we can actually support the
OpenGL 4.1 limit for this.
Fixes: 7118b2136e ("d3d12: Don't multiply cube array sizes by 6")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19780>
Supported in all hardware and software drivers. Only that don't support
are virgl and svga, depending on host capabilities. I don't think
there's anything to be done there. This does give fewer places to screw
up the CAPs, though, because everyone wants ARB_buffer_storage.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Marek Ol<C5><A1><C3><A1>k <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19392>
Mis-matched usage is a large percentage of buffer cache misses when
searching for applicable buffers. Separating these into separate
managers puts them into separate heaps and eliminates a significant
amount of CPU time spent searching.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19283>
The ideal would be to use a D3D12Core.dll next to the GL DLL, via
ID3D12SDKConfiguration1, but this requires a new D3D12.dll to be
present on the machine, which only very new OSes will currently have.
For older OSes, we can at least try to use ID3D12SDKConfiguration to
set a global Agility SDK override, but that only works in developer
mode and requires the DLL to be at a relative path from the app EXE,
so only try that if we have environment variables telling us to do so.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18305>
As explained in a comment, a device factory allows modification of state
like debug layer enablement without touching global state / triggering
device removal on a singleton device, and can even create devices that are
not singletons if the driver supports that.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18305>
The GLSL singleton ref was too late, and we could end up with an un-paired
dec-ref if screen init failed. Also the transfer slab init was in the wrong
init function, so we'd re-init that struct if the screen was re-initialized.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18305>
There are three tiers of drivers:
* Drivers that support MRT and support mixed colorbuffer formats. All modern
hardware fits this as it becomes a spec requirement.
* Drivers that do not support MRT. Then this CAP is a no-op, so we might as well
set it by default even here (this commit trivially enables the CAP for lima,
vc4, etanviv).
* Drivers that support MRT but do not support mixed colorbuffer formats! Very
little hardware fits this category as it doesn't suffice for MRT in most APIs.
Unfortunately we have a few drivers that are in this category, preventing us
from bulldozing the CAP altogether.
Given that the CAP only exists for a few legacy drivers, default it to being
enabled to avoid new drivers falling into the trap of forgetting to enable it.
Failing to set this CAP causes failures in
dEQP-GLES3.functional.fbo.completeness.*
Drivers which still do not set this CAP: nv30, r300 (older than r500), virgl in
some cases. r300/r400 is due to a hardware requirement as Emma points out.
v2: Advertise the cap on lima like the commit message claims (delete the special
case).
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19079>
All current drivers reports supporting this cap, let's just assume
it's always supported.
It seems better to lower this in the drivers, like we already do for
etnaviv, panfrost and zink...
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Begrudgingly-reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19049>
Instead of not reporting support for the pixel format at all, just
disable swapchain creation.
Some apps want to create off-screen contexts targeting these formats,
but since WGL doesn't really have "off-screen," the pixel format
enumeration should return support for these.
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18326>
When a resource is destroyed, we'll need to let the contexts know.
This is guarded by the submit mutex, because we'll already be holding
that for at least one place where we want to iterate this list, and
it's low-frequency enough that re-using it is simpler than adding more
locks and creating confusing lock ordering.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17688>
If the memobj wraps a resource, then we only succeed the
mapping operation if the gallium desc matches the D3D12
resource desc.
If the memobj wraps a heap, then we can place whatever
gallium is describing on the heap.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446>
The drivers not setting it were:
- nv30, which gets lowering using NIR's lower_fsat flag.
- r300, which gets lowering using NIR's lower_fsat flag.
- a2xx, which has was getting it optimized back to fsat anyway.
This drops the check for the cap from gallium nine. While nine does have
a non-nir path, I think it's safe to assume that if you have SM3
texturing, you can do fsat.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16823>
This is used for the old, buggy and slow GLSL IR loop unrolling
code. All drivers have now switched to the NIR unrolling code so
here we remove the CAP.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16366>
Now that all consumers of GLSL use NIR, make the remaining drivers take
the path that relies on NIR to really do optimization.
nouveau steam shader-db runtime -6.69631% +/- 1.29235% (n=12).
No change on shader-db there.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16364>
The only interesting ones here were LOWER_IF_THRESHOLD (which previously
had connected to some lowering in GLSL that was broken in the face of side
effects), and FMA (which turned GLSL IR's fma() into TGSI_OPCODE_FMA
instead of MAD).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8044>
This will only work if all contexts have been destroyed. If the app
attempts to re-create one context, while another outstanding context
exists and is still in the removed state, then the screen is not
recovered and the new context will fail to create.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15002>
This also breaks screen init/deinit into two parts. The first part of
creation cannot fail, and is not repeatable. The second part of creation
can fail, and is repeatable, to be used for reset recovery.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15002>
We can at least correctly return whether the context was lost, but
at this point can't correctly tear down and create a new one, nor
do we support the callback for dynamic notification.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15002>
On platforms where we're not using DXGI swapchains, there's no reason
to disallow DISPLAY for formats like B5G6R5. In fact, on Android,
we need to support this format as BIND_DISPLAY.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16154>
These aren't spiecic to TGSI any more, so let's rename them to reflect
reality.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15316>
These aren't specific to TGSI, so let's rename them to reflect the
reality.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15316>
