alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - Transientification is terminating. Memory reductions in progress.
* alyssa chases mem leaks farther
<alyssa> I feel like I'm getting closer..?
<alyssa> Evidence: none, but sentiments
<alyssa> Nope, wasn't that
NeuroScr_ has joined #panfrost
NeuroScr has quit [Ping timeout: 268 seconds]
NeuroScr_ is now known as NeuroScr
NeuroScr has quit [Read error: No route to host]
NeuroScr has joined #panfrost
NeuroScr has quit [Ping timeout: 258 seconds]
NeuroScr has joined #panfrost
<robclark> robher, w/ mali can you end up w/ same gpu-id (including minor revision #) with different set of bugs? That (fortunately) isn't a scenario that I've had to deal with for adreno.. if that isn't a problem keeping table of gpu-id and bugs/quirks in userspace seems sane.. espec since I guess as time goes on you'll discover more and rev'ing uabi each time would suck..
<robclark> (also, getting a fix to users with just a mesa update and not requiring a kernel update too is nice)
<alyssa> Users? What are those?
<robclark> with the # of arm mali boards out there, and # of chromebooks w/ mali, etc.. if you build it, they will come ;-)
<alyssa> Hmm... interesting proposition... :)
NeuroScr_ has joined #panfrost
NeuroScr has quit [Read error: Connection reset by peer]
NeuroScr_ is now known as NeuroScr
adjtm_ has joined #panfrost
adjtm has quit [Ping timeout: 250 seconds]
adjtm_ has quit [Remote host closed the connection]
adjtm has joined #panfrost
<memeka> alyssa: is the patch on the mesa ML the only one I should test on my T628?
<alyssa> memeka: There are overlay changes, uhh
<memeka> alyssa: so, erm... what repo should i use, what branch and what patches? :))
stikonas has quit [Remote host closed the connection]
<memeka> alyssa: this one? anything else?
<alyssa> 'Upstream mesa, the patch on the ML
<memeka> alyssa: upstream master?
<alyssa> Probably
<alyssa> Build broke since last night, need to fix that
<alyssa> I dunno, this will get easier once I get said patch merged
<memeka> alyssa: this is the log, I get black screen with kmscube
<memeka> any ideas?
<alyssa> Did you set the hw version
<alyssa> is_t6xx = true
<alyssa> require_sfbd = true
<memeka> yes
<alyssa> Uhhh
<alyssa> dmesg?
<memeka> nothing
* alyssa blinks
<alyssa> kbase version?
<alyssa> 11.11, right
<alyssa> uhhhh
<alyssa> Not sure..
<memeka> do i also need special kmscube? :)
<alyssa> That's the right kmscube :p
<memeka> $ git diff | grep 'is_t6xx\|require_sfbd' | head -n2
<memeka> +static bool is_t6xx = true;
<memeka> +static bool require_sfbd = true;
<memeka> alyssa: all seems good :( no errors, screen black :(
<memeka> alyssa: do I need to add exynos to the list of drms?
<alyssa> Probably
<alyssa> Grep for rockchip, anywhere you see that exynos should be
<alyssa> Although I'd expect if that was the issue, you'd already have seen it?
<alyssa> I can't view that
<memeka> Legacy (non-DRM) operation requires out-of-tree overlay
<memeka> MESA-LOADER: failed to open kms_swrast (search paths /usr/local/panfrost/lib/arm-linux-gnueabihf/dri)
<memeka> failed to load driver: kms_swrast
<memeka> MESA-LOADER: failed to open swrast (search paths /usr/local/panfrost/lib/arm-linux-gnueabihf/dri)
<memeka> failed to load swrast driver
<memeka> Segmentation fault
<memeka> there is an in /usr/local/panfrost/lib/arm-linux-gnueabihf/dri tho`
<alyssa> "Legacy (non-DRM) operation requires out-of-tree overlay" Yeah, you need the overlay
<memeka> what's the overlay? :(
* alyssa is carrying a bunch of out of tree crap..
<memeka> alyssa: nondrm is not being compiled :(
<alyssa> That would be a problem, yes..
<memeka> alyssa: ok we have progress :)
<memeka> ../src/gallium/drivers/panfrost/nondrm/pan_nondrm.c: In function ‘panfrost_create_nondrm_driver’:
<memeka> ../src/gallium/drivers/panfrost/nondrm/pan_nondrm.c:345:14: error: ‘struct panfrost_driver’ has no member named ‘free_slab’
<memeka> driver->base.free_slab = panfrost_nondrm_free_slab;
<memeka> :)
<alyssa> Yeah, sorry, bad at versioning cross repo stuff
<memeka> let's try w/o free :)
<alyssa> That'll do
<memeka> Created resource 0xab7758 with scanout (nil)
<memeka> Uploaded transient 896 bytes
<memeka> Using modifier ffffffffffffff
<memeka> failed to set mode: Unknown error 524
<memeka> [drm:exynos_plane_atomic_check] *ERROR* unsupported pixel format modifier
<memeka> on it :)
<memeka> alyssa: OOK i have a blinking screen :)
<alyssa> That's... progress :p
<memeka> alyssa: any idea? :(
* alyssa makes progress on bugs around perspective division
<alyssa> Isn't that cute? SuperTuxKart running on Panfrost :)
<alyssa> A _lot_ of room for optimization, but hey, only direction is up!
<alyssa> And it's faster than a software rast, right? :P
<alyssa> ^ Happy Panfrosting :)
<HdkR> woo?
<alyssa> HdkR: Woo!!
<tomeu> alyssa: looks great!
<davidlt> alyssa, can you actually play it?
<tomeu> alyssa: I also don't like those constants, but I feel it's a bit early to figure out something definitive
<tomeu> robher: I would also prefer to expose features and bugs, but what do we do about differences in register values between revisions?
<tomeu> guess we could call that reg_def_v1 and reg_def_v2 features, but I'm not sure that's any clearer
<tomeu> so maybe we can use features and bugs as much as possible, but then use GPU IDs for those changes between hw revisions that seem arbitrary to our current knowledge
<alyssa> davidlt: No, I suck at video games :)
<alyssa> But yes, hypothetically somebody could play it, someone other than me ;)
<alyssa> tomeu: Thanks! :)
<davidlt> alyssa, amazing!
<alyssa> tomeu: Rob et al did raise a fair point about not requiring kernel updates for userspace fixes..
<alyssa> davidlt: :)
<davidlt> I feel a lot better now buying Pinebook Pro
<alyssa> Haha
<tomeu> alyssa: yeah, guess features can be provided by the kernel (as it will anyway need it), and bugs for the cmdstream, compiler?, etc can be kept in userspace
* alyssa shrugs
<alyssa> Up to you and Rob really :)
Elpaulo has joined #panfrost
* alyssa just sent the corresponding patchset off to the list
<tomeu> I'm right now in more of a discovery phase
<alyssa> tomeu: That's alright!
* alyssa wonders where we are in terms of GNOME Shell
<davidlt> that would be interesting!
BenG83 has quit [Ping timeout: 250 seconds]
pH5 has quit [Quit: bye]
chewitt has joined #panfrost
maciejjo_ is now known as maciejjo
<daniels> karting! \o/
<HdkR> Now we just need Mario Karting
<HdkR> Time for ES 3.0
<davidlt> panfrost seems to be in decent condition that it can do Weston and SuperTuxKart
<HdkR> It's coming together :)
raster has joined #panfrost
<tomeu> we're close to have the 90% that takes 10% of the time :p
<raster> don't you mean the 10% that takes 90% of the time? :)
<tomeu> not sure we'll be "finished" in 10% of the time :)
davidlt has quit [Ping timeout: 245 seconds]
<raster> it'll be the 99% of the time :)
davidlt has joined #panfrost
<davidlt> tomeu, I notice there are people from collabora (incl. you), are there particular company-wise interest?
<tomeu> cannot talk for the whole company, but lots of people have a strong interest in free GPU drivers
<tomeu> and we generally hate having to work on projects with blobs
<HdkR> New blobs also don't support X, So you could get screwed on projects :P
<daniels> HdkR: avoiding X is a huge feature tbf
<HdkR> Unless you need X for something anyway
<daniels> davidlt: collabora is really interested in panfrost; having open drivers is better for absolutely everyone, and we are putting a bit of our own time towards helping panfrost. unfortunately though we are a consultancy, so the amount of time we can spend on this without anyone paying us for it is naturally limited :P
<HdkR> I hear getting access to the DDK is a huge PITA now
<daniels> depends how deep your pockets are
<HdkR> yea
<daniels> HdkR: depends on your line of work really. for things like steam or desktops where you want to run CAD apps, you'll not escape X for quite a while to come. but for the kinds of projects we work on, we've been actively trying to avoid X for years now, but also we haven't had any clients ask for X11 work (apart from DRI3 modifiers) in a very long time.
<raster> HdkR: X? we need to support X? we aren't all on wl by now? :)
<davidlt> I haven't run X server myself for a long time
<davidlt> Wayland for set as default on my GNOME shell for some years now
<raster> i'm not far from being able to move to wl
<raster> i need multihead to work
<davidlt> well, there is XWayland..
<davidlt> does that have issue?
<HdkR> That's nice to know. Good thing people are getting away from X. Sadly I still run it at this point in life :P
<raster> HdkR: as long as xwayland lets things run with acceleration i think we are on a good path to moving on
<raster> that will be our crutch for years to come
chewitt has quit [Max SendQ exceeded]
<urjaman> for me it's basically: when XFWM becomes a wayland compositor (and everything else works too, i havent tested much because why when it's not what i want) i might move to wayland...
<HdkR> Once I can get away from the Nvidia blob hopefully sway will be feature complete enough to replace i3 :D
chewitt has joined #panfrost
<HdkR> Last I looked, multimonitor support was still problematic
<davidlt> I am looking into testing sway at some point
<davidlt> 2020 will be interesting with Intel dGPU
<davidlt> In their feedback process no blobs, open source driver was on top of requested things
<raster> urjaman: is xfce looking at becoming a wl party guest? :)
<raster> HdkR: tried amd lately?
<HdkR> I wish. Sort of required to use Nvidia atm :P
<HdkR> Looking forward to the Intel dGPU in the future as well
<raster> i wonder what the performance of that will be
<urjaman> raster: last i looked they were like first working towards all the apps working with wayland (that is helped my gtk wayland support but still), so it was like not very quickly but maybe some day
<urjaman> *helped by
<raster> urjaman: aaaah thats fair enough.
<raster> we already have that all settled but need to fill in multihead to be useful day to day
<davidlt> raster, the performance will be good enough as long as we have open source driver and no-problems-setup :)
<raster> davidlt: well intel gpus are "good enough" for a desktop already
<raster> games.... that is a debate
<raster> depends on the game
<davidlt> yeah, their plan to talk more about Gen 11 at GDC
<davidlt> IIUC upscaled Gen 11 will be dGPU
<HdkR> Oh? GDC is going to be a good time
<HdkR> Wonder if I should try going then :P
<raster> welll it's been team green vs team red for so long...
<raster> team blue might shake things up a bit
<davidlt> it's funny, because I want Zen 2 CPU w/ Intel dGPU :D
<HdkR> I'm looking forward to Rome
<davidlt> Yeah, that's nice 9 die package
<davidlt> I hope they can do active interposer in 1-2 years
<davidlt> I was surprised Intel kind beat AMD to that with FOVEROS
<davidlt> I think, we finally got to really exciting times in computing (custom silicon / IP blocks, multi-die processors, stacking / active interposers)
<davidlt> Hopefully software can keep up
<HdkR> Software will work well enough, might just not be completely optimal :P
<HdkR> Threadripper multi-die packaging already showing issues
<HdkR> As seen by Mesa + Blender issues :P
<davidlt> yeah, but that's most likely software issues :)
<HdkR> It was
<HdkR> Might be fixed now, haven't tried
<HdkR> Pinned Blender to one cluster. Causing CPU renders to run at 1/4th rate
<HdkR> Can make sense in most gaming situations to do some sort of pinning
<davidlt> IIUC you can also select UMA / NUMA in UEFI
<davidlt> that will change what OS sees and change how scheduling is done
<HdkR> That doesn't work on the 2990WX :P
<robher> tomeu, alyssa: I think my plan is just expose all the feature register values to userspace as-is (via get_param). The vendor driver does that plus some parsed values to 'optimize' access. Maybe we can add those cases as needed, but otherwise kernel and userspace will each be responsible for pulling out what they need.
<tomeu> sounds good to me
<tomeu> robher: do we have any immediate need for those feature regs?
<robher> tomeu: yes, the command submission does. No idea what userspace needs though.
<HdkR> hardware version/revision mostly :P
<tomeu> that's already exposed
<tomeu> so I guess we can expose more regs to userspace later, as needed
raster has quit [Remote host closed the connection]
<HdkR> nice
<robher> Once we get to a stable ABI, we don't want to be adding things as needed.
<tomeu> well, I hope we don't commit to ABI stability before we have the basics there
<tomeu> robher: do I understand correctly that we only need for the submit ioctl to have a list of BOs for implicit sync?
<tomeu> as we are mapping to the GPU on creation
<robher> tomeu: no idea...
<tomeu> ok, will start with what I think it's absolutely needed
<tomeu> what's this timeline stream thing? is this for gator?
<tomeu> ah yes, seems to be some tracing infra
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
<tomeu> robher: have started drafting how job submission could start to
<tomeu> already have the mesa side of it
<tomeu> in my monday I could keep moving towards the hw
<tomeu> sorry, ran out of time before coming up with something more polished
<robher> tomeu: all the gator and timeline stream can go to /dev/null. But we should think about tracepoints at some point.
<tomeu> yeah, once we finish panfrost I would like to enable project catapult's systrace on regular linux userspace + weston
<tomeu> will be great to integrate gpu perf counters as well with it
<MoeIcenowy> what kernel driver does panfrost use now?
<tomeu> MoeIcenowy: the only functional one is ARM's
<MoeIcenowy> which version?
TheKit has quit [Ping timeout: 250 seconds]
TheKit has joined #panfrost
raster has joined #panfrost
alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature tbf
* alyssa looks at raster like he has three heads
<alyssa> robher: Alright. I think it makes sense just to expose the stuff as-is, yes -- userspace can pick out what it needs, kernelspace can pick out what it needs, minimal ABI breakage when one side needs something different than the other, everyone's happy? :)
<alyssa> MoeIcenowy: The one TheCycoONE pointed at
stikonas has joined #panfrost
alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
<HdkR> hah
<alyssa> HdkR: ?It's true!
<HdkR> I find it funnier in the topic :P
pH5 has joined #panfrost
chewitt has quit [Ping timeout: 268 seconds]
NeuroScr has quit [Read error: No route to host]
NeuroScr has joined #panfrost
NeuroScr has quit [Read error: Connection reset by peer]
NeuroScr has joined #panfrost
TheKit has quit [Ping timeout: 246 seconds]
NeuroScr has quit [Ping timeout: 245 seconds]
NeuroScr has joined #panfrost
<MoeIcenowy> hahahahahahahaha
<MoeIcenowy> but can Panfrost be used with X/
<MoeIcenowy> ?
<HdkR> Demo at XDC was running X :P
TheKit has joined #panfrost
<daniels> yeah, modern xorg just requires a kms driver, plus a standard gbm/dmabuf implementation, and then dri3 you get for free with mesa
raster has quit [Remote host closed the connection]
<TheKit> how is Xorg performance of Panfrost + glamor?
NeuroScr has quit [Ping timeout: 257 seconds]
afaerber has quit [Quit: Leaving]
NeuroScr has joined #panfrost
NeuroScr has quit [Ping timeout: 246 seconds]
afaerber has joined #panfrost
vakkov_ has joined #panfrost
chewitt has joined #panfrost
indy has quit [Quit: ZNC -]
indy has joined #panfrost
indy has quit [Quit: ZNC -]
indy has joined #panfrost