Re: GBM as standalone buffer allocator

On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) wrote: > > Hi, > > > > We are planning to enhance GBM as a standalone buffer allocator, which can be > used for all multi-media clients. Ex: video, camera, display etc; > > > > GBM create device expects a file descriptor to be passed, whic

Re: Question: error when running [Virtio-GPU Venus->vtest]

On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor wrote: > > Dear Developers: > > I am referring to this document > https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan related > functions, but every time I run vulkaninfo or vkcube some errors occur. > > virgl_test_server prints the fol

Re: [ANNOUNCE] mesa 22.3.0-rc1

On Wed, Nov 2, 2022 at 11:00 PM Tapani Pälli wrote: > > > > On 2.11.2022 23.25, Eric Engestrom wrote: > > Hello everyone, > > > > I'm happy to announce the start of a new release cycle with the first > > release candidate, 22.3.0-rc1. > > > > New features (in no particular order): > > - GL_ARB_sha

Re: Moving amber into separate repo?

On Fri, Sep 23, 2022 at 3:33 AM Filip Gawin wrote: > > Hi, recently I've seen case of user been using Amber when hardware was > supported by mainline mesa. This gave me a couple of thoughts. > > 1) Users don't correlate "Amber" with "Legacy" and probably it's gonna be > best to always also print

Re: revenge of CALLOC_STRUCT

On Wed, Dec 22, 2021 at 2:36 PM Dave Airlie wrote: > > 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 > g

Re: [Mesa-dev] Merge blocked

Please don't merge or push directly, that will interfere with marge-bot when it's trying to merge someone else's MR BR, -R On Tue, Sep 21, 2021 at 7:56 AM Jose Fonseca wrote: > > Hi Gert, > > > I can understand your frustration with the flaky tests, > > My frustration comes as much from the Gitl

Re: [Mesa-dev] outstanding patches for 21.2

On Wed, Sep 15, 2021 at 10:08 AM Dylan Baker wrote: > > Hi everyone, there's a few patch now outstanding for the 21.2 branch, > and I'd like to get some help from the relavent develoeprs on either > backporting them, or droping them. I've commented them as relavent > > 2021-08-10 FIXES a79ac1bee1

Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules

On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > but because it doesn't use the drm/scheduler it handles fences from > the wrong context with a synchronous dma_fence_wait. See > submit_fence_sync() leading to ms

Re: [Mesa-dev] Viability of Mesa 21.0.2 with Windows 10 ARM - Snapdragon/Adreno

+Jesse since he knows something about windows So, there are few different questions here: 1) 8cx/a680 .. the userspace difference compared to a6xx devices that are already supported is pretty small.. but I still need to find some time to do (linux) kernel side bringup 2) mesa on windows .. ie. e

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

or OpenSWR to support its existing users. >> >> Jan >> >> On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: >> > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark <mailto:robdcl...@gmail.com> >> > wrote: >> > > >> > > On Mon, Mar

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

On Thu, Mar 25, 2021 at 2:12 PM Kenneth Graunke wrote: > > On Thursday, March 25, 2021 10:15:51 AM PDT Rob Clark wrote: > > Other than the minor detail that we don't have pci-id's to > > differentiate between adreno generations, I might suggest a2xx users > &

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

t; from Meson. > Maybe it makes sense to keep gallium for r300? But how many r300 breakages > have we had in recent memory? > > On Wed, Mar 24, 2021, at 09:15, Jason Ekstrand wrote: > > On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote: > > > > > > On Mon, Mar 2

Re: [Mesa-dev] Rename "master" branch to "main"?

On Wed, Mar 24, 2021 at 9:15 PM Jason Ekstrand wrote: > > On March 24, 2021 22:25:10 Rob Clark wrote: > >> On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen >> wrote: >>> >>> >>> On 2021-03-23 09:38:59, Eric Anholt wrote: >>>> >

Re: [Mesa-dev] Rename "master" branch to "main"?

On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen wrote: > > On 2021-03-23 09:38:59, Eric Anholt wrote: > > On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote: > > > > > > Trying to pick this discussion back up. Daniel Stone thinks it's a > > > half hour of API bashing to retarget all the MRs so,

Re: [Mesa-dev] [RFC] Concrete proposal to split classic

