<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]
<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
<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
<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?
<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