00:17 <alyssa----> robher: tomeu: By the way, are we still aiming for 5.2?

00:18 <anarsoul> isn't it a bit late assuming 5.1 window is closed?

00:19 <Lyude> yeah

00:19 <Lyude> better to wait for 5.2 at this point

00:19 <alyssa----> Lyude: That's what I said...?

00:19 <Lyude> Oh

00:19 <Lyude> I think we both misread your post at the same time

00:19 <Lyude> what a coincidence

00:20 <alyssa----> tomeu: robher: Nothing on the TODO list looks like a blocker, I think

01:01 <robher> alyssa----: there is the question of doing GPU VA space management in userspace instead.

01:20 <alyssa----> robher: :/

02:36 <alyssa----> Time to look into cubemaps, I think

02:37 <alyssa----> At least enough so we go from "crash" to "fail" :P

03:22 <alyssa----> Oh, this is some interesting lowering

03:22 <alyssa----> Well, an opt I guess

03:22 <alyssa----> TL;DR "hard to compute constants" can be moved out of a fragment shader and into an intermediate shader stage and fed in as a uniform

06:42 <tomeu> cubemaps!

06:43 <tomeu> robher, alyssa----: will look at that in a few days

06:44 <tomeu> at the very least, to have a better idea of how the UAPI would look like

13:45 <tomeu> alyssa----: so, the problem with -brefract on weston (and possibly any other scene) is that glmark2 tries to run there at a much higher rate than 60fps

13:46 <tomeu> and the DRM backend isn't blocking after every job as the non-drm does

13:46 <tomeu> instead, it returns a fence that gallium can choose to wait on or not

13:46 <tomeu> what gallium doesn't know is that jobs share scrap buffers

13:47 <tomeu> so it doesn't wait before a new render starts, and panfrost overwrites data that current jobs depended on

13:47 <tomeu> if I actually wait for rendering to finish in force_flush_fragment, stuff looks fine

14:13 <chewitt> @alyssa---- you posted this patch to the list but I didn't see it get merged

14:13 <chewitt> https://github.com/chewitt/LibreELEC.tv/blob/amlogic/packages/graphics/mesa/patches/panfrost/b-Always-shadow-vertex-elements-buffers.patch

14:13 <chewitt> after mesa changes merged last night things are quite fluid in the Kodi GUI now

14:14 <chewitt> still some mem leakage over time

14:15 <chewitt> no change to the dim/black screensavers refusing to run

14:15 <chewitt> i've switched my test codebase to the drm driver now :)

15:06 <alyssa----> tomeu: You say it like "if I actually wait for rendering to finish in force_flush_fragment" is a hack, but what do you think "Force flush" implied? ;P

15:07 <alyssa----> chewitt: Yeah, that patch is a major hack. The real solution will take a lot more thinking (to avoid the performance disaster associated with that patch) but other items are higher-prio... so this way you can merge the patch for Kodi and have those bugs fixed, and I can continue to get reliable perf numbers? :P

15:07 <alyssa----> Might have to revisit it soon for dEQP, though

15:08 <alyssa----> Happy to hear the rendering glitches fixed themselves. Not really sure what the culprit was, since I was fixing a lot of rather obscure stuff, but hey :P

15:28 <tomeu> alyssa----: yeah, that was just to explain what was going on

15:28 <alyssa----> :+1:

16:21 <Lyude> tomeu: btw, curious: will panfrost's kernel driver have SAME_VA and such like kbase?

16:58 <tomeu> Lyude: I think it's not clear atm, robher is taking care of all the MM stuff

17:26 <alyssa----> there's discussion on the list rn about this

20:10 <robher> Lyude: For my own education, why do you care or want that?

20:11 <Lyude> robher: I'm honestly just curious

20:11 <Lyude> since you guys had been talking about doing VAs in userspace earlier

20:13 <robher> Lyude: I'm just trying to gauge whether we really need to support it from the start.

20:17 <Lyude> hh

20:17 <Lyude> *ahh