On Fri, 9 Feb 2024 at 14:38, Ashwin Bhat wrote:
>
> Hello,
>
> During Vulkanised 2024 I was super excited to hear and learn about Lavapipe
> https://vulkan.org/user/pages/09.events/vulkanised-2024/Vulkanised-2024-faith-ekstrand-collabora-Iago-toral-igalia.pdf
>
> Are there some basic tutorials
On Wed, 6 Sept 2023 at 18:20, summer xia wrote:
>
> I use this version: llvmpipe (LLVM 14.0.0, 256 bits Type: CPU API: 1.3.246)
> as a backed vulkan engine. When I trace the whole pipeline that draws a
> picture.I can trace all the C level codes as following hints:
>
> #0
On Fri, 5 May 2023 at 21:30, George Karpathios wrote:
>
> Hi list,
>
> I'm using Lavapipe for Vulkan software rendering support in a modeling
> application. I notice a large performance hit (with any Mesa version) in the
> following scenario: The user clicks & drags the mouse in order to create
On Thu, 27 Apr 2023 at 15:18, Josh Gargus wrote:
>
> Thanks for your advice! I hadn't looked at Venus, but that seems like a very
> promising place to start.
>
> The other approach feels more approachable now too; it feels like there are
> less "unknown unknowns", although there are plenty of
On Thu, 27 Apr 2023 at 05:27, Josh Gargus wrote:
>
> Hi, I'm from the Fuchsia team at Google. We would like to provide Lavapipe
> as an ICD within Fuchsia. However, our default security policy is to deny
> client apps the capability to map memory as writable/executable; we don't
> want to
On Tue, 12 Jul 2022 at 09:53, Mike Blumenkrantz
wrote:
>
> Hi,
>
> I did a GL 4.6 CTS run today on a very recent version of CTS, and I found a
> class of tests which target failure cases (specifically return codes) for
> various API. A number of these tests failed, which means they fail for all
On Mon, 24 Jan 2022 at 06:52, Abel Bernabeu
wrote:
>
> Dave,
>
> Am glad for the Mesa community to support the RISC-V effort with the advice
> given so far.
>
> I hear your concerns regarding performance. I am familiar with the Larabee
> case and know some of the people who worked on that.
On Sun, 23 Jan 2022 at 22:58, Abel Bernabeu
wrote:
>>
>> Yes, NIR arrays and struct and nir_deref to deal with them but, by the time
>> you get into the back-end, all the nir_derefs are gone and you're left with
>> load/store messages with actual addresses (either a 64-bit memory address or
>>
On Sun, 26 Dec 2021 at 20:37, Jose Fonseca wrote:
>
> I believe that as long as the CALLOC_STRUCT continue to get paired with right
> FREE call (or equivalent if these get renamed) either way should work for us.
> Whatever option proposed gets followed, there's a risk these can get out of
>
Hey,
Happy holidays, and as though to consider over the break,
We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used
throughout gallium.
We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in gallium.
Merging the state tracker into mesa proper, and even prior
On Tue, 7 Dec 2021 at 09:51, Dylan Baker wrote:
>
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving src/mesa into
> src/gallium/frontends/mesa. This makes the build system a little
> cleaner, as currently we do some bending
On Thu, 18 Nov 2021 at 18:45, Sil Vilerino
wrote:
>
> Hello mesa-dev community,
>
>
>
> We are starting to work on adding support for D3D12 Video acceleration in the
> mesa gallium D3D12 driver so that mesa frontends such as VA, VDPAU, etc can
> leverage HW acceleration in those environments.
>
On Sun, 14 Nov 2021, 08:38 Autumn, wrote:
> Hello! I submitted my first merge request to the Mesa GitLab earlier
> this month:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13671
>
> It hasn't been noticed yet as far as I can tell. I don't need it
> reviewed quickly or anything,
On Fri, 5 Nov 2021 at 11:59, Jason Ekstrand wrote:
>
> On Thu, Nov 4, 2021 at 8:53 PM Dave Airlie wrote:
> >
> > Just polling for opinions here on how best to move forward with
> > enabling the provisional vulkan beta headers in Mesa and the fallout
> > from doing s
Just polling for opinions here on how best to move forward with
enabling the provisional vulkan beta headers in Mesa and the fallout
from doing so for people importing updated vulkan headers.
Do we want to allow beta/provisional features in main?
Do we want to do it only under a meson option
On Fri, 24 Sept 2021 at 16:35, an0oo0nym0oo0us OoO
wrote:
>
> Hello everyone,
>
> I'm new to Mesa3D, and have read its source code for a last few days. I
> cannot find where "struct gl_context" definition. Can you help me find it out?
src/mesa/main/mtypes.h
irc.oftc.net:#dri-devel is also
> The texture has been taken from the wikipedia page
> https://en.wikipedia.org/wiki/Anisotropic_filtering#/media/File:Anisotropic_filtering_en.png
>
> The following images show results for both settings:
>
> image with anisotropic filtering (16)
> https://pasteboard.co/JNyFRkr.png
>
> image
On Sat, 10 Jul 2021 at 11:12, Jan Beich wrote:
>
> Wladislav Artsimovich writes:
>
> > Finally, on Gen4/Gen5 iGPUs, crocus does not expose
> > GL_EXT_gpu_shader4, thus modern GLSL functions are missing targets and
> > no "GL_ARB_blend_func_extended", as is normally possible on with i915
> > and
..@jlekstrand.net/
>
> v3: Since Christian has fixed amdgpu now in
>
> commit 8c505bdc9c8b955223b054e34a0be9c3d841cd20 (drm-misc/drm-misc-next)
> Author: Christian König
> Date: Wed Jun 9 13:51:36 2021 +0200
>
> drm/amdgpu: rework dma_resv handling v3
>
> Use the audit covered in this commit message as the excuse to update
> the dma-buf docs around dma_buf.resv usage across drivers.
>
> Since dynamic importers have different rules also hammer these in
> again while we're at it.
>
> v4:
> - Add the missing "through the device" in the dynamic section that I
> overlooked.
> - Fix a kerneldoc markup mistake, the link didn't connect
>
This is pretty epic commit msg, thanks for the investment, the commit
msg should be required reading.
Reviewed-by: Dave Airlie
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
assumptions
> > (Daniel Stone)
> > - Add links to priority spec
> >
> > Cc: Christian König
> > Cc: Luben Tuikov
> > Cc: Alex Deucher
> > Cc: Steven Price
> > Cc: Jon Bloomfield
> > Cc: Jason Ekstrand
> > Cc: Dave Airlie
> &g
On Tue, 27 Apr 2021 at 22:06, Christian König
wrote:
>
> Correct, we wouldn't have synchronization between device with and without
> user queues any more.
>
> That could only be a problem for A+I Laptops.
Since I think you mentioned you'd only be enabling this on newer
chipsets, won't it be a
eing over engineering, I hope they have a
good future use case.
The plan seems like a good plan.
Acked-by: Dave Airlie
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, 6 Apr 2021 at 03:22, Chia-I Wu wrote:
>
> Hi list,
>
> We are looking to merge virtio-gpu vulkan driver
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800
>
> On the good side, the driver is conformant with Vulkan 1.2 (vtest) and
> Vulkan 1.1 (virtio-gpu). I only tried
On Mon, 15 Mar 2021 at 22:44, Erik Faye-Lund
wrote:
>
> TLDR; I'm proposing to standardize on US English in our public-facing
> documentation.
>
> I proposed an MR a while back that changed the only occurrence of the
> UK English spelling "optimisation" for the US English spelling
>
On Mon, 8 Feb 2021 at 19:04, Andreas Fänger wrote:
>
>
> Am 08.02.2021 05:14, schrieb Dave Airlie:
> > On Wed, 3 Feb 2021 at 02:58, Michel Dänzer wrote:
> >>
> >> On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
> >> > On 2021-02-02 6:44 a.m., Dave Airl
On Wed, 3 Feb 2021 at 02:58, Michel Dänzer wrote:
>
> On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
> > On 2021-02-02 6:44 a.m., Dave Airlie wrote:
> >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote:
> >>>
> >>> On Thu, 7 Jan 2021 at 21:11, Andre
On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote:
>
> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote:
> >
> > >> don’t know why the current softpipe/swrast implementation shouldn’t be
> > >> conformant.
> >
> > >Interesting I hadn't kn
On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote:
>
> >> don’t know why the current softpipe/swrast implementation shouldn’t be
> >> conformant.
>
> >Interesting I hadn't known we had a correct impl in mesa, the features.txt
> >has said "softpipe and llvmpipe advertise 16x anisotropy but
On Thu, 7 Jan 2021 at 18:49, Andreas Fänger wrote:
>
> Hi Dave,
>
>
>
> don’t know why the current softpipe/swrast implementation shouldn’t be
> conformant.
Interesting I hadn't known we had a correct impl in mesa, the
features.txt has said
"softpipe and llvmpipe advertise 16x anisotropy but
based on the gallium
> infrastructure already?
>
I hadn't really looked at mesa I had thought the aniso impl weren't
conformant, I'll look again next week when I get back to work.
Dave.
>
>
> Andreas
>
>
>
> *Von:* mesa-dev *Im Auftrag von *Dave
> Airlie
> *Gesendet:* Donn
I have some plans nothing firm to add some sort of aniso to llvmpipe. I was
considering porting code from swiftshader, maybe I can bump it up the
priority list.
Dave.
On Tue, 5 Jan 2021, 06:02 Brian Paul, wrote:
>
>
> Forwarded Message
> Subject:[Mesa-users] Issues
It's not supported and not useful in any way. TGSI llvmpipe is missing a
lot of features.
Dave
On Thu, 19 Nov 2020, 18:35 Tommy Chou, wrote:
> Hi,
>
> When running Vulkan code through lavapipe, SPIRV shaders are first
> converted to NIR. Is it possible to further translate or dump that NIR to
On Thu, 12 Nov 2020 at 06:37, Dave Airlie wrote:
>
> On Thu, 12 Nov 2020 at 06:23, Francisco Jerez wrote:
> >
> > I don't remember the specifics of why we ended up interfacing with Clang
> > this way. What is technically wrong with it, specifically? I don't
> > h
On Thu, 12 Nov 2020 at 06:23, Francisco Jerez wrote:
>
> I don't remember the specifics of why we ended up interfacing with Clang
> this way. What is technically wrong with it, specifically? I don't
> have any objection to switching to the Driver and Compilation interface,
> nor to translating
Hey all (mostly Tom).
I've been learning new things today since Matt pushed a patch to clang
to remove "-cl-denorms-are-zero" from cc1 options. I thought this was
a regression or we should hack things to pass a different flag (which
I did locally for testing), but Matt informed me clover is
Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
is now official[1].
Thanks to everyone who helped me drive this forward, and to all the
contributors both to llvmpipe and the general Mesa stack that enabled
On Fri, 2 Oct 2020 at 15:01, Jason Ekstrand wrote:
>
> On Thu, Oct 1, 2020 at 10:56 PM Rob Clark wrote:
> >
> > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> > wrote:
> > >
> > > Implications for the build system vary. Rust prefers to be built by its
> > > own package manager, Cargo, which
On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay wrote:
>
> On Sun, Aug 23, 2020, 17:08 Luke Kenneth Casson Leighton
> wrote:
>>
>>
>>
>> On Monday, August 24, 2020, Dave Airlie wrote:
>>>
>>>
>>> amdgpu is completely scalar,
>>
>
On Mon, 24 Aug 2020 at 09:10, Jacob Lifshay wrote:
>
> On Sun, Aug 23, 2020, 15:55 Dave Airlie wrote:
>>
>> What is your work submission model then, Vulkan is designed around
>> having work submitted to a secondary processor from a control
>> processor. Do you in
On Mon, 24 Aug 2020 at 07:25, Luke Kenneth Casson Leighton
wrote:
>
> On Sun, Aug 23, 2020 at 8:50 PM Dave Airlie wrote:
>
> > I don't want to get involved in half-thought out schemes here,
>
> [this has been in the planning stage for... almost 2 years now?]
>
> >
> (if i can fill in this bit)
>
> the context is: to augment the PowerISA Instruction set to add 3D
> opcodes *directly* to PowerISA, with the guidance, full knowledge and
> under the supervision of the OpenPOWER Foundation.
>
> this will include: adding sin, cos, atan2... *to PowerISA*. adding
meson-gallium builds all the gallium drivers but no vulkan drivers.
meson-vulkan builds all the vulkan driver but no gallium.
I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so
I suppose the former is more suitable, but just looking for
suggestions.
Dave.
FYI:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5677
Dave.
On Thu, 21 May 2020 at 05:14, Roland Scheidegger wrote:
>
> Oh I missed that sparc is big endian.
> Still not sure where the llvm IR would differ but indeed some different
> unpacking somewhere could explain things.
>
On Wed, 27 Jun 2018 at 06:36, Denis Pauk wrote:
>
> Reuse code shared with mesa/main/texcompress_bptc.
>
> v2: Use block decompress function
> v3: Include static bptc code from texcompress_bptc_tmp.h
> Suggested-by: Marek Olšák
>
> Signed-off-by: Denis Pauk
> CC: Nicolai Hähnle
> CC: Marek
On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote:
>
> On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote:
> >
> > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > >
> > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > > > b)
On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
>
> On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > b) we probably need to take a large step back here.
> >
> > Look at this from a sponsor POV, why would I give X.org/fd.o
> > sponsorship money that they are
On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially
Hey,
Anyone know why LP_MAX_VBUF_SIZE is only 4K?
Tess submits > 100K verts to the draw pipeline, which start to split
them, due to the 4K size of the above it splits 50 vertices per vbuf,
however it then calls draw_reset_vertex_ids which iterates over all
100K vertices each time.
I might try
On Fri, 14 Feb 2020 at 08:22, Marek Olšák wrote:
>
> I wonder what PGO really does other than placing likely/unlikely.
With LTO it can do a lot more, like grouping hot functions into closer
regions so they avoid TLB misses and faults etc.
Dave.
___
On Thu, 5 Dec 2019 at 13:42, Jonathan Gray wrote:
>
> Until very recently OpenBSD built xlockmore against Mesa. xlock is
> setgid auth. As described by Qualys in their advisory
> https://marc.info/?l=oss-security=157549260013521=2
> "CVE-2019-19520: Local privilege escalation via xlock"
> the
On Wed, 4 Dec 2019 at 10:39, Marek Olšák wrote:
>
> Hi,
>
> Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
>
> 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them,
On Wed, 27 Nov 2019 at 21:08, Gert Wollny wrote:
>
> Hello Dave,
>
> I was wondering how much interest you still have in R600? I'm preparing
> to start feeding my NIR work as MRs to continue my work in-tree. It is
> currently only for Evergreen and still far from feature parity
> with TGSI (no
On Tue, 26 Nov 2019 at 05:19, Marek Olšák wrote:
>
> The way shader variants work in st/mesa is that NIR is generated, finalized,
> and stored in the cache. This helps the most common case when there is only
> one variant. If shader variants make changes to NIR, like adding samplers,
>
I was asked to use some newer radeonsi code in my tgsi info gathering
wrapper for NIR. One of the things it does is use
nir->info.textures_used.
Now with the piglit test draw-pixel-with-texture there is a reentrancy
issue with the passes.
We create a shader and gl_nir_lower_samplers_as_deref get
>
> From: Roland Scheidegger
Thanks,
Reviewed-by: Dave Airlie
>
> LLVM 8 did remove both the signed and unsigned sse2/avx intrinsics in
> the end, and provide arch-independent llvm intrinsics instead.
> Fixes a crash when using snorm framebuffers (tested with piglit
> a
On Fri, 30 Aug 2019 at 00:55, Roland Scheidegger wrote:
>
> Am 29.08.19 um 15:05 schrieb Jose Fonseca:
> > This change is
> >
> > Reviewed-by: Jose Fonseca
> >
> > Regarding follow up change, do you think the LLVM pattern is sane/doable?
> Yes, should be doable and not too bad (I did not
On Fri, 11 Oct 2019 at 14:56, Rob Clark wrote:
>
> On Thu, Oct 10, 2019 at 7:46 PM Jason Ekstrand wrote:
> >
> > On October 10, 2019 15:15:29 Marek Olšák wrote:
> >>
> >> Hi,
> >>
> >> I expect to make a new libdrm release soon. Any objections to changing the
> >> versioning scheme?
> >>
> >>
On Fri, 6 Sep 2019 at 12:13, wrote:
>
> From: Roland Scheidegger
>
> Should fix some issues we're seeing. And use REALLOC instead of realloc.
Oops sorry
Reviewed-by: Dave Airlie
> ---
> src/gallium/drivers/llvmpipe/lp_cs_tpool.c | 6 +++---
> src/gallium/drivers/llvmp
From: Dave Airlie
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111511
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
On Tue, 27 Aug 2019 at 20:30, Jose Fonseca wrote:
>
> FYI, I've followed Eric Engestroms' instructions for better Mesa <-> AppVeyor
> integration. (Thanks Eric.)
>
> I haven't tested, but hopefully this new integration method should now
> trigger Appveyor builds on pull requests too, which
Reviewed-by: Dave Airlie
On Thu, 29 Aug 2019 at 05:37, wrote:
>
> From: Roland Scheidegger
>
> LLVM 7.0 ditched the pmulu intrinsics.
> This is only a trivial patch to use the fallback code instead.
> It'll likely produce atrocious code since the pattern doesn't match what
On Tue, 27 Aug 2019 at 09:03, Andreas Bergmeier wrote:
>
> > Be warned that the way the Intel streamout hardware works is really weird.
> > It's designed from the perspective of something walking a buffer and trying
> > to figure out which outputs to grab. This is completely backwards (or
>
From: Dave Airlie
Not sure how I missed this before, but compswap was hitting an
assert here as it is it's own special case.
Fixes: b5ac381d8f ("gallivm: add buffer operations to the tgsi->llvm
conversion.")
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 ++
1 fi
On Fri, 2 Aug 2019 at 13:08, Brian Paul wrote:
>
> On 08/01/2019 04:56 PM, Charmaine Lee wrote:
> > This patch fixes a missing argument to CreateAtomicCmpXchg for older
> > version of LLVM.
Does this pass CI? please try a pull request.
We've got a bug open
From: Dave Airlie
This doesn't seem to need it's own copy here.
---
src/compiler/nir/nir_lower_scratch.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/compiler/nir/nir_lower_scratch.c
b/src/compiler/nir/nir_lower_scratch.c
index df0d3f43124
On Wed, 24 Jul 2019 at 11:55, Xu, Xing wrote:
>
> Hi, I tried to add some logs as below in file
> ./src/vulkan/wsi/wsi_common_x11.c (x11_queue_present):
>
> printf("%s,%d\n",__FUNCTION__,__LINE__);
>
> assert(0);
>
> but got nothing(no logs and assert didn’t happen) when I run my application.
>
From: Dave Airlie
I can find no evidence that removing this is a good idea.
Fixes: 9b116173b6a ("radv: do not emit VGT_FLUSH on GFX10")
---
src/amd/vulkan/radv_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/
From: Dave Airlie
IF we don't have clear state (which gfx10 doesn't currently)
we will fix to reset the scissor. AMDVLK will leave it set
to something else.
Marek also has this fix for radeonsi pending.
---
src/amd/vulkan/si_cmd_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
From: Dave Airlie
Enabling tracing, and then having a vmfault, can leads to a segfault
before we print out the traces, as if a meta shader is executing
and we don't have the NIR for it.
Just pass the stage and give back a default.
Fixes: 9b9ccee4d64 ("radv: take LDS into account for co
Reviewed-by: Dave Airlie
On Wed, 17 Jul 2019 at 11:01, Bas Nieuwenhuizen
wrote:
>
> After reset, if valid does not contain the relevant bit the descriptor
> can be != NULL but still not be valid.
>
> CC:
> ---
> src/amd/vulkan/radv_meta.c | 2 +-
> 1 file changed, 1
From: Dave Airlie
this shouldn't matter, but it's good to be correct.
---
src/amd/vulkan/radv_pipeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 5cdfe6d24eb..c7660c2900c 100644
--- a/src/amd/vulkan
From: Dave Airlie
This is ported from AMDVLK, it's probably not requires unless
we want to use "real time queues", but it might be nice to just have
in place.
---
src/amd/common/sid.h | 1 +
src/amd/vulkan/radv_cs.h | 18 +++
src/amd/vulkan/si_cmd_buf
From: Dave Airlie
Setting this seems to be broken, amdvlk only sets it for quilted
textures which I'm not sure what those are.
Fixes: dEQP-VK.glsl.texture_functions.query.texturesize*3d*
---
src/amd/vulkan/radv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd
r-b.
On Thu, 11 Jul 2019 at 23:51, Samuel Pitoiset wrote:
>
> DCC related, mirror RadeonSI.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 20
> 1 file changed, 4 insertions(+), 16 deletions(-)
>
> diff --git
From: Dave Airlie
this isn't used outside this file.
---
src/gallium/drivers/llvmpipe/lp_state_fs.c | 2 +-
src/gallium/drivers/llvmpipe/lp_state_fs.h | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
b/src/gallium/drivers
From: Dave Airlie
Pointed out by coverity
---
src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index ad7f1eb3d99..75bd61730da 100644
From: Dave Airlie
This is pointless in that we won't ever hit those paths in real life,
but coverity complains.
Fixes: f014ae3c7cce ("nouveau: add support for nir")
---
src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 +
src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 ++
s
Oops on new ext in master,
Reviewed-by: Dave Airlie for the v2 series.
On Sat, 8 Jun 2019 at 01:47, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As elaborated in the next patch, there is some hidden ABI that
> effectively require most entrypoints to be listed in the fil
wholesale so both sides were generated from
the same code. What we have now is inherently fragile, even if what we
had before might have been considered ugly.
I'm begrudingly giving a for both of these, just to unblock 19.1.
Reviewed-by: Dave Airlie
Emil I think you should give serious consideration
On Mon, 3 Jun 2019 at 11:37, Jan Vesely wrote:
>
> On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote:
> > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > > > I've started a thread on the llvm
On Mon, 3 Jun 2019 at 10:42, Jan Vesely wrote:
>
> On Mon, 2019-06-03 at 09:14 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 09:13, Dave Airlie wrote:
> > > On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote:
> > > > On Sun, 2019-06-02 at 07:17 -0400, James Ha
On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote:
>
> On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > I've started a thread on the llvm mailing list. See
> > http://lists.llvm.org/pipermail/llvm-dev/2019-June/132750.html
> >
> > I don't know if it's needed, but if anyone has a commit in
On Mon, 3 Jun 2019 at 09:13, Dave Airlie wrote:
>
> On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote:
> >
> > On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> > > wrote:
> > > &
On Sun, 2 Jun 2019 at 23:13, Jan Vesely wrote:
>
> On Sun, 2019-06-02 at 07:17 -0400, James Harvey wrote:
> > On Sun, Jun 2, 2019 at 7:01 AM Bas Nieuwenhuizen
> > wrote:
> > > On Sun, Jun 2, 2019 at 12:41 PM James Harvey
> > > wrote:
> > > > So, for people running amdgpu and wanting to run
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Maybe be a little less trigger happy with the tags, can we get these
reverted in stable :-) and master as well maybe.
Dave.
On Tue, 21 May 2019 at 02:32, Charmaine Lee wrote:
>
>
> >From: Brian Paul
> >Sent: Monday, May 20, 2019 6:39 AM
>
From: Dave Airlie
When creating function parameters, we create pointers from ssa
values, this creates nir casts with stride 0, however we have
no where else to get this value from. Later passes to lower
explicit io need this stride value to do the right thing.
---
src/compiler/spirv
ping? nha? mareko maybe?
Dave.
On Fri, 17 May 2019 at 12:02, Dave Airlie wrote:
>
> mesa-19.1.0-rc2/src/amd/common/ac_llvm_build.c:4019: copy_paste_error:
> "result_exclusive" in "ws->result_exclusive" looks like a copy-paste
> error.
>
> + if (w
It'd help in debugging.
>
> On Thu, May 9, 2019 at 8:12 PM Dave Airlie wrote:
>>
>> I've got a bunch of cases where copy prop vars is getting things wrong
>> around casts, it finds a store to an vec2 but ends up with the
>> writemask staying at 0x3 but the item being stor
From: Dave Airlie
we validate assert entry just before this, but since that doesn't
stop execution, we need to check entry before the next validation
assert.
---
src/compiler/nir/nir_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_validate.c b
From: Dave Airlie
src/compiler/glsl_types.cpp:577: uninit_member: Non-static class member
"packed" is not initialized in this constructor nor in any functions that it
calls.
from Coverity.
Fixes: 659f333b3a4 (glsl: add packed for struct types)
---
src/compiler/glsl_type
From: Dave Airlie
glsl_to_nir.cpp:276: uninit_member: Non-static class member "sig" is not
initialized in this constructor nor in any functions that it calls.
Reported by coverity
---
src/compiler/glsl/glsl_to_nir.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/com
From: Dave Airlie
link_uniforms.cpp:477: uninit_member: Non-static class member
"shader_storage_blocks_write_access" is not initialized in this constructor nor
in any functions that it calls.
Reported by coverity.
---
src/compiler/glsl/link_uniforms.cpp | 3 ++-
1 file changed, 2
From: Dave Airlie
imgui_draw.cpp:1781: error[shiftTooManyBitsSigned]: Shifting signed 32-bit
value by 31 bits is undefined behaviour
Reported by coverity
---
src/imgui/imgui_draw.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/imgui/imgui_draw.cpp b/src/imgui
mesa-19.1.0-rc2/src/amd/common/ac_llvm_build.c:4019: copy_paste_error:
"result_exclusive" in "ws->result_exclusive" looks like a copy-paste
error.
+ if (ws->enable_inclusive)
+ ws->result_inclusive = ac_build_alu_op(ctx,
ws->result_exclusive, ws->src, ws->op);
+ if
Coverity gave me this:
mesa-19.1.0-rc2/src/compiler/spirv/spirv_to_nir.c:1987:
overlapping_assignment: Assigning "src[1][i].u8" to "src[1][i].u32",
which have overlapping memory locations and different types.
and the following lines, I think it's actually undefined behaviour wrt
the C spec.
On Fri, 17 May 2019 at 07:42, Neha Bhende wrote:
>
> We need to free memory allocation PrimitiveOffsets in draw_gs_destroy().
> This fixes memory leak found while running piglit on windows.
Reviewed-by: Dave Airlie
>
> Fixes: 7720ce32a ("draw: add support to tgsi paths
> From: Marek Olšák
It would be nice to have a reasoning why, I assume that is what they
are called internally and in the kernel, but it would be good to
mention something to justify it in the commit msg.
Acked-by: Dave Airlie
___
mesa-dev mail
Reviewed-by: Dave Airlie
On Wed, 15 May 2019 at 12:17, Marek Olšák wrote:
>
> From: Marek Olšák
>
> ---
> src/amd/common/amd_family.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/common/amd_family.h b/src/amd/com
I've got a bunch of cases where copy prop vars is getting things wrong
around casts, it finds a store to an vec2 but ends up with the
writemask staying at 0x3 but the item being store being a single
64-bit.
Debug is attached below.
Dave.
nir_lower_memcpy_deref
shader: MESA_SHADER_KERNEL
From: Dave Airlie
---
src/gallium/targets/dri/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/targets/dri/meson.build
b/src/gallium/targets/dri/meson.build
index dd40969a166..45daf647960 100644
--- a/src/gallium/targets/dri/meson.build
+++ b/src
1 - 100 of 3958 matches
Mail list logo
