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,

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

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): > > -

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

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 >

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

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

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

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.

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

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 22, 2021 at 3:15 PM Dyla

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 > > to use

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

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 22, 2021 at

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. > >

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

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

; > 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

: > > 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 work scales > > accordi

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 counters

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

> 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, 2021 at 5:40 PM John Bat

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 >> > >&g

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

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. > > > >

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

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

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

king 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 in the backend.. BR, -R > &

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

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 > &g

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 onl

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: > >

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

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

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

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 the de

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

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 > > are g

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

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

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. > >

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

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

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: > >

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]

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.

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 de

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

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 Clark wrote: > >

[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

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

y 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 Reviewed-b

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

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 me

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

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

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 some out of

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

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 }, > > ^ > > > >

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

ust 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: > > > > Is t

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

ension. 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: Rob

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

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 flight by

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. > >

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

e; > + 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-comment: split

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.pl b/scri

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 > > > +++

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 =

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

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

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)

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/mesa

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't hi

  1   2   3   4   5   6   7   8   9   10   >