<HdkR>
I...might actually just work on the shader compiler. Was trying to backport panfrost DRM to 4.9 and it ended up being pain
<HdkR>
DOes the Hikey 970 support upstreamish kernel that would work to bring newer DRM to life on Bifrost?
<HdkR>
janrinze: ^ Maybe you know? :D
<anarsoul>
HdkR: they added sd and wifi support recently to mainline kernel, so I guess you can play with render-only (no display yet)
<anarsoul>
and no usb either
<alyssa>
HdkR: Yo, you gotta get it into my inbox or it doesn't exist. Resend :P
<alyssa>
<alyssa@rosenzweig.io>
<HdkR>
You're not part of mesa-dev?
<alyssa>
HdkR: Too much traffic. If I'm not cc'd/to'd, I don't get it.
<alyssa>
I'm technically a subscriber (so I don't need mod approval) but I don't actually, you know, get the mail
<HdkR>
I see. I use the magic of filtering myself :P
<HdkR>
anarsoul: Neat. So I could ssh in to the thing? :)
<anarsoul>
I guess
<HdkR>
alyssa: There you go
<anarsoul>
I don't have the board, I just looked for hikey970 patches in lakml
<HdkR>
Alright. I'll have to check it out later then
<alyssa>
HdkR: Thank you! It'll take me a bit to get to, since this is a lot of code and I want to really understand it (so I can contribute to Bifrost stuff in the future)
<alyssa>
But when I have time energy, I'll chew through this :)
<HdkR>
NP
<HdkR>
I'll just be working on the shader compiler now. Probably swap it around fairly significantly
<HdkR>
alyssa: btw, have you put much thought in to moving the shader compilers in to "common" space like the intel and radeon ones? :P
<alyssa>
HdkR: I have, actually.
<alyssa>
Consensus (between me and my much smarter, much prettier imaginary friend version of myself) is that there's no point before we do Vulkan.
<HdkR>
Right, so we need someone with enough time and energy to start working on that side
<alyssa>
HdkR: Vulkan is zero-priority.
<alyssa>
There are a lot of things that *really* matter.
<alyssa>
That is literally just not one of them.
<HdkR>
Slightly higher than zero for me :D
<alyssa>
Please no :P
<HdkR>
But that's because I'm rude
<alyssa>
If somebody's goal is "write a Vulkan driver", sure, I'd love panvk.
<HdkR>
hehe
<alyssa>
But if it's "write a Mali driver", please, no, Vulkan will waste your time.
<alyssa>
You know?
<HdkR>
yep
<HdkR>
alyssa: Do you want the compiler to be uploaded during active development to make the code easier to digest for review?
<HdkR>
uploaded/upstreamed
<alyssa>
HdkR: Mayhaps.
<alyssa>
HdkR: I'd say once you're correct compiling some simple shaders without huge hacks, that's a good time.
<alyssa>
I.e. when review starts to become productive as opposed to just getting in your way
<HdkR>
Alright :)
<alyssa>
And obviously I need to learn Bifrost first and get the disasm merged first, so that'll help buffer the time a bit :)
afaerber has quit [Ping timeout: 240 seconds]
kszaq has quit [Quit: Connection closed for inactivity]
afaerber has joined #panfrost
<alyssa>
Patches eliminating the staging buffer on the list. Performance is happy.
<HdkR>
woo
* HdkR
reviews
<alyssa>
HdkR: Please no, patch #1 is awful
<alyssa>
Mostly since it should be 3 patches but w/e :P
<HdkR>
:D
<alyssa>
:D
<robher>
HdkR: jstultz can probably give hikey970 upstream status. I don't recall seeing much in the way of DT patches for it.
<HdkR>
alyssa: Fine then, I'll continue rewriting this compiler from the ground up
<HdkR>
robher: That'll be good, If it gets closer to upstream than this board for DRM things then it'll be my main board for actually testing Bifrost
<HdkR>
this board being ODROID-N2
<alyssa>
Wee
jolan has quit [Remote host closed the connection]
jolan has joined #panfrost
<jstultz>
HdkR: so on the hikey960, we are getting the DRM bits refactored to be able to send upstream. hopefully soonish? On the 970, I don't really know. I've been told the 970 is very similar to the 960, so maybe the drm driver can be shared there?
<alyssa>
jstultz: \ o /
<HdkR>
jstultz: I can use either the 960 or 970 doesn't matter to me since both are Bifrost
<jstultz>
hoping USB can get queued for 5.2 (but we're cutting it close), then DRM is next on the focus list
<HdkR>
Hmm. How would you ssh in to the board without a USB ethernet nic?
<HdkR>
Wifi I guess?
<jstultz>
HdkR: that's why USB is most urgent right now :)
<HdkR>
ah
<jstultz>
HdkR: wifi support is already upstream
<HdkR>
Well that's good
<jstultz>
HdkR: but for either USB eth or gadget mode nic/adb, we need the usb stack to land
<HdkR>
Is USB support a pain because of the weird multiplexer thing on it?
<jstultz>
HdkR: yea
<HdkR>
Hardcode it so the OTG port is dead :P
<jstultz>
HdkR: well, for Android work the OTG port is really nice :)
<HdkR>
Yea. Linux is a bit more eh though
<HdkR>
:P
* alyssa
looks at her USB-C devices around her with lonely eyes
<alyssa>
If I could plug my Kevins in to each other and share files, that'd be dope, ok? :P
<alyssa>
Frustrated trying to get profiling working, so I guess onto reading about Bifrost :)
<HdkR>
lol
<alyssa>
HdkR: So Bifrost is basically Midgard, except all the hard parts are pushed from the hardware into the compiler
<alyssa>
Lovely.
<HdkR>
alyssa: I mean. The clause bundling and stuff isn't too crazy
<HdkR>
I think the scalar architecture ends up making it easier to work with
<alyssa>
WHat is I0 and I1?
<alyssa>
Oh. Instruction?
<alyssa>
Oh. Got it. This is cute.
<HdkR>
I adore it
<alyssa>
Not a fan of the {} syntax but ok
<alyssa>
My convention for Midgard bundles is putting an empty line between them, which is a lot easier on the eyes tbh
<HdkR>
Oh yea, that's just the "norm" for these things
<alyssa>
HdkR: Is it really? (:)
<HdkR>
Every architecture that bundles instructions together uses them as far as I'm aware
<HdkR>
Itanium, Hexagon, Other CPU architectures, other DSPs, Nvidia
_whitelogger has joined #panfrost
<alyssa>
OK, I read the Bifrost docs.
<alyssa>
I'd rather like to see some sample disasms..
<HdkR>
Lemme finish my dinner
<anarsoul>
alyssa: are you working on bifrost now?
<alyssa>
anarsoul: No, but I am opening the flood gates for Bifrost code to hit upstream, which means I need to understand it myself (since I'm the maintainer..)
<alyssa>
I could pass off maintainership duties for bifrost/ to someone else, but that's lazy :P
<anarsoul>
:)
<HdkR>
I can't call myself a maintainer runtil I show that I can actually spend my 10 hours/week on it :P
<alyssa>
Oh, I'm failing scissor stuff. Let's debug that first.
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
<alyssa>
...Eek, hm, k
<HdkR>
There we go. Basic IR being emitted again
<HdkR>
Still five more hours of work to go
<alyssa>
:)
<HdkR>
Goes to show how much work can be done with just a few hours of effort a week :P
<alyssa>
:)
<chewitt>
HdkR: alyssa: the Odroid N2 (Amlogic g12b) has reasonable mainline support already as it inherits heavily from the Amlogic g12a platform that @narmstrong is working heavily on
<chewitt>
and sourcing hardware for people is simple to arrange
<HdkR>
chewitt: I have a couple N2 boards. Is it capable of running a kernel greater tha the 4.9 provided by HK?
<chewitt>
I'm running 5.1-rc1 at the moment
<HdkR>
=O
<HdkR>
So what's broken on 5.1-rc1? :P
<HdkR>
Also. I'll do the rest of my weekly 5hours later this week. Need to create a power supply box
<chewitt>
hdmi audio and the v4l2 vdec are missing .. and then tertiary stuff related to 10-bit hdmi and smaller peripheral stuff
<chewitt>
but from a panfrost perspective all the essentials are there
<HdkR>
emmc and ethernet works fine?
<chewitt>
so far .. but not tested heavily from our side
<HdkR>
Well then, that sounds like an ideal board then
<chewitt>
I think so, and there are blobs available that work with the current r16p0 mali_kbase driver, so comparisons for RE purposes are possible
<HdkR>
aye, it is what I'm using for snagging traces even
<alyssa>
Scissors are wat
kszaq has joined #panfrost
<alyssa>
Oh, fun, I'm dealing with the interactions between parts of the hardware that are normally driver invisible
<alyssa>
I knew this bug would be o_o but I didn't realise it would be O_O
<bbrezillon>
ok, I think I get it, it's supposed to address the problem fixed by "panfrost: Fix ->set_vertex_buffers() for partial vertex bufs updates"
yann has quit [Ping timeout: 255 seconds]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
pH5 has quit [Quit: bye]
<kszaq>
robher: Re 64/32 bit - my knowledge is really basic on the topic but I encountered the bitness issue: when I compiled mesa for arm userspace (32-bit), the only thing I got was DATA_INVALID from kernel driver. I implemented an ugly workaround for this: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/650
<kszaq>
Basically if I force structs to contain 64-bit pointers, everything runs smoothly.
<kszaq>
I believe that MoeIcenowy had the issue the other way round: he got DATA_INVALID when talking to T720 from aarch64 userspace. I don't know if my workaround helped him.
raster has joined #panfrost
<kszaq>
robher: Since you plan to look into 32/64, I will probably drop the MR.
yann has joined #panfrost
BenG83 has quit [Ping timeout: 255 seconds]
<narmstrong>
HdkR: cpu dvfs, hdmi audio, advanced graphics stuff (afbc, 10bit, hdr...) are missing, but ethernet, usb and hdmi support is stable and should hopefully be for 5.2, or at least 5.3
<narmstrong>
But N2 support is only a few patches away from mainline (only DT)
<HdkR>
Yea, seems like N2 is the best choice
<HdkR>
So that'll continue being my primary target :P
<janrinze>
HdkR: There is a mainline kernel 5.1-rc1 that i tested. It has no DRM yet, just serial console and disk.
<narmstrong>
HdkR: I maintain stable branches for amlogic boards, and I share them with @chewitt and Armbian guys
<narmstrong>
janrinze: ???
<janrinze>
HdkR: Mani is doing the heavy lifting of porting to mainline linux for Hikey 970
<janrinze>
narmstrong: was a reply to some question a while back from HdkR
<narmstrong>
janrinze: ok
<narmstrong>
janrinze: seems the 970 full mainline support is still pretty far away, no ?
<janrinze>
narmstrong: the branch hikey970_pcie is what Mani is working on a.t.m.
<janrinze>
narmstrong: he said he wants to do DRM/HDMI after that
<HdkR>
Nice thing is the N2 is a heck of a lot cheaper than the Hikey boards :P
<janrinze>
HdkR: not if you already bought a Hikey970 ;-p
<HdkR>
I have them all, so it's all good :)
<janrinze>
HdkR: I'm sure you do :D
<raster>
gotta catch 'em all
<janrinze>
HdkR: got a beagleboard? (rev 1?)
<raster>
that still runs?
<HdkR>
lol no
<raster>
mins was destroyed by my cat
<janrinze>
raster: yup
<HdkR>
Had a pandaboard though
<raster>
oh lucky you!
<raster>
jam mainline kernel? :)
<janrinze>
Panda still runs here too
<janrinze>
HdkR: you can build a working kernel for Hikey970 from the kernel tree of mani using the hikey970_pcie branch. Does the panfrost driver require a mali kernel driver from ARM?
<suihkulokki>
He is mani_s on irc, I poked him to come here
<janrinze>
suihkulokki: he is quite busy so i was just asking around for some info that could be of help later.
<raster>
janrinze: current mesa requires the proposed panfrost kernel driver. doesn't work with mali kbase anymore
sleepymario has joined #panfrost
<sleepymario>
hello. how's progress on the panfrost drivers going? Are they somewhat useable on an Asus Tinkerboard yet? (Mali-T764)
<raster>
no idea of that specific board
<raster>
but at this point i would nto say they are usable
<raster>
on gpu's i know they work on (i test on the t860 on the rk3399)
<raster>
fbo's are badly broken (mostly don't work)
<sleepymario>
okay
<sleepymario>
it's an rk3288 fwiw
<raster>
and buffer age is also totally broken, breaking a lot of uses (wayland compositors for example and any apps doing 2d rendering via gl)
<sleepymario>
hm that doesn't sound ready indeed
<sleepymario>
all right i'll just stay patient
<raster>
not ready yet
<raster>
if buffer ag was disabled and fbo's were to work properly it'd be gettting close imho
<sleepymario>
okay, well that's promising.
<raster>
a lot of the other things are working
<raster>
there are hiccups like hangs with gpu timeouts and resetting at times
<raster>
but then it's a lot of smaller things
<sleepymario>
well if you guys ever need someone to test it on a rk3288, gimme a shout. i'm not rich enough to donate one, but i got one lying around here.
<raster>
you can try
<raster>
i am mostly using glmark and efl, enlightenment and weston to test
<sleepymario>
well why not. i'll give it a shot then.
<raster>
enlighenment used to work a lot better before and things have regressed
<raster>
to the point i could run apps and actually see a screen that mostly looked right
<raster>
fbo's were still not working but you'd know when they were used (screen would blank)
<raster>
and buffer age was disabled then
<raster>
now eston works
<raster>
but e doesnt
<raster>
big black screen
<raster>
i am suspecting it might be fbo related
<sleepymario>
i see
<raster>
tho another test that uses fbo's seems to work... but another hand crafgted test using fbo's doesnt
<raster>
its kind of iffy in some special cases they work
<raster>
and are glitchy then
<raster>
i havent figured out why exactly yet
<sleepymario>
raster: what OS are you using? I was having problems with installing wayland because of kernel versions.
<raster>
unsip it and use that as a starter config for that kerne;
<raster>
then make oldconfig
<raster>
and fill in the new things
<raster>
ensure u enable panfrost/mali support
<raster>
:)
<sleepymario>
okay. are the default values okay for the new stuff?
<sleepymario>
panfrost/mali support will be enabled of course :P
<raster>
i made mine modules
<tomeu>
at this point, it may be better to use drm-misc-next or linux-next
<janrinze>
raster: how about dtb? Surely the panfrost driver needs some access to hardware? default DRM too?
<janrinze>
raster: to get G72 working on hikey 970 i suppose a minimal hardware scaffold needs to be in place. There is the DRM drivers for 4.9.78 but i have not been able to merge that yet with the 5.1-rc1 due to many differences in the dtbs/dtsi
<bbrezillon>
have you done the same thing for MFBD?
<raster>
janrinze: oh yeah - the mainline tdb is broken badly
<raster>
janrinze: i basically stole the dtb from one of ayufan's trees
<raster>
then modified it to ad the voltage to the gpu then got it working with both gpu and everythng else
<raster>
janrinze: i can share that if u want. i'm chasing ayufan to see why he hasn't pushed patches to mainline
<raster>
bbrezillon: yeah. buffer age is indeed broken right now. like that bug report u point to. driver should not clear unless explicitly told to clear via gl api. this means buffer age query is then invalid if it does and thus should not report a sane buffer age to stop apps from partial-rendering
<tomeu>
davidlt: thanks!
<bbrezillon>
raster: actually, I'd like to avoid this clear instead of reporting a buffer age of 0 :)
<raster>
bbrezillon: sure - tho right now clearing AND reporting a valid buffer age is... bad :)
<bbrezillon>
yep, definitely
<raster>
the clear AND "wallpaper the tile" is the right solution
<tomeu>
raster: what's this wallpaper thing?
<tomeu>
keep hearing about it but I haven't made a clear idea of what is this about
<raster>
tomeu: fill the tile with backbuffer content before rendering if no clear has been issued
<raster>
there's code in panfrost to do this
<raster>
i found the "wallpaper" function myself and wondered what it is
<raster>
figured it out after that
<raster>
normally wallpapering isn't "done"
<raster>
most 3d rendering ALWAYS involves a clear first
<raster>
and then u re-render everything
<raster>
so tiled rendering hw has an optimization for that
<raster>
a tile update can "self-zero" its own tile memory without actively doing the work
<raster>
so when a tile renders u just init it and its always cleared to 0 (the common clear color and z value) for "zero cost"
<raster>
then begin rendering
<raster>
for 2d tho - we hate doing this
<raster>
so since we know which regions update and which dont we like to only render those
<raster>
the problem is this requires not clearing and then assuming buffer content was the same as N frames ago
<raster>
when a tile has to re-render the optimal thing to do is "wallpaper" the regions u will not re-render. this is invisible to the gl api user - they dont know this, so the driver has to doit
<raster>
from the gl api level we dont know its a tiled renderer and if it says buffer age is 2 then the buffer already contains content from 2 frames ago
<raster>
so we can just render "on top" of that content as we see fit :)
<raster>
so thats what wallpapering is - filling in these tile buffers when you haven't done a clear yet this frame
<bbrezillon>
raster: thanks for this explanation
<bbrezillon>
so, looks like part of the solution is to finish implementing panfrost_draw_wallpaper()
afaerber has quit [Quit: Leaving]
<raster>
bbrezillon: yup. or just debug it to make sure it works every time correctly
<raster>
i know there is an implementation and it tries to work...
<raster>
:)
<bbrezillon>
yep, almost all the code is in an #if 0 section
<bbrezillon>
so not sure when it was tested last
<bbrezillon>
last question, where would you call panfrost_draw_wallpaper() from?
thefloweringash is now known as thefloweringash_
<raster>
well i thnk i remember making it #if 1 and having... issues
<raster>
i think it didnt compile or something
<bbrezillon>
it doesn't compile
<raster>
bbrezillon: and where to call it - i dont rememeber i thought it was called from somewhere
afaerber has joined #panfrost
<bbrezillon>
but that's part of the challenge :)
<raster>
hmm
<raster>
it seems it isnt called at the moment
<bbrezillon>
no, it's not, I'll go look in git history
<raster>
aaah
<raster>
it was removed
<raster>
panfrost_flush()
<raster>
it was called there
<raster>
c351cc4e94410e76ef0512d4bc503ef90adf3370 <- alyssa removed the call to it then
<bbrezillon>
but I'd thought we could call it from panfrost_resource_flush()
<raster>
i remember when i looekd it was being called
<bbrezillon>
ok
<raster>
see that commit that removes it
<raster>
but its logically correct
<raster>
if (!ctx->frame_cleared) {
<raster>
...
<raster>
panfrost_draw_wallpaper()
<raster>
so like described
<raster>
in the evebnt of no clear - fill in wallpaper
<raster>
i suspect the code was restructured at some point ...
<alyssa>
belgin: No, it's MATE themed to look like GNOME3 :p
<belgin>
still wow
<alyssa>
No GPU drivers on this machine, since I need things to stay stable.
<alyssa>
(This is my school computer)
<belgin>
oh i see
<belgin>
did you make that wallpaper? it's cool
<alyssa>
I did! Thank you :)
<belgin>
why would the gpu driver even care about desktop wallpapers? or were you talking about different wallpapers?
<belgin>
perhaps i have a more idealistic view of drivers
<bbrezillon>
belgin: yep, didn't know what wallpapering was before raster explained it
<alyssa>
belgin: Why would a GPU driver care about scissors? :)
<belgin>
oh so it's a different kind of wallpaper
<alyssa>
Yeah :)
<belgin>
i thought you were talking about the wallpaper image on my desktop
<belgin>
although, knowing software, i wouldn't be too surprised to know drivers have special code into them for my lovely nature pictures
<belgin>
nvidia drivers, at least on windows, query a large database of programs from your hdd
<belgin>
upon launch of a graphical program
<belgin>
it could take up to several seconds to start rendering anything thanks to this database query thingy
<belgin>
it's nuts
<bbrezillon>
alyssa: 2nd question was, where should that be called from, and when?
<bbrezillon>
I guess it's related to END_OF_FRAME
<bbrezillon>
so panfrost_submit_frame() is probably the right place
<bbrezillon>
only when flush_immediate is set
<urjaman>
tomeu: does drm-misc-next now have the equivalent of that TLBI quirk thingy?
belgin has quit [Quit: Leaving]
kszaq has joined #panfrost
robher has quit [Changing host]
robher has joined #panfrost
<tomeu>
urjaman: I think so
<janrinze>
raster: do you have a repository for your dtb changes for hikey970?
jernej has joined #panfrost
<raster>
bbrezillon: actually you can make it work for mali gpu's - use scissor clip as an implicit update region and intersect that with the tile - if first render to a tile uses a scissor clip that is a subset of that tile and blend mode is off, then wallpaper the inverse region from the scissor clip ... leave the rest blank because it's going to be filled anyway :)
<alyssa>
bbrezillon: Probably submit_frame area
<alyssa>
It shouldn't matter if flush_immediate is set, though; that's unrelated..?
<bbrezillon>
I thought we'd want to this readback to happen only in that case
<bbrezillon>
s/to//
<alyssa>
bbrezillon: I may have messed it up, but the thought was that flush_immediate would be triggered for glReadPixels()
<alyssa>
So if we're rendering on-screen, we're okay being "a frame late" since that way we get good performance (Midgard expects a deep pipeline to be effective)
<alyssa>
But if we're reading back directly, then we need to flush as soon as we submit, so the results we read back are actually correct (or otherwise we'd fail all CTS testing, etc)
<alyssa>
I admit the scheme smells funny, but AFAIU it's how the blob (and other drivers?) do it..
<alyssa>
Regardless, the readback should happen anytime we do a clear, which is... any time we submit work, thanks to the nature of the FRAGMENT job on a tiler.
<urjaman>
"Load average: 13.37" eheheh
forkbomb has quit [Remote host closed the connection]
forkbomb has joined #panfrost
yann has quit [Ping timeout: 250 seconds]
<Lyude>
janrinze: I have a beagleboard rev1 I think
<Lyude>
not sure how to tell which rev, but since robclark gave it to me and they originally got it from Ti I'd assume so
pH5 has joined #panfrost
<robclark>
Lyude: beagleboard or beaglebone (the smaller one)? I think some (but maybe not all) of the 'bones I had were a later revision (where they added the hdmi bridge)
<Lyude>
oh yeah, this one definitely has an hdmi bridge
<janrinze>
Lyude: the beagleboards rev.1 had hardware issues with the usb-otg
<urjaman>
tomeu: yup seems like it (and yes i rebased it from drm-misc-next to 5.1-rc5 for my c201 kernel)
raster has quit [Remote host closed the connection]
afaerber has quit [Quit: Leaving]
BenG83 has joined #panfrost
afaerber has joined #panfrost
kszaq has quit [Quit: Connection closed for inactivity]