This uses APIs that are not available on Win7. Since this is a build-time
configuration, and since we can't use the SDK version as an indicator
(since you can support Win7 via new SDKs), a new option is added to allow
disabling it, to maintain Win7 support if desired.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17431>
This option has no meaningful effect any more other than pointlessly
renaming the the library. Let's introduce a new default value called
"unspecified", and complain if it's set to anything else.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16213>
Add a new backend to enable using native driver in a VM guest, via a new
virtgpu context type which (indirectly) makes host kernel interface
available in guest and handles the details of mapping buffers to guest,
etc.
Note that fence-fd's are currently a bit awkward, in that they get
signaled by the guest kernel driver (drm/virtio) once virglrenderer in
the host has processed the execbuf, not when host kernel has signaled
the submit fence. For passing buffers to the host (virtio-wl) the egl
context in virglrenderer is used to create a fence on the host side.
But use of out-fence-fd's in guest could have slightly unexpected
results. For this reason we limit all submitqueues to default priority
(so they cannot be preepmted by host egl context). AFAICT virgl and
venus have a similar problem, which will eventually be solveable once we
have RESOURCE_CREATE_SYNC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14900>
MESA_SHADER_READ_PATH is handy but it's not usable in
all cases.
This commit allows to implement an alternative mechanism
without assuming too much about how it's done, nor where/how
the shaders are stored.
When this is enabled MESA_SHADER_DUMP_PATH,
MESA_SHADER_CAPTURE_PATH and MESA_GLSL env var handling is
disabled.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11621>
Add a moltenvk-dir build option to supply the MacOS Vulkan SDK MoltenVK location.
Force compiler, for zink only, into object-c mode when MoltenVK is used to allow for the MacOS ioSurface and CAMetalLayer types that the headers expose.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11129>
This change adds a gallium D3D10 state tracker that works as a WDDM UMD
software driver, similar to Microsoft WARP, but using llvmpipe/softpipe.
The final deliverable is a d3d10sw.dll, which is similar to WARP's
d3d10warp.dll.
This has been used to run Microsoft Windows HCK wgf11* tests with
llvmpipe, and they were at one point passing 100%.
Known limitations:
- TGSI (no NIR)
- D3D10 only (no D3D11 support yet)
- no WINE integration (WINE doesn't implement WDDM DDI.)
For further details see:
- src/gallium/frontends/d3d10umd/README.md
- src/gallium/targets/d3d10sw/README.md
v2: Drop the DXBC-based disassembly. Add missing break statements.
v3: Incorporate Jesse's feedback.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10687>
With the idea of branching classic device support in to its own tree now would be a good time to also raise the minimum
requirements to something that is more "modern" on x86.
SSE2 was introduced in 2000(!) by default let's make it the minimum spec now
All the old hardware that is moving to the maintenance branch will finally be out of the way.
For the 64-bit side of the discussion there isn't much changed.
* GCC already enables -msse and -msse2 by default
* Same with clang
* fpmath=sse might remove some extraneous x87 usage
** Clang implies fpmath=sse ALWAYS
For the 32-bit side of things is where the exciting details change
* GCC by default doesn't enable sse1 or sse2
** Does all `float`, `double`, and `long double` math with x87
** -msse2 enables sse2 and sse1, gcc still uses x87 even with those enabled
** -mfpmath=sse moves away from using x87 and instead uses sse1 and sse2
* Clang already default enables sse1/sse2 which then turns on their implied fpmath=sse
What does this mean for users?
On Linux raises the default minimum processor spec to SSE2 supporting CPUs
* Intel requirements raise from P5 (1993) to Netburst (2000)
* AMD requirements raise from Athlon(1999/2000) to Athlon 64 (2003)
* Via requirements raise from C3(2001) to C7 (2005)
What does it mean for package maintainers?
For x86-64 distributions that have i386/i686 multilib, then nothing changes. You're already on a platform guaranteed to support SSE2.
For i386/i686 distributions they will need to weigh their min spec against this. Not sure how many still support classic processors.
Who is left out in the cold?
* Intel Quark (2013)
** Embedded board, doesn't have a GPU, Technically has 1x PCIe 2.0 lane that someone could plug a GPU in to
* Some older transmeta CPUs, but they had a followup that also had SSE2.
** Anyone hacking on these with a modern GPU? I'm guessing they know how to turn this option off
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9868>
We'd like to use one Mesa build environment which builds our CL compiler
stack (which needs Clang/LLVM) and which builds our GL driver. The GL
driver doesn't really need LLVM support, and since we're statically
linking LLVM, removing it from the driver drastically reduces our DLL
size on disk.
Acked-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9259>
The classic OSMesa renders directly into user memory using
src/mesa/swrast, while gallium OSMesa renders using softpipe or llvmpipe
and copies out at glFlush() time. This would make gallium look like a
worse choice for OSMesa, except that swrast is:
1) Painfully slow to render compared to llvmpipe
2) Incorrect at derivatives
3) Limited to GL 2.1 instead of GL 4.6
In my survey of OSMesa users, debian was the remaining holdout with
classic OSMesa in use on hurd and some rare non-LLVM-supported
architectures (sh4, alpha, etc.). As of today, they've switched to
softpipe-based gallium OSMesa for them.
To prevent people from running the wrong OSMesa (to the extent that
running OSMesa can ever be the right thing), delete the classic
version.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Closes: #320Closes: #877Closes: #2297
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243>