On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote: > > Hi list, > > We've talked about it a number of times, but I think it's time time to > discuss splitting the classic drivers off of the main development branch > again, although this time I have a concrete plan for how this would > work. > > Fi

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Thu, Feb 18, 2021 at 8:00 AM Rob Clark wrote: > > On Thu, Feb 18, 2021 at 5:35 AM Tamminen, Eero T > wrote: > > > > Hi, > > > > On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote: > > [discussion about Perfetto itself] > > ... > > &

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Thu, Feb 18, 2021 at 7:40 AM Primiano Tucci wrote: > > > > On 18/02/2021 14:35, Tamminen, Eero T wrote: > > Hi, > > > > On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote: > > [discussion about Perfetto itself] > > ... > >> eero.t.tamminen@ > >> from in common Linux distro repos. > >> >

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Thu, Feb 18, 2021 at 5:35 AM Tamminen, Eero T wrote: > > Hi, > > On Thu, 2021-02-18 at 12:17 +0100, Primiano Tucci wrote: > [discussion about Perfetto itself] > ... > > eero.t.tamminen@ > > from in common Linux distro repos. > > > > That's right. I am aware of the problem. The plan is to addres

Re: [Mesa-dev] Perfetto CPU/GPU tracing

wrote: > > So, we're vendoring something that we know getting bug fixes for will be an > enormous pile of work? That sounds like a really bad idea. > > On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote: > > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker wrote: > > >

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Mon, Feb 15, 2021 at 3:13 AM Tamminen, Eero T wrote: > > Hi, > > On Fri, 2021-02-12 at 18:20 -0800, Rob Clark wrote: > > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin > > wrote: > ... > > > In our implementation that precision (in particular when a draw

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Sat, Feb 13, 2021 at 12:52 PM Lionel Landwerlin wrote: > > On 13/02/2021 18:52, Rob Clark wrote: > > On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin > > wrote: > >> On 13/02/2021 04:20, Rob Clark wrote: > >>> On Fri, Feb 12, 2021 at 5:56 PM Lionel L

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Sat, Feb 13, 2021 at 12:04 AM Lionel Landwerlin wrote: > > On 13/02/2021 04:20, Rob Clark wrote: > > On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin > > wrote: > >> On 13/02/2021 03:38, Rob Clark wrote: > >>> On Fri, Feb 12, 2021 at 5:08 PM Lionel Lan

Re: [Mesa-dev] Perfetto CPU/GPU tracing

an Baker wrote: > > I can't speak for anyone else, but a giant pile of vendored code that you're > expected to not update seems like a really bad idea to me. > > On Fri, Feb 12, 2021, at 18:09, Rob Clark wrote: > > I'm not really sure that is a fair statement.. the

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 5:56 PM Lionel Landwerlin wrote: > > On 13/02/2021 03:38, Rob Clark wrote: > > On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin > > wrote: > >> We're kind of in the same boat for Intel. > >> > >> Access to GPU perf cou

Re: [Mesa-dev] Perfetto CPU/GPU tracing

a really bad idea. > > On Fri, Feb 12, 2021, at 17:51, Rob Clark wrote: > > On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker wrote: > > > > > > > > > > > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote: > > > > On Thu, Feb 11,

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 5:40 PM John Bates wrote: > > > > On Fri, Feb 12, 2021 at 4:34 PM Rob Clark wrote: >> >> On Thu, Feb 11, 2021 at 5:40 PM John Bates wrote: >> > >> >> >> >> > Runtime Characteristics >> > >>

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 5:35 PM Dylan Baker wrote: > > > > On Fri, Feb 12, 2021, at 16:36, Rob Clark wrote: > > On Thu, Feb 11, 2021 at 5:40 PM John Bates wrote: > > > > > > > > > > > > Runtime Characteristics > > > > > > ~

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 5:08 PM Lionel Landwerlin wrote: > > We're kind of in the same boat for Intel. > > Access to GPU perf counters is exclusive to a single process if you want > to build a timeline of the work (because preemption etc...). ugg, does that mean extensions like AMD_performance_mo

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 4:51 PM Mark Janes wrote: > > Rob Clark writes: > > > On Fri, Feb 12, 2021 at 5:01 AM Tamminen, Eero T > > wrote: > >> > >> Hi, > >> > >> On Thu, 2021-02-11 at 17:39 -0800, John Bates wrote: > >> > I r

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Thu, Feb 11, 2021 at 5:40 PM John Bates wrote: > > Runtime Characteristics > > ~500KB additional binary size. Even with using only the basic features of > perfetto, it will increase the binary size of mesa by about 500KB. IMHO, that size is negligible.. looking at freedreno, a mesa build *

Re: [Mesa-dev] Perfetto CPU/GPU tracing

On Fri, Feb 12, 2021 at 5:01 AM Tamminen, Eero T wrote: > > Hi, > > On Thu, 2021-02-11 at 17:39 -0800, John Bates wrote: > > I recently opened issue 4262 > > to begin the > > discussion on integrating perfetto into mesa. > > > > *Background*

Re: [Mesa-dev] Perfetto CPU/GPU tracing

yes, but that is a limitation of mali which does not apply to a lot of other drivers ;-) But AFAIU typically you'd use perfetto with a sort of system server collecting trace data from various different processes, so the fact that that mali trace perf counters come from somewhere else doesn't reall

