- 30 Apr, 2019 1 commit
-
-
Rafael Antognolli authored
Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org>
-
- 29 Apr, 2019 28 commits
-
-
Plamena Manolova authored
This patch re-enables fast color clears for GEN11. It also ensures that we use linear color formats for sRGB surfaces during fast clears. Signed-off-by:
Plamena Manolova <plamena.n.manolova@gmail.com> Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com>
-
Rafael Antognolli authored
Hardware docs say that Gen11 requires the use of two MI_ATOMICs of size QWORD when updating the clear color. The second MI_ATOMIC also needs CS Stall and Return Data Control set. v2: Remove include of srgb header (Lionel) Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Rafael Antognolli authored
Change some of the single bit fields to booleans, and add an enum with the definition of the ATOMIC_OPCODE. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Jordan Justen authored
With python's int(), if the optional second parameter is 0, then python will support the 0x prefix for hex numbers. Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Plamena Manolova authored
The ClearColorConversionEnable bit needs to be set for GEN11 when inderect clear colors are used. Signed-off-by:
Plamena Manolova <plamena.n.manolova@gmail.com> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Reviewed-by:
Nanley Chery <nanley.g.chery@intel.com>
-
Leftovers from when autotools was deleted. Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Dylan Baker <dylan@pnwbakers.com>
-
One special case, `src/util/xmlpool/.gitignore` is not entirely deleted, as `xmlpool.pot` still gets generated (eg. by `ninja xmlpool-pot`). Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Reviewed-by:
Dylan Baker <dylan@pnwbakers.com>
-
Kenneth Graunke authored
The hardware feature is new as of Gen9+. I accidentally enabled it on Gen8.
-
Kenneth Graunke authored
I was setting it based off a pipe_rasterizer_state field that appears to be entirely dead outside of the draw module respecting it. I should be setting it when the primitive type reaching the SF is neither points nor lines. This is, unfortunately, rather dirty, as we have to look at the rasterizer state, the geometry shader state, the tessellation evaluation shader state, and the primitive type...
-
Rhys Perry authored
https://reviews.llvm.org/rL356946 (present in LLVM 9 and later) changed the meaning of the "system" sync scope, making it no longer restricted to the memory operation's address space. So a single address space sync scope is needed for shared atomic operations (such as "system-one-as" or "workgroup-one-as") otherwise buffer_wbinvl1 and s_waitcnt instructions can be created at each shared atomic operation. This mostly reimplements LLVMBuildAtomicRMW and LLVMBuildAtomicCmpXchg to allow for more sync scopes and uses the new functions in ac->nir with the "workgroup-one-as" or "workgroup" sync scopes. F1 2017 (4K, Ultra High settings, TAA), avg FPS : 59 -> 59.67 (+1.14%) Strange Brigade (4K, ~highest settings), avg FPS : 51.5 -> 51.6 (+0.19%) RotTR/mountain (4K, VeryHigh settings, FXAA), avg FPS : 57.2 -> 57.2 (+0.0%) RotTR/tomb (4K, VeryHigh settings, FXAA), avg FPS : 42.5 -> 43.0 (+1.17%) RotTR/valley (4K, VeryHigh settings, FXAA), avg FPS : 40.7 -> 41.6 (+2.21%) Warhammer II/fallen, avg FPS : 31.63 -> 31.83 (+0.63%) Warhammer II/skaven, avg FPS : 37.77 -> 38.07 (+0.79%) Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
To quote Uli Schlachter, who understands this stuff more than I do: > The function __glXSendError() in mesa's src/glx/glx_error.c invents an X11 > protocol error out of thin air. For the sequence number it uses dpy->request. > This is the sequence number of the last request that was sent. _XError() will > then update dpy->last_request_read based on the sequence number of the error > that just "came in". > > If now another something comes in with a sequence number less than > dpy->last_request_read, since sequence numbers are monotonically increasing, > widen() will incorrectly add 1<<32 to the sequence number and things might go > downhill afterwards. `__glXSendErrorForXcb` was also patched, as that's the function that `glXCreateContextAttribsARB` actually uses. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99781 Cc: mesa-stable@lists.freedesktop.org Fixes: ad503c41 'apple: Initial import of libGL for OSX from AppleSGLX svn repository' Reviewed-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Ian Romanick <ian.d.romanick@intel.com> Signed-off-by:
Hal Gentz <zegentzy@protonmail.com>
-
Lionel Landwerlin authored
In commit 0d46e404 ("anv: limit URB reconfigurations when using blorp") we tried to limit the number of URB reconfiguration by checking if the last allocation is large enough to fit the blorp dispatch. We used the last bound pipeline to compare the allocation. The problem with this is that the pipeline is bound but its commands might not have been emitted into the command buffer yet. Let's just revert commit 0d46e404 since it didn't seem to yield any performance improvement. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 0d46e404 ("anv: limit URB reconfigurations when using blorp") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110535 Acked-by:
Jason Ekstrand <jason@jlekstrand.net>
-
Erik Faye-Lund authored
This code is essentially dead now. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Erik Faye-Lund authored
It's prefectly legal and well-defined to render using a non-existing or empty buffer object. The data coming out of the buffer object isn't well defined unless we have the robustness flag set on the context, but that's a different matter, and up to the shader hardware; it's the same as out-of-bounds reads. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Erik Faye-Lund authored
It's legal for a buffer-object to have a NULL-resource, but let's just skip over it, as there's nothing to do. This patch switches the order of the conditionals in swr_update_derived, so the logic becomes a bit more straight forward: if (is_user_buffer) ... else if (resource) ... else ... ...instead of this: if (!is_user_buffer) if (resource) ... else ... else ... Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by:
Alok Hota <alok.hota@intel.com>
-
Erik Faye-Lund authored
It's legal for a buffer-object to have a NULL-resource, but let's just skip over it, as there's nothing to do. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Acked-by:
Karol Herbst <kherbst@redhat.com>
-
Erik Faye-Lund authored
It's legal for a buffer-object to have a NULL-resource, but let's just skip over it, as there's nothing to do. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com>
-
Erik Faye-Lund authored
It's legal for a buffer-object to have a NULL-resource, but let's just skip over it, as there's nothing to do. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Erik Faye-Lund authored
st_setup_current never sets this flag, and it's already checked against right before. So let's remove this pointless check. Signed-off-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com>
-
Andres Gomez authored
From page 76 (page 80 of the PDF) of the GLSL 4.60 v.5 spec: " No aliasing in output buffers is allowed: It is a compile-time or link-time error to specify variables with overlapping transform feedback offsets." Currently, this is expected to fail, but it succeeds: " ... layout (xfb_offset = 0) out vec2 a; layout (xfb_offset = 0) out vec4 b; ... " Fixes the following piglit test: tests/spec/arb_enhanced_layouts/compiler/transform-feedback-layout-qualifiers/xfb_offset/invalid-overlap.vert Fixes the following test: KHR-GL44.enhanced_layouts.xfb_output_overlapping v2: - Use a data structure to track the used components instead of a nested loop (Ilia). v3: - Take the BITSET_WORD array out from the gl_transform_feedback_buffer struct and make it local to the validation process (Timothy). - Do not use a nested scope for the validation (Timothy). v4: - Add reference to the fixed piglit test in the commit log. - Add reference to the fixed VK-GL-CTS test in the commit log (Tapani). - Empty initialize the BITSET_WORD pointers array (Tapani). Cc: Timothy Arceri <tarceri@itsqueeze.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Andres Gomez <agomez@igalia.com> Reviewed-by:
Tapani Pälli <tapani.palli@intel.com>
-
Patrick Lerda authored
Issue detected by valgrind. Fixes: 92d7ca4b ("gallium: add lima driver") Signed-off-by:
Patrick Lerda <patrick9876@free.fr> Reviewed-by:
Qiang Yu <yuq825@gmail.com>
-
Before setting the physical device API version, we should check if the MESA_VK_VERSION_OVERRIDE environment variable is set and take it into account. Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com>
-
Kenneth Graunke authored
While we can clean this up later, it's trivial to not generate the stupid code in the first place, which saves some optimization work. Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Matt Turner <mattst88@gmail.com>
-
Kenneth Graunke authored
Helper and name suggested by Eric Anholt. Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Matt Turner <mattst88@gmail.com>
-
Kenneth Graunke authored
Similar to list_is_singular() in util/list.h. Reviewed-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Matt Turner <mattst88@gmail.com>
-
Tapani Pälli authored
VK_ANDROID_external_memory_android_hardware_buffer requires this extension. It is safe to enable it since currently aux usage is disabled for ahw buffers. Fixes following dEQP extension dependency test on Android: dEQP-VK.api.info.device#extensions Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Tapani Pälli <tapani.palli@intel.com> Acked-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
-
Treat gl_FragCoord variable as a system value and lower the w component with a nir pass. Add the necessary bits for correct codegen. Signed-off-by:
Andreas Baierl <ichgeh@imkreisrum.de> Reviewed-by:
Qiang Yu <yuq825@gmail.com>
-
On some hardware (e.g. Mali400) the shader needs to apply some transformations for correct gl_FragCoord handling. The lowering actions look like the following in pseudocode: gl_FragCoord.xyz = gl_FragCoord_orig.xyz gl_FragCoord.w = 1.0 / gl_FragCoord_orig.w Add this lowering as a nir pass in preparation for using it in the driver. Signed-off-by:
Andreas Baierl <ichgeh@imkreisrum.de> Reviewed-by:
Qiang Yu <yuq825@gmail.com> Reviewed-by:
Eric Anholt <eric@anholt.net>
-
- 28 Apr, 2019 9 commits
-
-
Mesamatrix.net expects uppercase. Acked-by:
Timothy Arceri <tarceri@itsqueeze.com>
-
Alyssa Rosenzweig authored
I have *no* idea what's happening here, but let's not regress an app that used to work in the mean time while we're figuring it out.. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
In a perfect world, we'd use fp16 varyings for mediump and fp32 for highp, allowing us to get a performance win without sacrificing conformance. Unfortunately, we're not there (yet), so it's better we assume always fp32 than always fp16 to avoid artefacts / breaking a lot of deqp. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
Unbreaks mpv. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
Two fixes here, one is that we tried to copyprop non-strictly-SSA values which was bound to fly in our face. The other was peeling back the imov workaround.. Turns out we still need that. More research is needed still, but let's not regress real apps. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
With an outmod, we would need to propagate that through, which is for future work. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
Alyssa Rosenzweig authored
Fixes: commit b53b4573 . Optimization gone wrong. In the future, we should try this again (it's a net win if implemented right), but at the moment this just regresses. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
-
- 27 Apr, 2019 2 commits
-
-
Samuel Pitoiset authored
Otherwise it returns "AMD RADV unknown". Cc: 19.0 <mesa-stable@lists.freedesktop.org> Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Kenneth Graunke authored
Some of the dEQP.functional.transform_feedback tests end up doing the following sequence of operations: 1. BeginTransformFeedback 2. PauseTransformFeedback 3. Draw 4. ResumeTransformFeedback At step 1, we'd pack 3DSTATE_SO_BUFFER commands saying to zero the SO_WRITE_OFFSET registers. At step 2, we disable streamout, so step 3 doesn't bother emitting those commands. Then, step 4 re-packs new 3DSTATE_SO_BUFFER commands with offset = 0xFFFFFFFF, saying to continue appending at the existing offset. This loads the value from the BO as the offsets - but we never actually zeroed it. So, just maintain a flag saying "we actually emitted the commands", and stomp offset back to zero until we emit some.
-