<urjaman>
for GL apps the X extension that's needed is glx (unless you enable mesa to just softrender with xlib) - honestly i dont know too much more about that, except that i've built llvmpipe-only mesa for vnc use sometimes because some X vnc server didnt the glx extension (i think there is now one that does have it... not sure forgot)
<urjaman>
*didnt have...
<Lyude>
glx is kind of like egl in that it's more geared towards getting an OpenGL context setup with the X server, it doesn't really need special hw support
<Lyude>
(although that will soon be possible for drivers that choose so iirc)
cwabbott has quit [Ping timeout: 252 seconds]
* alyssa
blinks
<Lyude>
alyssa: a context being "where do I render to, what drivers do I use, etc"
* alyssa
blinks
<Lyude>
alyssa: so, the OpenGL specification doesn't really cover anything but rendering images, which means it doesn't define how to actually take those rendered images and display them onto the screen. That's usually the job of whatever platform you're using. Windows uses wgl for this, X uses glx for this, wayland can use egl for this (among other methods), android has it's own platform for doing this, etc.
<HdkR>
Android = EGL with surfaceflinger operating in the background ;)
<Lyude>
mhm
<HdkR>
But yea, GL itself doesn't know anything beyond framebuffer 0 being special and is unmanaged by its API
stikonas has quit [Remote host closed the connection]
<HdkR>
Today, back to the compiler
stikonas has joined #panfrost
BenG83 has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
NeuroScr has quit [Read error: Connection reset by peer]
NeuroScr has joined #panfrost
hanetzer has quit [Ping timeout: 268 seconds]
_whitelogger has joined #panfrost
raster has joined #panfrost
raster has quit [Remote host closed the connection]
AntonioND has quit [Quit: Quit]
<Lyude>
hooray, my home has heating again
<HdkR>
I imagine blankets were your close friend
<Lyude>
yes
<cwabbott>
alyssa: I was looking into cross-compiling the panwrap in mesa for android
<Lyude>
cwabbott: jfyi
<cwabbott>
I couldn't get it to work
<Lyude>
I want to put peridot (the bifrost system on my server) onto something with a mainline kernel
NeuroScr has quit [Ping timeout: 250 seconds]
<Lyude>
if you would rather me just do that first once my office is warmer
NeuroScr_ has joined #panfrost
<Lyude>
*home office
<cwabbott>
Lyude: that sounds like a good idea... android is a pain
<Lyude>
Yep lol :P
<cwabbott>
also, it would be cool to get a system with opencl binaries
<HdkR>
Bifrost or Midgard?
<cwabbott>
when I was looking into some newer glsl builtins, I managed to activate some super-weird 64-bit mode with different register encodings
<cwabbott>
HdkR: Bifrost
<HdkR>
ah
<Lyude>
cwabbott: ooooo
<Lyude>
Do tell
<cwabbott>
but since GL and Vulkan don't support 64-bit integers...
<cwabbott>
Lyude: I think it was the one that gets you the high 32 bits of a 32x32->64 bit multiplication
<Lyude>
Ah, interesting
<cwabbott>
it seems to do a 64-bit multiplication by setting a magic clause type of 16, which changes all the instruction to 64-bit mode? and the encoding for the register part of the instruction is totally different
<Lyude>
Oh weird
<cwabbott>
it did an IMUL.i32, but all the source/dest registers were obviously wrong
<cwabbott>
and it was using an unknown reg ctrl
<Lyude>
!!!
<Lyude>
Nice
<cwabbott>
I remember seeing somewhere in a patent, it was mentioned offhand that the 32 vs. 64-bit distinction is per-clause
<cwabbott>
and sure enough, that multiply was all by itself in a clause
<cwabbott>
the thing is, figuring out this stuff was super-fiddly in the first place
<cwabbott>
I mean, figuring out the reg ctrl stuff was super-fiddly
<cwabbott>
but I have even less control over it now, with only one instruction to provoke it
<cwabbott>
*one way to provoke it
<cwabbott>
for example, I can't make it read 3 registers at a time
<cwabbott>
but maybe with their opencl blob, which has 64-bit integer support, I could do it
<HdkR>
I assume they don't use this for SSBO address generation?
<cwabbott>
HdkR: in the usual cases, no
<cwabbott>
there's a special pair of instructions to do a 64-bit add with a small shift on one of the operands, even in 32-bit mode
<cwabbott>
it usually uses that
<cwabbott>
maybe I could get it do to the 64-bit instruction with a really large stride or something?
<cwabbott>
Lyude: if you wanna play around with it, imulExtended() and umulExtended() are the builtins
<Lyude>
I'd imagine we should be able to get it to spit opencl code from the binaries for other boards
<Lyude>
cwabbott: in glsl?
<cwabbott>
Lyude: yes
<cwabbott>
right now that's the only reliable way I know of in glsl to get it to do the 64-bit magic thing
<Lyude>
I assume it always generates an independent 64 bit clause as well with just the imul? E.g. code before/after that would just be 32 bit gets put into a different clause than the imul
<cwabbott>
yeah
<Lyude>
(on my phone atm so can't check)
<cwabbott>
hold on, here's what the assembly looks like
<Lyude>
I don't know that the other clause is an entirely different mode per-say, maybe the clause type is controlling the bit width of the output of the clause
<cwabbott>
but look at the registers
<cwabbott>
they're complete and utter garbage
<cwabbott>
nowhere else is R12 used
<Lyude>
Right
<cwabbott>
the only explanation is that there's a different reg ctrl format
<Lyude>
Maybe the reg
<Lyude>
Yeah
<Lyude>
That
<Lyude>
It reminds me of how Intel GPUs do register accesses a bit
<cwabbott>
and that, plus the mention from the patent that it may be per-clause...
<cwabbott>
so, I think clause_3 is basically constructing the arguments to a 64x64->64 multiply
<cwabbott>
R7 is all 0's if R0 is positive and all 1's if R0 is negative
<cwabbott>
then it moves R0 to R6
<cwabbott>
so (R6, R7) is the first argument
<cwabbott>
then (R4, R5) are the second
<cwabbott>
it's basically just doing sign extension
<Lyude>
Oooh
<Lyude>
That makes sense
<cwabbott>
also, IIRC if you make it umulExtended it just replaces the shifts with setting the high register to 0