Re: [Mesa-dev] Rust drivers in Mesa

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 is tricky to integrate with other > build systems. Actually, Meson has native support for Rust, invoking the > compiler directly a

Re: [Mesa-dev] mediump support: future work

ns is a thing I'm still working on. But ignoring that fp16 is a win for us because of register pressure.. ie. a full-reg conflicts with two half-regs. For sure, a lot of the gain involves avoiding excessive conversions, but in a lot of common cases we can fold conversion into alu instruction

Re: [Mesa-dev] mediump support: future work

On Mon, May 4, 2020 at 11:44 AM Marek Olšák wrote: > > Hi, > > This is the status of mediump support in Mesa. What I listed is what AMD GPUs > can do. "Yes" means what Mesa supports. > > Feature FP16 support Int16 support > ALU Yes No > Uniforms No No > VS in No No > VS out / FS in No No > FS out

Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services

On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > >

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne > > wrote: > > > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > >

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI onl

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > pre-merge CI. > > Thanks for the suggestion! I implemented something like this for Mesa: > > https://gitlab.freedesk

Re: [Mesa-dev] [PATCH kmscube] meson.build: Do not set c_std

On Mon, Mar 30, 2020 at 5:28 PM Fabio Estevam wrote: > > Hi Rob, > > On Mon, Mar 30, 2020 at 6:29 PM Fabio Estevam wrote: > > > > When building kmscube in Buildroot for ARM the following > > errors are seen: > > > > ../common.c: In function 'get_time_ns': > > ../common.c:376:18: error: storage si

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > We could also do stuff like reducing the amount of tests we run on each > > commit, and punt some testing to a per-weekend test-run or someting > > like that. We don't *need* to know ab

Re: [Mesa-dev] Drop scons for 20.1?

On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca wrote: > > > but it bothers me how we keep not making a decision on this. If we'd said, > > "let's keep it and support it", that would something. > > I'm surprised there's any doubt. > > SCons works great for us. Meson gives no immediate benefit for

Re: [Mesa-dev] Drop scons for 20.1?

On Wed, Feb 26, 2020 at 2:07 AM Michel Dänzer wrote: > > On 2020-02-26 4:56 a.m., Rob Clark wrote: > > It looks like we have 4 scons build jobs in CI.. I'm not sure how much > > that costs us, but I guess those cycles could be put to better use? > > So even ignoring t

Re: [Mesa-dev] Drop scons for 20.1?

It looks like we have 4 scons build jobs in CI.. I'm not sure how much that costs us, but I guess those cycles could be put to better use? So even ignoring the developer-cycles issue (ie. someone making changes that effects scons build, and has to setup a scons build env to fix breakage of their MR

Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

On Tue, Feb 4, 2020 at 9:42 PM Eric Anholt wrote: > > On Tue, Feb 4, 2020 at 7:54 PM Rob Clark wrote: > > > > it seems like BE vs formats (vs llvm) is a constant nightmare, because > > there are essentially no mesa dev's working on BE devices (ie. issues > >

Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)

it seems like BE vs formats (vs llvm) is a constant nightmare, because there are essentially no mesa dev's working on BE devices (ie. issues are generally discovered long after the fact when mesa changes finally propagate into into enterprise distros).. but with gitlab we have now a sane scheme to

Re: [Mesa-dev] Is it time to stop using the mailing list for patch review?

