alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - - Logs - <daniels> avoiding X is a huge feature
<alyssa> stikonas: We're aiming for 5.2 for the initial merge... we'll see if we hit that, but we're hopeful (v3 is on review)
<alyssa> And yes, kbase is GPL because of licensing obligations. The code isn't mainline quality (the Panfrost kernel is).
<alyssa> We don't offer support for legacy (proprietary userspace or NIH kernelspace) in here.
<alyssa> We do support the modern driver stack :D
<stikonas> well, so my answer to milloni was mostly right :)
<stikonas> anyway, nice to hear that it might be in 5.2
NeuroScr has quit [Quit: NeuroScr]
<alyssa> Hope so!
<cyrozap> milloni: You don't need the proprietary userspace blob to get video output, so even if you were missing it that's probably not the cause of your monitor issues.
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
adjtm_ has quit [Remote host closed the connection]
cwabbott has quit [Remote host closed the connection]
stikonas has quit [Remote host closed the connection]
adjtm has joined #panfrost
bnieuwenhuizen has quit [Quit: No Ping reply in 180 seconds.]
bnieuwenhuizen has joined #panfrost
<hanetzer> urjaman: hey, did those c201 patches of yours make it into u-boot ?
<hanetzer> milloni: basically upstream kernel is understandably picky about what code they let in :)
vstehle has quit [Ping timeout: 250 seconds]
robclark has joined #panfrost
chewitt has joined #panfrost
travankor1 has joined #panfrost
robclark has quit [Ping timeout: 240 seconds]
cwabbott has joined #panfrost
vstehle has joined #panfrost
<urjaman> hanetzer: working on it ...
<hanetzer> got a link? :)
chewitt has quit [Quit: Zzz..]
<urjaman> to be more accurate, the boot fixes got reviewed but afaik nobody took them into any of the trees yet, and the configuration etc (eMMC GPT, poweroff) didnt get much attention
<urjaman> but yes wait a sec
<urjaman> the boot fixes are in that series ... and i guess i could actually link then in the patchwork ...
chewitt has joined #panfrost
<urjaman> (i was thinking of sending some "pings" about these like soon-ish but also i am lazy etc...)
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
pH5 has quit [Quit: bye]
<hanetzer> urjaman: you da man. Warning tho, your efi patches need rebasing ;)
<hanetzer> or at the very least they do against my current clone, which was updated sometime within the last 6hr or so
<urjaman> ok i'll rebase the whole series at soome point soon
pH5 has joined #panfrost
<urjaman> all of my u-boot stuff (including stuff that is just for me :P) is at
<urjaman> (so yeah 99 new commits in master and some of them are my problem it seems :P)
stikonas has joined #panfrost
<hanetzer> yeah :P
stikonas has quit [Remote host closed the connection]
<urjaman> that commit message doesnt even have a sign off, also it's not a commit message but just an email describing a problem :P
<urjaman> (also yeah git didnt have any problems with the rebase, - i guess i'll re-send the efi patches as v2: rebased along with my ping, but right now it's too early for me to be thinking and i have a shopping trip to do so ... laters.)
raster has joined #panfrost
<kszaq> I put together patches to override GPU "bitness": first two are non-functional changes, third one introduces C-flag to force GPU "bitness" - I don't know if it's a good approach, perhaps something meson-related would be better? All suggestions are very welcome. :)
<HdkR> Probably want something that is runtime selectable?
<HdkR> Makes packaging a single binary for multiple pieces of hardware more viable
raster has quit [Read error: Connection reset by peer]
<kszaq> Yes, that would be ideal
<kszaq> That would probably need more refactoring and having 2 variants of all structs that differ.
raster has joined #panfrost
thefloweringash has quit [Ping timeout: 250 seconds]
travankor1 has quit [Ping timeout: 252 seconds]
sphalerit has quit [Ping timeout: 252 seconds]
tgall_foo has quit [Ping timeout: 250 seconds]
afaerber has joined #panfrost
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<robher> alyssa: seems to be a weston regression:
<robher> Current master. I updated from something pretty old.
<daniels> robher: yeah, need to disable the EGL_EXT_buffer_age extension, or get tile readback actually working so it's no longer lying
tlwoerner has quit [Quit: Leaving]
<raster> robher: partial update broken? yup. also here are other regressions. enlightenment used to render but fbo usage was broken when it happened, now it's all just one big black. :)
tlwoerner has joined #panfrost
<alyssa> Uh oh
<alyssa> kzsaq: HdkR: I mean, the correct solution is to figure out which change is actually necessary for T8xx, because it's not going to be all of them
<alyssa> (And then fix it directly)
yann has quit [Ping timeout: 244 seconds]
pH5 has quit [Quit: bye]
pH5 has joined #panfrost
afaerber has quit [Quit: Leaving]
stikonas has joined #panfrost
raster has quit [Remote host closed the connection]
<robher> Is there midgard h/w that is 32-bit?
<alyssa> robher: Plenty of it, e.g T760
<alyssa> Er not t760
<alyssa> but RK3288 which is armhf with T760
<milloni> robher: do you mean the cpu?
<robher> CPU bit width is different
<milloni> so what would 32-bit/64-bit mean in the context of gpu
* milloni n00b question here
<robher> CPU and GPU are independent.
<robher> GPU has its own address spaces and MMU.
<milloni> its not enitirely clear to me what it means for the cpu to be 32-bit either :) i assume size of general purpose registers
<milloni> don't integrated GPUs share the memory space with the CPU?
<robher> And you can run 32-bit userspace on a 64-bit CPU
<urjaman> i had understood that the T760 whilst having 64-bit addresses had some of the structures memory-optimized
<robher> urjaman: So T760 happened to work with 32-bit builds, but If we had T860 with 32-bit userspace or T760 with 64-bit userspace they wouldn't work.
<urjaman> robher: currently yeah afaik that's true
<urjaman> just a simple matter of programming tho :P
<robher> milloni: ultimately, yes, but there's a lot of addresses in the mix.
<robher> alyssa: armhf is an ABI which works on 32-bit and 64-bit CPUs.
<urjaman> robher: yeah but she meant that the RK3288 has 32-bit CPU
<urjaman> (A12 i think ... )
<urjaman> ah A17 ...
<urjaman> (which are pretty much almost the same thing so :P)
<urjaman> it does have LPAE tho so ...
<robher> urjaman: my point is the CPU is irrelevant here if we are talking GPU h/w data structures.
<robher> LPAE doesn't matter other than highlight that 32-bit doesn't mean 32-bit everywhere.
<urjaman> yeah should be
<urjaman> (and yep that's why i mentioned it ... just to say that it's complicated :P)
<hanetzer> robher: yep. in fact stock chromeos on the kevin is 32 bit user space :)
<hanetzer> hmm. panfrost userspace is not yet in any mesa release?
<stikonas> no, not yet, just git
chewitt has quit [Quit: Zzz..]
chewitt has joined #panfrost
<tomeu> robher, alyssa: I think this project became long ago big enough to need some kind of CI :)
<tomeu> will try to come up with some small steps towards that aim
<TheCycoONE> tomeu: is mesa-ci relevant?
<hanetzer> hey, question you guys may know about. CONFIG_DRM, you still get vid output? just not good?
<hanetzer> working on a tiny kernel to shove into coreboot :)
<Lyude> hanetzer: I think it depends, what kind of video output are we talking?
<hanetzer> the kevin screen
<TheCycoONE> tomeu: the one intel runs
<hanetzer> workin on some corebootish things wrt petitboot
<Lyude> also note, assuming your question was whether you could get video without CONFIG_DRM and not with CONFIG_DRM, but yeah: I don't think that's likely to work
<Lyude> someone else might know more then me, but since there isn't really anything but the kernel driving the display (unlike with x86 where you could get the display from efi or bios) you kind of need the DRM display drivers
<Lyude> if drm is too big it might be a good idea to try making it smaller :)
<Lyude> there's some low hanging fruit there I'm pretty sure
<hanetzer> heh. well, I decided to do an allnoconfig and build from scratch more or less.
<hanetzer> if you start from a defconfig its easy to miss a lot of options to turn off (eg, tegra/sunxi hardware support)
<hanetzer> currently have a 1.9m Image and 812k Image.gz
<alyssa> tomeu: Please yes :)
<alyssa> dEQP regression testing should work well, I think
<Lyude> don't forget piglit
<alyssa> please foregt piglit
<alyssa> dEQP++
<Lyude> out of curiosity, what is wrong with piglit exactly?
janrinze has joined #panfrost
<alyssa> 1. It's not split well into desktop/embedded tests nor by version, which means running "just" the ES2 tests is prohibitively annoying, requiring either hugely convoluted steps or getting large numbers of skipped tests
<alyssa> 2. It doesn't display the tests being run as it goes, just the number, which makes interacting debug prohibitively annoying.
<Lyude> (-v does that btw)
<alyssa> 3. The tests themselves are kind of.. random, I guess? dEQP follows the spec directly and is literally used with some modifications as the CTS for GLES these days.
<alyssa> (I.e. I can be regression testing on the CTS directly)
<alyssa> piglit has some novel stuff, it's my understanding, but for where we're at, dEQP is just... a lot more useful
<janrinze> Has anyone been able to do some testing on G72 yet?
<Lyude> alyssa: alright, I trust whatever you choose of course, I was pretty curious
<Lyude> janrinze: don't need to, that won't work yet
<Lyude> bifrost is going to take a lot of work to bringup
<Lyude> although the intial isa research and assembler works so far
<Lyude> erm, *initial isa research is done and asm works, but that doesn't mean a whole ton
<Lyude> stuff is currently waiting on me/hdkr
<janrinze> Okay, I understand. I saw a few patches which mentioned G72. Probably just preliminary scaffold for future work.
<Lyude> (and cwabbott if they're interested ?)
<Lyude> janrinze: mhm, most likely
<alyssa> Lyude: Read: Piglit is great, I'm just suuuper opinionated ;P
<janrinze> Lyude: If it could do simple DRM and such it would be a nice start already. Leaving the ARM drivers behind and being able to update panfrost as the development continues would be my preference.
<alyssa> But for panfrost CI, please please please dEQP, since then it's working on the same tests I work on
<Lyude> alyssa: btw, some of the randomness you see in the piglit tests is very likely intentional
<alyssa> Touche
<Lyude> a lot of the test cases are written based off previous bugs or issues that were found which made validating certain gl extensions useless, etc etc
<Lyude> usually edge cases
<alyssa> This is true
<alyssa> Lyude: Anyway, you're right, I'm just partisan :p
yann has joined #panfrost
<urjaman> hanetzer: i've sent some pings about the most important c201 u-boot fixes and also sent a rebase of the efi/gpt patches...
<hanetzer> thankie-sai
* urjaman does feel like u-boot folks are either really busy or not very welcoming ...
<urjaman> with some exceptions :)
<hanetzer> happens.
NeuroScr has joined #panfrost
<mmind00> urjaman: so far I haven't met "unwelcoming" people there, but you're right - stuff tends to take time there and people seem to disappear
<mmind00> so I guess it really means busy/stressed
<HdkR> janrinze: I'm using Dvalin rather than G72. Is there a device out with it that can run Linux? :P
<janrinze> HdkR: I have the Hikey970 running Debian 9
<HdkR> Oh right. I also have one of those
<Lyude> mm, hikey 960/970 work alright
<HdkR> :P
<Lyude> 960 is what most of the isa reverse engineering was done on :)
<janrinze> Lyude: The kernel is unfortunately 4.9.78 I have a branch setup at github.
<Lyude> janrinze: yikes, note I haven't tried mainline on it
<janrinze> Lyude: which kernel did you use?
<Lyude> janrinze: android :P
<Lyude> honestly haven't had the time to setup my systems on mainline yet
<Lyude> other than the vim2
<janrinze> Lyude: Hmm.. Android has a much different graphics system
<janrinze> Mainline linux hardly works on the Hikey970.
<janrinze> Mani has introduced the platform and I think the serial console and block devices are about all that you get with it.
<janrinze> introduced it in mainline, that is
<janrinze> For a simple test, what would be the shortest route to setup? (can do compile/debug etc. been porting for a few decades.)
<Lyude> do you mean for the hikey? note again we don't support bifrost at all yet
<janrinze> Lyude: so there is nothing to test yet, right?
<Lyude> yes
<janrinze> Lyude: Okay. understood. Hope to see some development in the future, the DRM driver on this board (I'm typing this using the Hikey970) is quite poor and there is zero chance of getiing mali drivers from either HiSilicon or LeMaker. So I guess panfrost is the last hope for a decent desktop experience on this board.
<Lyude> of course :)
<Lyude> honestly i'm itching to work on bifrost
<HdkR> Itchy scratchy
<janrinze> Lyude: drop me a ping sometime in the future when you had time to work on it. I'll gladly help out where I can.
<janrinze> HdkR: :D
janrinze has quit [Remote host closed the connection]
janrinze has joined #panfrost
<urjaman> mmind00: yeah wasnt meaning unwelcoming in any active way, more like a feeling of "am i invisible?" :P
<urjaman> but now i'm back to Falcon Heavy
pH5 has quit [Ping timeout: 264 seconds]
<hanetzer> would help if I enabled kexec support in my kernel :P
<hanetzer> bleh, hisilicon
<hanetzer> vendor of IoT 'security system' SoCs, terrible stuff :P
<alyssa> IoS
<hanetzer> 'greed
<alyssa> 'vanity
<HdkR> alyssa: Internet of suck?
<hanetzer> their chips could actually be useful if they did open source the right way :P
pH5 has joined #panfrost
pH5 has quit [Client Quit]
<Lyude> hanetzer: a hisilicon lives in my apt's security cameras, even :)
<alyssa> # apt install backdoors
<hanetzer> yep. our cameras run hisi chips too.
<hanetzer> ever try some of the more well-known backdoors on them?
<hanetzer> we used to have a pair of boxes that had that 6-digit backdoor password, was the zip code for where they were made
<janrinze> hanetzer: which HiSilicon device? I tried kexec on hikey970, did not work.
<hanetzer> janrinze: I'm not doing kexec on hisi. the conversation's just happened to intersect
<janrinze> hanetzer: :D happens.
<hanetzer> kexec seems to not be in a workable state for arm64... :<
Elpaulo has joined #panfrost
<janrinze> indeed. wonder why that is. with so many well supported boards ;-)
janrinze has quit [Remote host closed the connection]
interface{} is now known as empty_string
janrinze has joined #panfrost
vstehle has quit [*.net *.split]
adjtm has quit [*.net *.split]
TheCycoONE has quit [*.net *.split]
Lyude has quit [*.net *.split]
phh has quit [*.net *.split]
maciejjo has quit [*.net *.split]
adjtm has joined #panfrost
maciejjo has joined #panfrost
TheCycoONE has joined #panfrost
vstehle has joined #panfrost
phh has joined #panfrost
Lyude has joined #panfrost
Elpaulo has quit [Ping timeout: 252 seconds]