<Mis012[m]>
presumably it gets confused by my "android device" having non-ES OpenGL, which is somehow not common on android despite Mesa having it on same hw
<Mis012[m]>
not sure if freedreno is 3.2 or 3.3 now
<Mis012[m]>
with 3.3 might hit the same shit
<Mis012[m]>
on one hand it looks like it finds the newest GL supported and appends "es"
<Mis012[m]>
on the other hand, surely they are not that stupid
<Mis012[m]>
seems MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=320 got rid of that issue... so maybe they are that stupid
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
jljusten has quit [Ping timeout: 480 seconds]
<Mis012[m]>
now we have a sigsegv from SwappyGL...? sed
<Mis012[m]>
it should allegedly log this, but seems like the issue might be missing eglPresentationTimeANDROID
Haaninjo has quit [Quit: Ex-Chat]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<Mis012[m]>
does Mesa not have that?
Jeremy_Rand_Talos has joined #dri-devel
jljusten has joined #dri-devel
flto has quit [Quit: Leaving]
<Ristovski>
Mis012[m]: mesa does seem to have EGL_ANDROID_presentation_time, hmm
<alyssa>
Mis012[m]: it's apparently not trivial to get mesa to build GLES without GL :|
<Mis012[m]>
well, I don't mind that :P
<linkmauve>
alyssa, with -Dglx=disabled -Dgles2=enabled -Dgles1=disabled I do get a Mesa which doesn’t support GL I think.
<Mis012[m]>
apps breaking when non-ES GL exists is the issue
<linkmauve>
Programs not supporting GLES is also an issue, even if they could.
<Mis012[m]>
it's only an issue when you're not using Mesa
<linkmauve>
Or linking to libGL.so.1 when they actually should get their symbols from EGL.
<Mis012[m]>
and non-Mesa drivers are sad
<Mis012[m]>
I guess I didn't check it's NULL and not just malformed, but it's probably NULL
<alyssa>
linkmauve: maybe it is that simple? I was told that didn't actually work for a silly reason but maybe I got bad data
<linkmauve>
Mis012[m], well no, I use Mesa everywhere and when I build it with only GLESv2 support many programs are sad, either don’t provide acceleration or crash altogether.
<Mis012[m]>
but why would you not build it with gl
<linkmauve>
alyssa, the weird part is Mesa still installs /usr/include/GL, even if it doesn’t support it.
<alyssa>
linkmauve: thinking
<linkmauve>
Mis012[m], Lima lies when it advertises GL 2.1 support, I’d rather get proper GLES 2.0 everywhere as that’s what the hardware is capable of.
<Mis012[m]>
linking against libGL.so.1 makes total sense, the whole theatre with getSymbol only exists because of windows, it's not even called egldlsym so take a hint
<linkmauve>
Mis012[m], well no, that comes with GLX dependency which means X11 dependency too, I’d rather not have to have that.
<Mis012[m]>
Mesa should just commit to exporting those functions, I don't care where
<Mis012[m]>
linkmauve: I doubt there are actual hw limitations for gl2 vs gles2, at best fw limitations
<linkmauve>
There is no firmware on this GPU AFAIK.
<Mis012[m]>
no way
<Mis012[m]>
probably has it's own bootrom if it's not loaded from elsewhere
<Mis012[m]>
>Note that the Mali GPU is only for rendering: the GPU does not control a display
<Mis012[m]>
sad that this has to be stated
<linkmauve>
Why? This is standard on most ARM platforms.
<Mis012[m]>
it's the literal definition of CPU/GPU
<clever>
the rpi is the same, v3d handles rendering, hvs/pv/hdmi handles the display pipeline
<linkmauve>
Unlike desktop GPUs which do absolutely everything, from render to 2D composition to video decoding to video encoding to display driving.
<Mis012[m]>
only x86 people use those terms incorrectly
<linkmauve>
Guess where the majority of users come from. :p
<clever>
the rpi is a bit more blurry though, its all in one chip, but there are clearly seperated peripherals within it
<Mis012[m]>
desktop GPUs are pretty much SoCs
<clever>
and the 3d rendering part has its own power domain, and can be turned off independantly
<linkmauve>
alyssa, also funny that it installs /usr/include/GLES3/, even if the only enabled driver supports up to ES 2.0. :p
<Mis012[m]>
if AMD designed their SoCs with unified address space like sane people, you could probably run Linux on the PSP core at worst if you don't find some better suited core lurking there
<Mis012[m]>
from security perspective, the PSP can access anything it wants anyway
<Mis012[m]>
just not in a way that's sane
<alyssa>
linkmauve: whoops
<Mis012[m]>
clever: well, I assume rpi has a standard AMBA architecture with multiple masters
<alyssa>
linkmauve: in fairness that'd be difficult to change and i'm not convinced it would make sense to
<clever>
Mis012[m]: yeah, the masters i'm aware of are the vpu, arm, v3d, hvs, vce, isp, dma
<Mis012[m]>
the fun part about rpi is that it's effectively a videocore SoC featuring an arm coprocessor cluster
<clever>
Mis012[m]: and the arm co-processor runs thru a custom mmu before it hits the proper master port
<clever>
so the arm's view of memory can be totally different from the peripherals view
<Mis012[m]>
not sure to what degree that's a matter of fw configuration like with qcom
<clever>
its setup by start.elf on the official firmware
<clever>
you have 64 pages, of 16mb each, controlling the lower 1gig of the addr space
<clever>
on the videocore side, you have 1gig of ram, aliased 4 times, the top 2 bits of the address are cache control flags
<clever>
with some peripherals shadowing ram at 0x7e00_0000
<Mis012[m]>
basically every sus thing with qcom is a matter of sw configuration, just that sw is signed by someone other than the supposed owner and somehow people are fine with that being the norm
<clever>
for the pi0-pi3 lineup, none of the signature checks are enabled
<clever>
so with the right drivers/compiler, you can just replace the firmware and do whatever you want
<Mis012[m]>
pi is a devboard, so it shouldn't have ever been accepted that they are enabled on pi4
<clever>
Mis012[m]: this is demoing the 2d core, the 3d core, and the arm core, all at the same time
<clever>
Mis012[m]: i suspect the pi4 has sig checks enabled because they wanted a checksum, but all the rom had was hmac
<clever>
and why respin the rom to add a weaker validation method?
<clever>
and yeah, turning even the hmac on was a mistake, it led to 2-3 seperate people RE'ing the entire signing chain and cracking it wide open on every model :P
<Mis012[m]>
so where do I download the private key
<clever>
for the pi4, its a symetric signing algo
<Mis012[m]>
wat
<clever>
the validation key, is also the signing key
<clever>
thats why they messed up :P
<Mis012[m]>
I know what symmetric means
<clever>
nobody cared to look, until it got in the way
<clever>
with the proper start4.elf file, you can just dump the keys from your own pi
<clever>
and every pi4 has the same hmac keys
<Mis012[m]>
I guess it's not malicious then, they do give you the key :P
<Mis012[m]>
qcom does security properly
<clever>
but starting with the bcm2711B1T rev i think, they added rsa support to the boot rom
<clever>
there are 4 rsa2048 pubkeys in the boot rom
<clever>
and OTP is used to permanently disable those, and to enable RSA validation
<clever>
from the factory, its still in hmac mode
<Mis012[m]>
interesting
<clever>
the rsa sigs, are part of the RPF custom secure-boot chain
<Mis012[m]>
should still not be assholes and just release the key
<clever>
"low" security, involves putting a user-generated rsa2048 pubkey into the SPI eeprom, and setting SIGNED_BOOT=1 in the SPI eeprom config file
<clever>
the firmware will then expect a boot.img and boot.sig on the boot media, signed by that key
<clever>
boot.img is just a fat32 fs, but in a file, on the SD fat32
<clever>
all further firmware/kernels/config are inside that signed disk image
<clever>
but "low" security can be defeated by just re-flashing the SPI eeprom
<clever>
"high" security, involves burning the sha256 of the urer-generated rsa2048, into OTP, and turning on the RSA validation of the firmware
<clever>
the official bootcode.bin firmware, will then enforce that the pubkey in SPI, matches the hash in OTP
<clever>
so an attacker cant clear or change the pubkey
<Mis012[m]>
bootrom fw is the only stock fw that should stay
<clever>
Mis012[m]: and if they publish the privates for the rom keys, a the bootcode.bin could be maliciously replaced, and defeat the entire chain of trust
<Mis012[m]>
the chain of trust should be verified by bootROM
<Mis012[m]>
agsinst user supplied key
<clever>
it is, but the root of trust is 4 keypairs, burned into the boot rom
<clever>
and 1 keypair is already spent, it was used to sign binaries that dont enforce the chain of trust
<Mis012[m]>
bootrom is mask rom
<clever>
the setup directions explain how to revoke that key
<clever>
yep
<Mis012[m]>
OTP not being called fuses sounds like it's eprom?
<clever>
one time programmable
<clever>
all of the official docs call it OTP, but yeah, its basically just fuses
<Mis012[m]>
qcom uses literal fuses
<Mis012[m]>
other vendors don't say what it is, which makes you assume eprom