On Wed, Dec 11, 2019 at 9:58 AM Brian Paul wrote: > > On 12/11/2019 10:42 AM, Jason Ekstrand wrote: > > On Wed, Dec 11, 2019 at 11:33 AM Michel Dänzer > > wrote: > > > > On 2019-12-11 5:47 p.m., Brian Paul wrote: > > > > > > I've had little time for Mesa w

Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches

On Mon, Dec 9, 2019 at 2:27 AM Michel Dänzer wrote: > > On 2019-12-07 12:56 a.m., Rob Clark wrote: > > > It would be nice if there was some way to setup some conservative > > filters to exclude groups of tests, ie. if only paths changed were > > under src/freed

Re: [Mesa-dev] Running the CI pipeline on personal Mesa branches

On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen wrote: > > On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer wrote: > > > > > > I just merged > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2794 , which > > affects people who want to run the CI pipeline on personal Mesa branches: > > > >

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

On Wed, Dec 4, 2019 at 11:58 PM Kenneth Graunke wrote: > > On Tuesday, December 3, 2019 4:39:15 PM PST 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 ma

Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

On Wed, Dec 4, 2019 at 9:48 AM Eric Anholt wrote: > > On Tue, Dec 3, 2019 at 4:39 PM 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. > > C

Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically

hmm, initially the UCP lowering did work post var lowering (since it had work after tgsi_to_nir).. the same might not be true of the drawpix/wpos_ytransform/etc lowering that is used internally in mesa/st for variants. I assume something like this is the issue? BR, -R On Fri, Oct 18, 2019 at 3:2

Re: [Mesa-dev] libdrm versioning - switch to 19.0.0?

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? >> >> Current: 2.4.n >> n = starts from 0, incremented per release >> >> New

Re: [Mesa-dev] Copying common u_format from gallium/auxiliary to broadcom/util

The plan is to extract some of this from gallium to share formats and related utils.. I need this too in order to share layout helper between gallium (freedreno) and vulkan (turnip) drivers BR, -R On Thu, Oct 3, 2019 at 11:30 PM wrote: > > > Currently broadcom/compiler does not link on its own.

Re: [Mesa-dev] Propose: Add transform buffer in egl/drivers/dir2/platform_android.c

On Wed, Sep 11, 2019 at 9:14 PM Cici Ruan wrote: > > Hi Mesa developers, > > I would like to add a feature in egl/drivers/dir2/platform_android.c to > respect he transform hint and rotation in Android buffer and transform buffer > to pre-rotated buffer, so display hardware can do a simple linear

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

On Fri, Sep 6, 2019 at 3:09 PM Eric Anholt wrote: > > Rob Clark writes: > > > On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt wrote: > >> > >> If you haven't seen this MR: > >> > >> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632

Re: [Mesa-dev] Enabling freedreno CI in Mesa MRs

On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt wrote: > > If you haven't seen this MR: > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632 > > I feel ready to enable CI of freedreno on Mesa MRs. There are some docs > here: > > https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b4024065

Re: [Mesa-dev] Moving libglvnd to FreeDesktop Gitlab

On Sat, Aug 31, 2019 at 12:34 PM Matt Turner wrote: > > Getting patches into libglvnd has proven quite difficult (see [0] for > example). There was some talk of moving it to FreeDesktop Gitlab on > IRC recently. Can we move forward with that? Are there objections to > doing so? > > [0] https://git

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke wrote: > > Hi all, > > As a lot of you have probably noticed, Bugzilla seems to be getting a > lot of spam these days - several of us have been disabling a bunch of > accounts per day, sweeping new reports under the rug, hiding comments, > etc. Thi

Re: [Mesa-dev] [PATCH] util/slab: add slab_free_fast()

umbers for this? > > On August 7, 2019 17:02:22 Rob Clark wrote: > > > From: Rob Clark > > > > I noticed slab_free() showing up at the top of perf results in > > gl_driver2, due to "streaming" GPU state objects, which are allocated > > and destroyed

Re: [Mesa-dev] [PATCH] util/slab: add slab_free_fast()

Jason Ekstrand wrote: > > It'd be nice to throw some numbers in the donut message before you push. > "Real" ones of it's convenient but what you have below is probably fine if > you've already thrown the data away. > > On August 7, 2019 19:13:21 Rob Clar

