Currently u_math needs gallium utils for cpu detection. Most of what
u_math uses out of u_cpu_detection is duplicated in src/mesa/x86
(surprise!), so I've just reworked it as much as possible to use the
x86/common_x86_features.h macros instead of the gallium ones. The mesa
implementation is a header only approach, with no external dependencies.
There is one small function that was copied over, as promoting
u_cpu_detection is itself a fairly hefty undertaking, as it depends on
u_debug, and this fixes the bug for now.
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107870
Tested-by: Vinson Lee <vlee@freedesktop.org>
Unlike the other platforms, here we aim do guess if the device that we
somewhat arbitrarily picked, is supported or not.
In particular: when a vendor is _not_ requested we loop through all
devices, picking the first one which can create a DRI screen.
When a vendor is requested - we use that and do _not_ fall-back to any
other device.
The former seems a bit fiddly, but considering EGL_EXT_explicit_device and
EGL_MESA_query_renderer are MIA, this is the best we can do for the
moment.
With those (proposed) extensions userspace will be able to create a
separate EGL display for each device, query device details and make the
conscious decision which one to use.
v2:
- update droid_open_device_drm_gralloc()
- set the dri2_dpy->fd before using it
- return a EGLBoolean for droid_{probe,open}_device*
- do not warn on droid_load_driver failure (Tomasz)
- plug mem leak on dri2_create_screen failure (Tomasz)
- fixup function name typo (Tomasz, Rob)
v3:
- add forward declaration for droid_load_driver()
Fixes the HAVE_DRM_GRALLOC build (Mauro)
- split dup() assignment and check in separate lines (Tomasz, Eric)
- make droid_load_driver() static (Tomasz)
- drop unused prop_set variable (Tomasz)
v4:
- rebase
- fwd declarationi should be for droid_probe_device()
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Tomasz Figa <tfiga@chromium.org>
Cc: Mauro Rossi <issor.oruam@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
do_assignment validated assigment but when rhs type was not compatible
it proceeded without issues and returned error_emitted = false.
On the other hand process_initializer expected do_assignment to always
return compatible type and never fail.
As a result when variable was initialized with incompatible type
the type of variable changed to the incompatible one.
This manifested in unnecessary error messages and in one case in crash.
Example GLSL:
vec4 tmp = vec2(0.0);
tmp.z -= 1.0;
Past error messages:
initializer of type vec2 cannot be assigned to variable of type vec4
invalid swizzle / mask `z'
type mismatch
operands to arithmetic operators must be numeric
After this patch:
initializer of type vec2 cannot be assigned to variable of type vec4
In the other case when we initialize variable with incompatible struct,
accessing variable's field leaded to a crash. Example:
uniform struct {float field;} data;
...
vec4 tmp = data;
tmp.x -= 1.0;
After the patch there is only error line without a crash:
initializer of type #anon_struct cannot be assigned to variable of
type vec4
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
The only thing that matters is the size since we never specify any
offsets in terms of blocks.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
All CTS pass on Polaris/Vega with LLVM 6, 7 and master, so
I think it's safe to enable the feature.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Fixes:
dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.depth_stencil.d32_sfloat_s8_uint_d32_sfloat_s8_uint.optimal_optimal_nearest
And all friends that try to blit a surface with different
depth and stencil formats.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
If we update the program-state etc, we risk compiling needless shaders,
which can cost quite a bit of performance.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
CC: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 82799a5d1b8 ("nir: Add a small pass to rematerialize derefs
per-block")
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
The lcssa and phis_to_regs passes are used by various NIR optimizations
that modify the CFG. Putting a couple of asserts will help ensure that
we don't accidentally put derefs in phis as part of an optimization
pass.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
When we're about to re-arrange a bunch of blocks, it's a good idea to
make sure that we don't have deref uses crossing block boundaries.
Otherwise we may end up with a deref going through a phi and that would
be bad.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
This pass re-materializes deref instructions on a per-block basis to
ensure that every use of a deref occurs in the same block as the
instruction which uses it.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
This reverts commit 90819abb56.
This logic was wrong, the original code is correct. The direct
impact is that we allocate up to approximately a squared amount
of memory compared to what we should allocate.
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Only supported by GFX9+.
The conservativeraster Sascha demo seems to work as expected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Since user defined names are not allowed in core profile
we remove the allow_user_names bool and just check if
we have a core profile like all other buffer/texture
object handling code does.
This extension is required by "Wolfenstein: The Old Blood"
and is exposed in core in the Nvidia binary driver.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This game is looking for some odd extension after creating a core
context such as ARB_vertex_program and EXT_framebuffer_object.
Rather then enabling these in core this forces the game to use
compat. This allows the game to run and seems to work without
issues. All other id tech games/engines use a compat profile.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The HW for FLUSH_ALL_STATE isn't validated, since the closed driver only
uses FLUSH. Now that we don't have any new state at the end of our bin
CLs, follow their lead.
Ever since we added OQ support, we've been clearing OQ state at the start
of the job anyway. We're intentionally breaking old-and-new-driver-mix
systems, because we need to stop using the unvalidated FLUSH_ALL_STATE.
The HW's FLUSH_ALL_STATE is not validated, so we probably shouldn't use
it, meaning that we need to reset state at the start. By doing this, we
also make ourselves more resilient to another client leaving the TF state
enabled at the end of their batch (as we now do, ourselves).
However, we still need to emit a single TF disable at the end of the
frame, for SWVC5-718.
Currently gallium's xlib target will fail to link due to multiple
definitions of all the symbols in libmesautil, this only shows up in
autotools, and not in meson due to differences in the way that meson and
autotools handle linking static archives into static archives. Autotools
uses -Wl,--whole-archive implicitly, meson requires this behavior to be
opted-into. The solution is just to remove libmesautils from the
libgl-xlib target, since it will get all of those symbols form
libmesagallium.
I've dropped the link from meson as well, it doesn't seem to hurt
anything and should make linking just a little faster.
Fixes: 8396043f30
("Replace uses of _mesa_bitcount with util_bitcount")
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107923
Tested-by: Brian Paul <brianp@vmware.com>
Tested-by: Vinson Lee <vlee@freedesktop.org>
Cc: Sergii Romantsov<sergii.romantsov@globallogic.com>
Rather than trying to encode all of the rules in a header, lets just put
them in the build system where they belong. This fixes the build on
FreeBSD, which does have pthraed_setaffinity_np, but it's in a
pthread_np.h, not behind _GNU_SOURCE. FreeBSD also implements cpu_set
slightly differently, so additional changes would be required to get it
working right there anyway.
v2: - fix #define in autotools
Fixes: 9f1bbbdbbd
("util: try to fix the Android and MacOS build")
Cc: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Missing break; causes parameter checking to
never pass GL_FRAMEBUFFER_FLIP_Y_MESA parameters.
Fixes: 318c265160 ("mesa: GL_MESA_framebuffer_flip_y extension [v4]")
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Instances where direction was determined based on
winsys or user fbo and should be determined based on
FlipY.
Key STATE_FB_WPOS_Y_TRANSFORM for of FlipY instead of
_mesa_is_user_fbo. This corrects gl_FragCoord usage
when applying GL_MESA_framebuffer_flip_y.
Fixes: ab05dd183c ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
Reviewed-by: Brian Paul <brianp@vmware.com>
To get an useful UUID for systems that have a non-useful mtime
for the binaries.
I started using SHA1 to ensure we get reasonable mixing in the
various possibilities and the various build id lengths.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Not sure if this is all wired up. CTS does pass and the Tangrams
demo works fine on Vega. There are corruption issues on Polaris
but not sure if that related to 16-bit support.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
