08:37 <warpme_> hi *

08:39 <warpme_> just quick Q: playing with t720 (allwinner h6) current mesa master and xorg 1.20.5 I see in xorg log: (EE) AIGLX error: sun4i-drm does not export required DRI extension. May this explain black screen on h6. (exactly the same software not show such error on amlogic/rockchip and works ok on panfrost t820 (s912).

08:55 <HdkR> I think this is more that older Mali midgard is currently broken

08:58 <warpme_> HdkR: I’m a bit confused about „older Mali midgard” - i’m using current mesa master.

09:04 <HdkR> t720 is an older Midgard. ARM made multiple generations of midgard

09:04 <HdkR> t720 is SFBD while t820 is MFBD

09:04 <HdkR> SFBD is currently broken

09:12 <warpme_> ah ok - so this falls into current state of things where mesa not yet supports mali hw with SFBD (like t720)?

09:14 <HdkR> It was implemented, just became broken once everyonw was looking at MFBD

09:58 <robmur01> SFBD is actually sort-of-mostly-working ATM (at least for my T620)

10:01 <robmur01> most of glmark2 runs OK - primarily, 'shadow' fails an assert and blows up, while 'desktop' and 'refract' run but don't render properly

10:03 <tomeu> sounds pretty good already

10:05 <bbrezillon> tomeu: did you find a drm-sched regression or was it something else?

10:05 <robmur01> and even those are actually regressions rather than missing functionality - they were working OK a while ago

10:06 <bbrezillon> I'm testing some of my changes on top of drm-misc-next and deqp-volt hangs

10:06 <bbrezillon> was working fine with v5.3-rc8

10:18 <warpme_> robmur01: regarding SFBD - do You have working it with xorg?

10:23 <robmur01> nope - my dev board doesn't have a desktop set up, I just use glmark2-es2-drm from the console

10:24 <mardestan> HdkR: maybe at some point with grown up men like karolherbst you will find that only knowing Ohm's law ain't gonna be enough to be allround brilliant programmer.

10:25 <warpme_> ok. thx. I’m asking as i’m trying to fing root cause of „(EE) AIGLX error: sun4i-drm does not export required DRI extension” in my xorg. it looks like this is because of current state of things in mesa for SFBD….

11:50 <tomeu> bbrezillon: on the veyron?

11:50 <tomeu> bbrezillon: I tested on drm-misc-next a few days ago and it worked fine on the kevin

11:53 <bbrezillon> tomeu: I'm testing drm-misc-next-fixes

11:53 <bbrezillon> on a rockpi

11:54 <tomeu> oh, that has way few stuff, right?

11:54 <bbrezillon> and I get timeouts

11:54 <tomeu> bbrezillon: can I see them?

11:54 <bbrezillon> and weston is just a black screen

11:55 <bbrezillon> tomeu: drm-misc-next includes robher's AS fixes

11:55 <bbrezillon> sorry, drm-misc-next-fixes

11:55 <bbrezillon> too many drm-misc- branches

11:56 <bbrezillon> http://code.bulix.org/ykwh82-868307

11:59 <bbrezillon> tomeu: and drm-misc-next didn't work for me

11:59 <bbrezillon> I had GPU page faults in the middle of a deqp run

12:01 <bbrezillon> http://code.bulix.org/al7isj-868313

12:19 <tomeu> bbrezillon: the timeouts with 0x0 values in them means that the GPU isn't pwoered up

12:20 <tomeu> there's some regulator commits in there that seem to be causing problems

12:20 <tomeu> would be gret if you could find out which and report it so it gets reverted (or fixed)

12:20 <tomeu> bbrezillon: about the page faults, no idea

12:21 <tomeu> robher, robmur01 ^

12:22 <bbrezillon> tomeu: I guess that's what robher patches were fixing

12:22 <tomeu> could be, not sure

12:35 <robmur01> that "(GPU VA = 100000000)" looks a bit suspect

12:46 <robmur01> the actual fault addresses look reasonable, so how the round trip through addr_to_drm_mm_node() manages to resolve to a node apparently past the top of the mm is troubling

12:47 <robher> bbrezillon: Steven posted a fix a few days ago that might be the same.

12:56 <shadeslayer> bbrezillon: yay, everyone seems to like the idea of a common IOCTL to label gem bo's

12:58 <bbrezillon> shadeslayer: great!

12:59 <bbrezillon> robher: a fix for the timeouts or the page faults?

13:00 <bbrezillon> guess we're talking about " drm/panfrost: Prevent race when handling page fault"

13:01 <alyssa> shadeslayer: If we're doing common, what about common for non-GEM, too?

13:01 <alyssa> Or does that not make sense?

13:01 <alyssa> (Thinking about V4L integration, etc)

13:03 <bbrezillon> alyssa: yes, could be attached to a dma-buf too

13:04 <bbrezillon> though, a GEM does not necessarily have a dma-buf attached to it

13:05 <bbrezillon> so I guess we'd need the label in both places

13:05 <alyssa> bbrezillon: Mm, I'm just thinking about trying for a generic thing if we're going to muck with the common UABI

13:06 <alyssa> So we want to think about not just non-Panfrost but also non-GPU use cases, since potentially this sort of thing could be useful to media people and maybe others

13:06 <alyssa> On one hand feature creep, otoh changing the UABI is hard so you want to get it right the first time :p

13:08 <bbrezillon> it can't really be the same ioctl since they will target different objects (a GEM, a DMABUF or a V4L2 buffer), but we can probably try to make the API similar

13:10 <shadeslayer> ^^ this is getting pretty broad in scope tbh, and what I'd suggest is, we do GEM labelling first, learn our lessons there, then extend to others

13:23 <bbrezillon> shadeslayer: yes, I also think it's the right strategy

13:24 <bbrezillon> as I said, it can't be the same ioctl anyway

13:25 <bbrezillon> but if we provide that works fine for DRM, there's chances it will be applied to V4L/DMABUF at some point

13:25 <bbrezillon> *provide something

13:31 <tomeu> so the ioctl will be per allocator, but the debugfs file will display all labeled BOs regardless of how it was allocated?

13:42 <bbrezillon> tomeu: are we discussing the debugfs interface already?

13:42 <bbrezillon> sorry, haven't followed the discussed on the ML

13:48 <shadeslayer> nah, debugfs interface comes after

13:51 <tomeu> hmm, are the labels useful without a way to display them?

14:02 <shadeslayer> tomeu: well, I'm also going patch the panfrost driver to display the label when a page fault occurs

14:05 <bbrezillon> shadeslayer: and I guess there's an ioctl to retrieve the label attached to a BO

14:08 <shadeslayer> bbrezillon: I'm sure we can add one

14:08 <shadeslayer> I'm working on the patch

15:31 <alyssa> robmur01: Often page faults are from buffer overruns

15:32 <alyssa> So it can be helpful to see the label of the BO that was, say, exactly 1 page before the fault

15:36 <robmur01> alyssa: yup, that could be handy. Might also be possible to do something similar for use-after-free by poking at the BO cache

15:36 <alyssa> Mm, yeah

15:51 <narmstrong> tomeu: https://gitlab.freedesktop.org/narmstrong/mesa/-/jobs/606003

15:51 <narmstrong> Almost ! But timeout occurs too early...

16:39 <alyssa> Okay, hullo again