[Mesa-dev] [PATCH] util/slab: add slab_free_fast()

From: Rob Clark I noticed slab_free() showing up at the top of perf results in gl_driver2, due to "streaming" GPU state objects, which are allocated and destroyed within a single draw call. In this case, it is guaranteed that we free on the same child pool, from the same (only) thread

Re: [Mesa-dev] R: [PATCH 1/2] meson: require libdrm for gallium svga or virgl

Hmm, I don't *think* the freedreno gallium driver itself should depend on libdrm. I guess I haven't tried to build without. What is the error? BR, -R On Thu, Jul 18, 2019 at 9:43 AM Francesco Ansanelli wrote: > > Dear Alyssa, > > Sorry the bothering.. > > Your patch also added the check for fr

Re: [Mesa-dev] [AppVeyor] mesa master #11902 failed

On Thu, Jul 18, 2019 at 4:34 PM Roland Scheidegger wrote: > > Am 16.07.19 um 20:55 schrieb AppVeyor: > > > > Build mesa 11902 failed > > Commit 856e84083e by Rob Clark <mailto:robdcl...@chromium.org> on > > 7/15/2019 4:05 PM: > > mesa/st: add sampler u

Re: [Mesa-dev] [PATCH 2/2] mesa: Add ir3/ir3_nir_imul.c generation to Android.mk

simply adds it to the Android build, after which > thigns build and boot ok on db410c. > > Cc: Rob Clark > Cc: Emil Velikov > Cc: Amit Pundir > Cc: Sumit Semwal > Cc: Alistair Strachan > Cc: Greg Hartman > Cc: Tapani Pälli > Signed-off-by: John Stultz Revie

Re: [Mesa-dev] What does WIP really mean in an MR?

I had interpreted it as literally the "block the gitlab merge button" option, ie. "I want to get feedback but it is not ready to merge and I'll drop the WIP tag when I think it is".. (comments inline) On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick wrote: > > After a conversation yesterday with a c

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

On Mon, Jun 24, 2019 at 11:48 AM Eric Anholt wrote: > > Rob Clark writes: > > > On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt wrote: > > > > (tbh I've not really played w/ renderdoc yet.. I should probably do so..) > > > >> - Mozilla folks tell m

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt wrote: > > Hey folks, I wanted to show you this follow-on to shader-db I've been > working on: > > https://gitlab.freedesktop.org/anholt/renderdoc-traces > > For x86 development I've got a collection of ad-hoc scripts to capture > FPS numbers from vario

Re: [Mesa-dev] Proposal for the future of www.mesa3d.org

On Fri, Jun 21, 2019 at 7:01 AM Erik Faye-Lund wrote: > > A while back, Laura and Jean was working on a Sphinx-conversion of the > mesa-documentation. Sadly this work stranded due to it also trying to > move to using GitLab Pages for hosting www.mesa3d.org, and because the > documentation and the

[Mesa-dev] [PATCH] gallium: add z24s8_as_r8g8b8a8 format

From: Rob Clark This maps to a special format that recent generations of adreno have, for blitting z24s8. Conceptually it is similar to doing Z and/or S blits by pretending it is r8g8b8a8 (with appropriate writemask). But it differs when bandwidth compression is used, as z24 is a different

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

On Mon, Jun 10, 2019 at 6:52 PM Brian Masney wrote: > > Hi Rob, > > On Mon, Jun 10, 2019 at 05:10:45PM -0700, Rob Clark wrote: > > On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote: > > > > > > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote: >

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

On Mon, Jun 10, 2019 at 3:54 PM Brian Masney wrote: > > On Mon, Jun 10, 2019 at 06:58:30AM -0700, Rob Clark wrote: > > On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote: > > > > > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote: > > > > > > &

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

On Sun, Jun 9, 2019 at 7:43 AM Jonathan Marek wrote: > > On 6/9/19 8:41 AM, Brian Masney wrote: > > On Sat, Jun 08, 2019 at 10:58:11PM -0400, Jonathan Marek wrote: > >> Hi, > >> > >> It's possible 19.1 has another issue, I only tested the master branch with > >> my fix. I would suggest trying 19.0

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

On Mon, Jun 10, 2019 at 6:53 AM Rob Clark wrote: > > On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote: > > > > Hi, > > > > I'm trying to get the GPU working using the Freedreno driver (A330) on > > the Nexus 5 phone. I'm using kernel 5.2rc3 with s

Re: [Mesa-dev] freedreno: 'Unhandled NIR tex src type: 11' on A3XX

On Sat, Jun 8, 2019 at 6:08 PM Brian Masney wrote: > > Hi, > > I'm trying to get the GPU working using the Freedreno driver (A330) on > the Nexus 5 phone. I'm using kernel 5.2rc3 with some out of tree patches > related to the GPU [1] and mesa 19.1.0-rc5 on postmarketOS. When I run > glxgears, I se

Re: [Mesa-dev] [PATCH] freedreno: Fix GCC build error.

On Tue, Jun 4, 2019 at 12:59 AM Juan A. Suarez Romero wrote: > > On Thu, 2019-05-30 at 21:48 +, Vinson Lee wrote: > > ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is > > not constant > > .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 }, > > ^ > > > > Sh

