| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.
If adaptive_sync is false then the _VARIABLE_REFRESH property
is deleted on loader init.
The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Applications that don't present at a predictable rate (ie. not games)
shouldn't have adapative sync enabled. This list covers some of the
common desktop compositors, web browsers and video players.
[ Michel Dänzer: Added entry for firefox-esr ]
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Cc: Timothy Arceri <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were leaking surfaces because the references taken in
etna_set_framebuffer_state weren't being released on context destroy.
Instead of just directly releasing those references in
etna_context_destroy, use the util_copy_framebuffer_state helper.
Take the chance to remove the duplicated buffer references in
compiled_framebuffer_state to avoid confusion.
The leak can be reproduced with a client that continuously creates and
destroys contexts.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reported-by: Sjoerd Simons <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
|
|
|
|
|
|
|
|
| |
Older versions of virglrenderer before 33da7361aec486290df0aec4ad8dfa8ff6adde2c
in vtest mode, misrender gears.
Fixes: 9d81cd8e7c (virgl: Pass resource size and transfer offsets)
Reviewed-By: Gert Wollny <[email protected]>
|
|
|
|
|
|
|
|
| |
I know it's not what anyone wants, but how about we start with a
message in the documentation that encourages people to try meson.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Engeström <[email protected]>
|
|
|
|
|
|
|
|
| |
Note that meson requires python 3, scons requires python 2, and
autotools works with either.
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Engeström <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Engeström <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Eric Engeström <[email protected]>
|
|
|
|
| |
Signed-off-by: Juan A. Suarez Romero <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Juan A. Suarez Romero <[email protected]>
(cherry picked from commit 24c31bc0e237148b1c44811b17c61fc71f09bd93)
|
|
|
|
|
| |
Signed-off-by: Juan A. Suarez Romero <[email protected]>
(cherry picked from commit 785e09e3b32980380eb2081eeb48c157306f99ba)
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
ATOMFADD is a little special -- make drivers have to specify it
explicitly.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
This is supported by at least NVIDIA hardware, and exposeable via GL
extensions.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Not sure if this ever worked, but the current logic for setting the
min/max index is definitely wrong for indexed draws. While we're at it,
bring in all the usual logic from the non-indirect drawing path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109086
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We need a 64-bit value, otherwise we only handle the low 32, and happen to
sign-extend to claim to write all varying slots if VARYING_SLOT_VAR2 was
used.
Fixes: 4d0b2c7aaac3 ("ttn: Update shader->info as we generate code.")
Reviewed-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've made the choice not to use fast clears on layer > 0 with
multilayer images. This is partly because we would need to store
multiple clear colors for each layer, making the existing memory
layout, already including aux surfaces, fast clear color, image state,
etc... even more complex.
Partial resolves are the operations transfering the clear colors into
the auxiliary buffers. This operation is currently implemented in
Blorp by loading the clear color from the image's BO, into a shader
that then samples from the auxiliary buffer and writes the color only
if it isn't there already.
The problem here is that because we store only one clear color for all
layers and it is used for partial resolves. If you trigger a partial
clear on a layer > 0, then you're likely to deal with a color that is
not what you actually want. In the particular issues below, we have
multiple layers, each cleared with a different color but the partial
resolve just writes the wrong color into the auxiliary buffers for
layers > 0.
Signed-off-by: Lionel Landwerlin <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108910
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911
Cc: [email protected]
|
|
|
|
|
|
|
|
| |
100 is too small for some games, which triggers recompilations
every frame. Increase to 1024.
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Just like nine_context_box_upload, nine_context_range_upload
should reference the src, which holds the ram source buffer.
Fixes: https://github.com/iXit/Mesa-3D/issues/327
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
| |
nine_context_box_upload uploads a ram buffer (from src)
to a pipe_resource (dst).
We already have a refcount on the pipe_resource,
what needs to be protected from release is the ram buffer,
thus a reference to src.
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
| |
The dtor is called on allocation failure,
thus we must check the volumes are allocated
before trying to release them.
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
| |
This enables to match the window size
on resize on all cases, as it only works
currently with presentation buffers.
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a structure to release the
present_handles only when they are fully released
by the server, thus making
"DestroyD3DWindowBuffer" actually release the buffer
right away when called.
Signed-off-by: Axel Davy <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
| |
Maybe not 100% perfect, but seems to be a pretty good approximation of
that.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
This logic can be re-written as the two cases for 3d (ie. before/after
the miplevel sizes start reducing) vs everything else. I think it is
easier to read this way.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
| |
We really only need this logic in one place.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This was a hold-over from the early TGSI days, and mostly not needed
with NIR. This avoids burning an entire 4 consecutive scalar regs
for vec3 outputs, for example. Which fixes a few places that we were
doing worse that we should on register usage.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following crash that happened after d6110d4d
The problem happens if we first compile a "vanilla" shader with nothing
lowered in NIR, which perform the final lowering passes on so->shader->
nir (including nir_lower_locals_to_regs()), and then later we have
compile a shader with some lowering. The second time through we would
have already done nir_lower_locals_to_regs().
Arguably this was already a bug, just one we hadn't noticed yet.
Fixes: d6110d4d547 intel/compiler: move nir_lower_bool_to_int32 before nir_lower_locals_to_regs
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
| |
Nobody uses this, so let's drop it. This makes the helper callable
from places without a gl_program.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
DrawPixels lowering, for example, adds new varyings that need to be
accounted for in inputs_read. The earlier info gathering at link time
cannot account for this.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
They're now identical, so we can just compile it once.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Now that we always copy color, we can just use the util function.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The glDrawPixels passthrough vertex shader copies position and texcoord
vertex attributes to varying outputs. It also optionally copies a third
gl_Color attribute, which sometimes is unnecessary. Until now, we've
compiled separate variants of the shader, one of which does this extra
copy, and the other of which doesn't. We have done this since 2007.
But, the vertex shader runs for a whopping four vertices, and so the
cost of a copying a single input to output is likely inconsequential.
In theory, we could bind one fewer vertex element - but we always bind
all three regardless. So, we don't even get that savings.
This patch unifies the two, so we always copy the optional color,
and save having to compile the variant. It also makes the VS input
interface match up with the vertex element state without any dead
(unused) input attributes.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
Dead since 2015 (commit 5142564734bd68f165b02e29e384ebbcf91cce38).
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Trivial.
Fixes: 9f0bfbed11f "radv: Work around non-renderable 128bpp compressed 3d textures on GFX9."
|
|
|
|
|
|
|
|
| |
So that gitlab will render the < and > correctly allowing the tag to be
copy-n-pasted without additional formatting.
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Samuel Pitoiset <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever llvm removes an intrinsic (we're using), we're hitting segfaults
due to llvm doing calls to address 0 in the jitted code instead.
However, Jose figured out we can actually detect this with
LLVMGetIntrinsicID(), so use this to abort, so we don't have to wonder
what got broken. (Of course, someone still needs to fix the code to
no longer use this intrinsic.)
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This intrinsic disppeared with llvm 6.0, using it ends up in segfaults
(due to llvm issuing call to NULL address in the jited shaders).
Add code doing the same thing as the autoupgrade code in llvm so it
can be matched and replaced back with a pavgb.
While here, also improve lp_test_format, so it tests both with and without
cache (as it was, it tested the cache versions only, whereas cache is
actually disabled in llvmpipe, and in any case even with it enabled
vertex and geometry shaders wouldn't use it). (Although at least for
the unorm8 uncached fetch, the code is still quite different to what
llvmpipe is using, since that would use unorm8x16 type, whereas
the test code is using unorm8x4 type, hence disabling some intrinsic
paths.)
Fixes: 6f4083143bb8 ("gallivm: use llvm jit code for decoding s3tc")
Reviewed-by: Jose Fonseca <[email protected]>
Tested-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a number of build combinations:
- Gallium Drivers {SWR, RadeonSI, Others)
Each one has different LLVM requirements. Building SWR alone is twice
as slow as all other drivers combined.
- Gallium ST Clover LLVM {5,6,7}
Because C++ API changes all the time. Analogous to above building
Clover takes as much time as building all other ST combined.
- Gallium ST Others
Nouveau is used, instead of i915g since meson has explicit target
tracking. Meaning that a configure error is thrown if we use i915g
with say va, vdpau or others.
Note: LLVM prior to 5.0 is intentionally dropped. If needed we can add
that later.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|