ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
yuq825 has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
adjtm_ has quit [Remote host closed the connection]
adjtm has joined #lima
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
adjtm has quit [Quit: Leaving]
adjtm has joined #lima
yuq825 has quit [Remote host closed the connection]
camus1 has joined #lima
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #lima
camus1 has joined #lima
kaspter has quit [Ping timeout: 244 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #lima
buzzmarshall has quit [Remote host closed the connection]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #lima
yuq825 has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
camus1 has joined #lima
camus1 is now known as kaspter
<rellla> would this be sth you had in mind?
<rellla> i temporarily pushed the changes to https://gitlab.freedesktop.org/rellla/mesa/-/commits/lima-opt-indexed-draws_v2 and this branch seems to work as expected now.
<rellla> this is mainly a cleanup with respect to your comments.
mripard has joined #lima
paulk-leonov has quit [Ping timeout: 272 seconds]
paulk-leonov has joined #lima
paulk-leonov has quit [Excess Flood]
paulk-leonov has joined #lima
paulk-leonov has quit [Excess Flood]
paulk-leonov has joined #lima
Viciouss has quit [Ping timeout: 246 seconds]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #lima
Viciouss has joined #lima
cwabbott has quit [Ping timeout: 265 seconds]
cwabbott has joined #lima
<yuq825> rellla: almost there, I think your current changes fixes all the performance loss and should be OK for a performance test now
<rellla> ok, i will --force push them to the original MR and see how we can get reliable benchmarks...
camus1 has joined #lima
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
cwabbott_ has joined #lima
cwabbott has quit [Ping timeout: 260 seconds]
cwabbott_ is now known as cwabbott
dddddd has joined #lima
Viciouss has quit [Ping timeout: 240 seconds]
Viciouss has joined #lima
buzzmarshall has joined #lima
adjtm has quit [Remote host closed the connection]
adjtm has joined #lima
adjtm has quit [Remote host closed the connection]
adjtm has joined #lima
yuq825 has quit [Quit: Leaving.]
<rellla> hi all, not sure if this one https://gitlab.freedesktop.org/rellla/gfx/-/tree/master/gbm-indexed-draw is suitable for a quick hacky benchmark...
<rellla> it shows me a benefit of ~ 1.64 microseconds per single run :/
<enunes> rellla: do you get better results if you scale it more for very large buffers and large deltas (index 1,2,3, then 10000,10001,10002) and accumulated time differences between thousands of runs?
<rellla> enunes: i will give it a try
<rellla> btw, is there any better way to measure this? though, if we have an avarage of many runs and different scalings/ large buffers we should at least see, whats better...
<enunes> I think the arm kernel driver had some performance counters, but we don't have that implemented
<enunes> maybe just 'perf' could help showing where most of the time is spent
paulk-leonov has quit [Excess Flood]
monstr has quit [Remote host closed the connection]
<enunes> rellla: by the way, I tried to compile deqp to run with the blob some days ago and I was not very successful at that. do you still have a working image for the A20? (cubieboard 2?)
<enunes> I ran into many issues with different deqp targets, at the end I remember it kept trying to link with libGL.so or fail because some of the gl functions were not in libGLESv2, even though I tried my best to make it only gles2...
<enunes> my final goal was to test a change enabling some fake shader-db like report for number of instructions, so I could get some comparison data between ppir and the disassembles from the full deqp runs on blob
adjtm_ has joined #lima
adjtm has quit [Ping timeout: 265 seconds]
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #lima
<rellla> enunes: i have. can send it tomorrow
<rellla> it's built for wayland target and uses the wayland/gbm blob
<enunes> rellla: ah, that is helpful too, I never tried that target. well don't even know if the distro I installed has a wayland blob
<rellla> you can get one from me :)
<rellla> it is r7p0 wayland blob.
<rellla> iirc i also built the gbm wrapper
<rellla> should be the kernel driver
<rellla> iirc :)
<rellla> surfaceless target doesn't work with blob btw
<enunes> cool, thanks
<enunes> and you use some debian as base os?
<enunes> I tried surfaceless and some targets for x11
<rellla> a clean debian buster from scratch with own kernel, yes. no armbian.
<enunes> ok that is supposedly what I have too
<enunes> I'll give a try to those blobs
<enunes> I'm also thinking of an alternate solution, which would be a horrible hack on shader-db run.c to initialize a window in some other way than /dev/dri/renderD%d so that it might run on shader files themselves even with the blob
<rellla> after you got deqp build you need a running weston instance started locally
<rellla> then you have to export XDG_RUNTIME_DIR
<rellla> that was a bit tricky for me to find out but lets me rin deqp via ssh now
<enunes> looks like I have a wayland blob but weston doesn't start, maybe I have to find out which net of symlinks end up pointing to one blob or another
<rellla> yeah. thats why i dont have lima and mali and debian-mesa on one machine. its a horror.
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #lima
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #lima
cwabbott has quit [Client Quit]
cwabbott has joined #lima