Re: [Mesa-dev] [PATCH] freedreno: Fix GCC build error.

s://bugs.freedesktop.org/show_bug.cgi?id=110698 > Signed-off-by: Vinson Lee Reviewed-by: Rob Clark > --- > src/freedreno/vulkan/tu_device.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/freedreno/vulkan/tu_device.c > b/src/freedreno/vulkan/tu_devic

Re: [Mesa-dev] [PATCH] list: add some iterator debug

On Mon, May 27, 2019 at 5:06 AM Rob Clark wrote: > > On Mon, May 27, 2019 at 4:39 AM Erik Faye-Lund > wrote: > > > > On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote: > > > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote: > > > > On M

Re: [Mesa-dev] [PATCH] list: add some iterator debug

On Mon, May 27, 2019 at 4:39 AM Erik Faye-Lund wrote: > > On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote: > > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote: > > > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund > > > wrote: > > > > On Sat,

Re: [Mesa-dev] [PATCH] list: add some iterator debug

On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund wrote: > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote: > > This ends up embedded in a for loop expression, ie. the C part in an > > for (A;B;C) > > > > iirc, that means it needs to be a C expr rather than statem

Re: [Mesa-dev] [PATCH] list: add some iterator debug

not just do it in a way that works for everyone? Both the do/while > method and the ifdef-based method that I suggested work everywhere. Or > is there another reason you prefer to use those statement expressions? > > On Sat, May 25, 2019 at 6:21 PM Rob Clark wrote: > > > >

Re: [Mesa-dev] [PATCH] list: add some iterator debug

s a GNU extension. It also works in clang but not MSVC which is > used to build NIR. > > On May 25, 2019 13:30:29 Rob Clark wrote: > > > On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin wrote: > >> > >> On Sat, May 25, 2019 at 2:03 PM Rob Clark wrote: > >&g

Re: [Mesa-dev] [PATCH] list: add some iterator debug

On Sat, May 25, 2019 at 11:13 AM Ilia Mirkin wrote: > > On Sat, May 25, 2019 at 2:03 PM Rob Clark wrote: > > > > From: Rob Clark > > > > Debugging use of unsafe iterators when you should have used the _safe > > version sucks. Add some DEBUG build support to

[Mesa-dev] [PATCH] list: add some iterator debug

From: Rob Clark Debugging use of unsafe iterators when you should have used the _safe version sucks. Add some DEBUG build support to catch and assert if someone does that. I didn't update the UPPERCASE verions of the iterators. They should probably be deprecated/removed. Signed-off-by

Re: [Mesa-dev] [PATCH] st/mesa: fix 2 crashes in st_tgsi_lower_yuv

ot; failed > > The second crash was due to insufficient allocated size for TGSI > instructions. I might have split this into two patches, but either way you can add my: Reviewed-by: Rob Clark > > Cc: 19.0 19.1 > --- > src/mesa/state_tracker/st_tgsi_lower_yuv.c | 48 ++

Re: [Mesa-dev] [RFC PATCH 03/17] eir: add live ranges pass

On Fri, May 10, 2019 at 12:28 PM Rob Clark wrote: > > On Fri, May 10, 2019 at 7:43 AM Connor Abbott wrote: > > > > On Fri, May 10, 2019 at 11:47 AM Connor Abbott wrote: > > > > > > > > > This way of representing liveness, and then using a colori

Re: [Mesa-dev] [RFC PATCH 03/17] eir: add live ranges pass

