<HdkR>
Looks like that extension is unconditionally supplrted in mesa
<cphealy>
When I look at the Panfrost driver, I see that this extension is supported. When I look at the ARM provided Mali driver, I've not found any instances where this extension is supported. Can anyone provide any insight into why the ARM provided Mali driver does not support this and why Panfrost/Mesa does?
<HdkR>
supported*
<HdkR>
Mali blob historically avoids adding features
<macc24>
it's almost like mali blob avoids being actually useful for something other than tracing and rendering chromeos
<cphealy>
haha, got it.
<alyssa>
It can render Android too
<cphealy>
HdkR, macc24: are there other notable examples of features that the Mali driver has avoided adding?
<HdkR>
dual source blending is my goto :P
<macc24>
cphealy: did you just think that i know anything about mali blob beyond "blob bad panfrost good"?
<cphealy>
As I found recently, the ARM Mali driver for Linux/Wayland does not support "EGL_ANDROID_native_fence_sync" while the Android version of the ARM Mali driver does.
<alyssa>
ANDROID
<HdkR>
yea, android
atler has quit [Killed (orwell.freenode.net (Nickname regained by services))]
atler has joined #panfrost
<HdkR>
Pretty sure mesa only exposes one ANDROID extension as a quirk
<macc24>
GL_ANDROID_extension_pack_es31a
<HdkR>
yep
<cphealy>
I thought Panfrost exposed "EGL_ANDROID_native_fence_sync". Am I mistaken?
<HdkR>
Because it was good to support that extension when there wasn't ES 3.2 available...
<HdkR>
Panfrost should end up having it in an Android environment, but not X/Wayland
<cphealy>
So, without "EGL_ANDROID_native_fence_sync", you get the following error and associated change in behaviour: "warning: Disabling explicit synchronization due to missing EGL_KHR_wait_sync extension\n"
<macc24>
yep it's there
<macc24>
on g72
<HdkR>
wants versus has problems I guess
<cphealy>
daniels on #wayland had the following to say about it: "yes, EGL_ANDROID_native_fence_sync is required, because without that we can't get a dma-fence FD to poll on, only an opaque EGLSyncKHR object which we have to constantly query EGL about; those aren't portable between contexts, so we can't pass them between client<->compositor (as well as KMS) either"
<cphealy>
If it's there with Panfrost, we should be fine though and that warning should not show up when starting weston.
<cphealy>
It's just an issue with the blob driver...
<daniels>
Panfrost does expose it, as do all vaguely modern Mesa drivers
* alyssa
thinks we're a CAP short
<alyssa>
Passed: 34/36 (94.4%)
<alyssa>
that's totally good enough right???
<macc24>
alyssa: maybe try again and it will fix itself?
<alyssa>
:p
<macc24>
oh, and gnome is more usable on duet when gpu is set too 800mhz
<macc24>
therefore it will fix itself and there will be some actual user interface that is tablet friendly :D
<alyssa>
sway is tablet friendly
<alyssa>
just picky about its friends
* macc24
notices number of loc changed in panfrost after git pull
<alyssa>
?
<macc24>
i sure hope that there are no regressions
<alyssa>
thanks for volunteering to debug
<macc24>
uhhh
<macc24>
did bifrost lose gl3.1?
<alyssa>
shouldn't've but maybe accidentally
<macc24>
then it did
<macc24>
nvm was looking at es
<macc24>
woo, chromium works on my chromebook
<alyssa>
icecream95: re tiler faults, wonder if sharing the tiler heap across batches is the problem
<alyssa>
if the tiler heap needs to be preserved for the fragment job, that's racey
<icecream95>
alyssa: The faults happen even with PAN_MESA_DEBUG=sync
<anarsoul>
alyssa: again, not sure if it's relevant for midgard/bifrost, but we have to preserve tiler heap for fragment job on utgard
karolherbst has quit [Ping timeout: 272 seconds]
<alyssa>
:V
<alyssa>
icecream95: bifrost only or also midg?
<alyssa>
bifrost tiler heap start/free/end ptr management is hard to understand for me, maybe it's broken
<alyssa>
bbrezillon: ^^
<anarsoul>
alyssa: do you have debug flag to serialize jobs?
<anarsoul>
if yes, it's worth to try reproducing the bug with this flag set
<anarsoul>
icecream95: ^^
<alyssa>
=sync
kaspter has joined #panfrost
<macc24>
umm
<macc24>
my cursor disappeared
<macc24>
only in "normal mode"
<macc24>
after playing some video games that hide the cursor in chromium
<macc24>
icecream95: can you reproduce this? happened in firefox randomly too
<macc24>
oh god
<macc24>
now i'm seeing something that i thought i'd never see on arm device
archetech has quit [Quit: Konversation terminated!]
davidlt_ has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
chewitt has quit [Quit: Adios!]
vstehle has joined #panfrost
davidlt_ has quit [Ping timeout: 264 seconds]
davidlt has joined #panfrost
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 246 seconds]
daniels has quit [Ping timeout: 260 seconds]
daniels has joined #panfrost
robher has quit [Ping timeout: 260 seconds]
narmstrong has quit [Ping timeout: 260 seconds]
robher has joined #panfrost
narmstrong has joined #panfrost
<bbrezillon>
alyssa: heap.{base,size} are set to the heap BO address and size, and never changed by the GPU, the top/bottom fields are updated by the GPU when it allocates memory from the heap
<bbrezillon>
so I don't think we do something wrong here
<bbrezillon>
sharing the tiler heap is fine, as long as tiler job N+1 doesn't start before fragment job N, which was enforced by icecream95's patch (adding the BO to the batch should create an implicit dependency between the fragment and vertex/tiler job chains)
guillaume_g has joined #panfrost
<bbrezillon>
if we want to make that explicit, we can call panfrost_add_bo(heap_bo, RW | VERTEX_TILER | FRAGMENT), but I doubt it will fix icecream95's issue
<bbrezillon>
icecream95: can you share an apitrace?
<icecream95>
bbrezillon: I've tried making apitraces, but replaying them doesn't reproduce the faults
<bbrezillon>
:-(
camus has joined #panfrost
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
kaspter has quit [Remote host closed the connection]
<bbrezillon>
icecream95: can you share the kernel logs?
<bbrezillon>
icecream95: and 0x3E008080 is near/in the tiler heap?
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
<icecream95>
bbrezillon: It's far above any allocated addresses
<bbrezillon>
icecream95: which job fails (vertex, tiler or fragment)?
<bbrezillon>
js=0, so it's a fragment job
<bbrezillon>
icecream95: do you have a pandecode trace of the failing batch?
<icecream95>
bbrezillon: plasmashell uses multiple render threads, so moving the tiler heap from being per-device to per-context would probably fix the faults
<bbrezillon>
oh
<bbrezillon>
that's indeed a problem I didn't think about
<icecream95>
That would explain why it doesn't reproduce with apitrace
<bbrezillon>
well, in theory that shouldn't be a problem
<bbrezillon>
the kernel should do the right thing
<bbrezillon>
we only share the tiler heap BO, not the tiler heap descriptor
<bbrezillon>
right?
<bbrezillon>
I mean, as long as the heap BO is passed to the job submission request, it should force the drm scheduler to serialize jobs using this heap
<bbrezillon>
unless there's a race somewhere...
<icecream95>
bbrezillon: It could be: context 1 writes to tiler_heap, context 2 writes to tiler_heap, context 1 reads from tiler_heap from three different jobs
nlhowell has joined #panfrost
<icecream95>
Making tiler_heap per-context did seem to fix the faults
<icecream95>
bbrezillon: This might be unrelated, but is it supposed to be possible for jobs in different processes to interfere like this? https://gitlab.freedesktop.org/-/snippets/1525
kaspter has quit [Ping timeout: 246 seconds]
<bbrezillon>
icecream95: the MMU should prevent that, but I guess a use-after-free bug could cause that
<bbrezillon>
so, tiler heap is only accessible from the GPU, and jobs accessing the same BO are supposed to be serialized by the kernel driver
<bbrezillon>
but there's indeed a race because vertex/tiler and fragment jobs are issued separately
<bbrezillon>
got it
<bbrezillon>
so tiler_job 1 from context 2 might be sceduled between tiler_job 1 and fragment job 1 from context 1
kaspter has joined #panfrost
<bbrezillon>
icecream95: BTW, I think we should have a panfrost_add_bo(tiler_heap, RW | VERTEX_TILER | FRAGMENT), just to make it clear that we really use the BO from both fragment and vertex/tiler job chains
<robmur01>
amonakov: the reason I'm dismissive of "datasheets?" being repeatedly asked every couple of months is that it's already been said that there is no public documentation, there never will be, and the notion of a nice manual that explains everything doesn't even exist
<robmur01>
the GPU TRMs in the customer documentation do cover the hardware registers, but there's not much more than you can already infer from kbase anyway
<robmur01>
the rest is basically just a mess of internal engineering specs, particularly for Midgard
<robmur01>
Regardless of anything else, Arm simply doesn't have the resources to spend on writing up nice docs for 5+ year old products that are effectively obsolete, just to satisfy the curiosity of a few people on the internet
<phh>
they can just release the source code if it's obsolete ;-)
<robmur01>
if you want to figure things out from source code, you're far better off looking at panfrost ;)
<urjaman>
I thought phh meant midgard in whatever HDL it is written in :P
<phh>
urjaman: correct
<tomeu>
for most humans, guess what robmur01 said still holds true? :p
<macc24>
therefore, the only way to get datasheets is to get a job at arm, steal datasheets and get fired (yes this is a joke)
wwilly has joined #panfrost
<wwilly>
hi, I would like to know if it's possible to use opencl with panfrost? I'm a bit new about all this drivers and mali stuff, I may have silly questions... I'm doing research on scheduling around big.LITTLE (odroid-xu3), my stuff is working pretty well against CFS and EAS for scheduling+DVFS cpu tasks, but I would like to introduce gpu workload, via openCL (for rodinia benchmark) or openGL (for video games). my system is current
<wwilly>
ly "stock" debian 10, with a linux-stable-5.9.y (dirty by my stuff)
<macc24>
icecream95: ^ ?
raster has joined #panfrost
<bbrezillon>
icecream95, alyssa: ok, so I'll have the same problem with the varying mem pool (needed for indirect draws), the question is, should we allocate one per context (max varying mem pool size == 512MB of growable mem) or should we instead add a lock at the dev level to guarantee that vertex/tiler and fragment jobs are not inter-mixed?
thecycoone has quit [Ping timeout: 256 seconds]
thecycoone has joined #panfrost
Ashleee has quit [Ping timeout: 240 seconds]
davidlt_ is now known as davidlt
camus has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
tlwoerner has quit [Ping timeout: 246 seconds]
<alyssa>
macc24: fired? try arrested...
<alyssa>
bbrezillon: It's well established by now I don't know how to write multithreaded graphics code, don't ask me :|
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
<bbrezillon>
alyssa: the question is more, is it okay to have 512M per context, or do we want to mutualize that in the multi-context case
<alyssa>
bbrezillon: 512M GROWABLE per context will hit undebuggable OOMs, I suspect
<bbrezillon>
yeah, that's also what I think
<bbrezillon>
so I guess we can fix both the tiler and varying_mem_pool issue with a lock and keep them per-device
Ashleee has joined #panfrost
zkrx has quit [Ping timeout: 246 seconds]
nlhowell has quit [Ping timeout: 256 seconds]
zkrx has joined #panfrost
nlhowell has joined #panfrost
nlhowell has quit [Remote host closed the connection]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 258 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
* robmur01
ponders why enabling AFBC in Mesa would reduce CPU cache misses/evictions...
<macc24>
am i allowed to complaing about dsi panels being broken here?
<icecream95>
robmur01: When AFBC is enabled, texture uploads are done on the GPU, otherwise they are done on the CPU
<robmur01>
icecream95: aha, that will probably do it indeed
<robmur01>
S922 coherency is the new RK3399 voltage scaling...
<robmur01>
except this time backporting the patches *is* a realistic proposition
<macc24>
robmur01: huh?
<alyssa>
robmur01: rip
kherbst has joined #panfrost
karolherbst has quit [Disconnected by services]
kherbst is now known as karolherbst
<amonakov>
robmur01: if no datasheets, and no ISA manuals, can we at least get text assembly from Mali shader compiler (seeing how it's based on LLVM, so necessary internals should be there already)?
<HdkR>
When writing an LLVM backend you don't actually need to wire up the disassembler bits
<alyssa>
Mesa has that wired up for Bifrost at least
<alyssa>
(compatible with the Mali shader compiler, with more or less 'official' assembly syntax)
<HdkR>
Symbol names from the Mali driver also seems to imply that ARM never hooked up the LLVM disassembly bits
<amonakov>
OTOH libraries shipped with malisc do have instruction names showing up in `strings`
<HdkR>
tablegen will end up doing that
<HdkR>
Gives you all the names for the MIR
<HdkR>
Allows you to do an IR dump late in the pipe and get all the MIR names
<robmur01>
macc24: as in, kernel thing that leads people to keep reporting Mesa bugs, and that we keep forgetting about because it's already sorted in mainline and CI
<robmur01>
amonakov: no idea, you'd have to ask the people responsible for that (although I think I can guess at the answer...) - I'm just an OSS kernel guy ;)
davidlt has quit [Ping timeout: 256 seconds]
<amonakov>
HdkR thanks for the elaboration; yeah, if not full-fledged asm, access to LLVM IR would be nice