On Fri, May 10, 2019 at 7:43 AM Connor Abbott wrote: > > On Fri, May 10, 2019 at 11:47 AM Connor Abbott wrote: > > > > > > This way of representing liveness, and then using a coloring register > > allocator, is a common anti-pattern in Mesa, that was initially copied > > from i965 which dates bac

Re: [Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

On Sat, Apr 27, 2019 at 9:52 AM Axel Davy wrote: > > On 27/04/2019 18:13, Rob Clark wrote: > > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: > >> From: Marek Olšák > >> > >> It's done by: > >> - decrease the number of frames in flig

Re: [Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák wrote: > > From: Marek Olšák > > It's done by: > - decrease the number of frames in flight by 1 > - flush before throttling in SwapBuffers > (instead of wait-then-flush, do flush-then-wait) > > The improvement is apparent with Unigine Heaven. > > Prev

Re: [Mesa-dev] [PATCH 1/2] nir: Add inverted bitwise ops

rtable; > + bool bitwise_src_invertable; neat, this trick seems to work on a6xx (and I'd assume earlier gens that use ir3 although I'd have to dust off some older blobs to check.. blob is less kind when it comes to retaining support for older hw).. very-bikeshed-

Re: [Mesa-dev] [PATCH] get_reviewer.pl: improve portability

> > Using /usr/bin/env means that we can't give the -w argument to Perl, > so I added `use warnings' in the script. > > Cc: Rob Clark > --- > scripts/get_reviewer.pl | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/get_reviewer

Re: [Mesa-dev] [PATCH 1/2] panfrost: Track BO lifetime with jobs and reference counts

On Tue, Apr 16, 2019 at 8:07 AM Alyssa Rosenzweig wrote: > > > > diff --git a/src/gallium/drivers/panfrost/pan_job.c > > > b/src/gallium/drivers/panfrost/pan_job.c > > > index 66a8b0d4b07..6c68575158f 100644 > > > --- a/src/gallium/drivers/panfrost/pan_job.c > > > +++ b/src/gallium/drivers/panfros

Re: [Mesa-dev] [PATCH 1/2] panfrost: Track BO lifetime with jobs and reference counts

On Tue, Apr 16, 2019 at 12:31 AM Boris Brezillon wrote: > > On Tue, 16 Apr 2019 01:49:21 + > Alyssa Rosenzweig wrote: > > > @@ -1793,22 +1799,9 @@ panfrost_set_vertex_buffers( > > const struct pipe_vertex_buffer *buffers) > > { > > struct panfrost_context *ctx = pan_context

Re: [Mesa-dev] Proposal: MESA_debug_operations

On Sun, Apr 14, 2019 at 2:22 PM Ilia Mirkin wrote: > > Hi all, > > I've put together a GLSL extension proposal at: > > https://people.freedesktop.org/~imirkin/MESA_debug_operations.spec I could see some cases where something like this would be useful.. BR, -R > > The situation this is trying to

Re: [Mesa-dev] [PATCH 1/2] nir: Add nir_lower_viewport_transform

On Sun, Apr 14, 2019 at 11:27 AM Christian Gmeiner wrote: > > Am So., 14. Apr. 2019 um 17:45 Uhr schrieb Alyssa Rosenzweig > : > > > > On Mali hardware (supported by Panfrost and Lima), the fixed-function > > transformation from world-space to screen-space coordinates is done in > > the vertex sha

Re: [Mesa-dev] Move adriconf to mesa repositories

+daniels On Mon, Apr 1, 2019 at 1:55 PM Jean Hertel wrote: > > Hi Rob, > > As we have spoken already in the past, I have the intention to move adriconf > under the mesa project umbrella, as an official tool for configuring DRI > options. > I would like to ask your advice, as well as other mesa

[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v3)

in GL contexts. Signed-off-by: Rob Clark --- src/mesa/state_tracker/st_extensions.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index c953bfd9f7a..405fc21b3ad 100644 --- a/src

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v2)

On Thu, Mar 21, 2019 at 2:19 PM Ilia Mirkin wrote: > > On Thu, Mar 21, 2019 at 1:45 PM Rob Clark wrote: > > > > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a > > sufficiently high ESSL feature level, even if the GLSL feature level > > isn'

  1   2   3   4   5   6   7   8   9   10   >