<alyssa>
From the errata list (in the kernel -- older versions had comments the new kbase doesn't):
<alyssa>
"Occlusion queries can create false 0 reulst in boolean and counter modes"
<alyssa>
Read: there is a counter mode
<alyssa>
HdkR: ^^
<Lyude>
alyssa: wait I thought we couldn't even do occlusion queries
<alyssa>
Lyude: I landed support for boolean occlusion queries sometime last month
<Lyude>
oooo o:
<alyssa>
Nothing too hard tbh
<alyssa>
I mean
<alyssa>
As far as the arch goes it's not too hard
<alyssa>
The hard part is scheduling flushes and all that; the current implementation is wrong for all but the simplest cases
<HdkR>
ES 3.0 has boolean occlusion query support :P
<HdkR>
alyssa: I presume counter mode means precise occlusion queries
<HdkR>
Sadly Nvidia has had an ES extension for this for a long time but the spec page was never made public. `GL_NV_occlusion_query_samples`
<alyssa>
HdkR: Yeah
<alyssa>
I suspect I know how to switch modes, just trying to recreate my test app lol
<alyssa>
Nope, not that bit ^_^
* alyssa
is totally not just trying random bits :v
<alyssa>
It worked for GL_QUADS..
<alyssa>
Got it
<alyssa>
...Maybe
<alyssa>
Not very precise if so
<HdkR>
Oh? how is it not very precise?
<alyssa>
Massive variance in read back results
<alyssa>
Although it's possible I have a race condition
<HdkR>
I'd guess a race. Occlusion queries are supposed to give fairly precise results
<alyssa>
Mm
<alyssa>
Sent off a patchset to the list to do precise queries. Untested since I don't want to futz with desktop right now but it shouldn't regress anything and this way I won't forget about it ;)
<HdkR>
:D
<alyssa>
Not sure what I want to do next
* alyssa
debates compiling Kodi on her Veyron
<alyssa>
It could make a fun media center ;P
<robher>
alyssa: It's been years and freedreno still doesn't do CL (mainly just low priority I think), so I'm not expecting that to happen soon. I'm basically looking at the pretty fixed command submission you use and worrying about supporting just that for now. Obviously, I expect that to expand and we'll need it too before we nail down the kernel ABI.
<alyssa>
robher: Freedreno does do GLES compute shaders, though
<robclark>
cl is a million paper cuts of all of a sudden 16b and 8b thins matter
<alyssa>
And that's fair, although obviously command submission will expand sooner than later (it's already questionable for anything involving FBOs, which I should probably be fixing)
<alyssa>
robclark: Ohai, do you just get beeped whenever someone says freedreno? ;P
<robclark>
heheh, no I was just checking in before sleep :-P
<alyssa>
Ah
* alyssa
wasn't aware robclark read scrollback in here at all
* robher
gets pinged for Herring which is usually due to "red herring".
<robclark>
but tl;dr; I wouldn't hold things up on cl.. there is obvs a bunch of details but, well, they are details
* alyssa
gets pinged for alyssa which is usually due to "Alyssa talks about herself in third-party way too much; she's kind of making me uncomfortable"
<alyssa>
*person
<robher>
So do GLES compute shaders use JS2? How long til those are supported?
<alyssa>
Not sure
<alyssa>
I try to focus on GLES2.0, gles compute is in ES#
<HdkR>
JS2?
<alyssa>
HdkR: Job slot #2
<alyssa>
Only for compute
<HdkR>
ah
<alyssa>
Gah, I can't for the life of me replicate ezequielg's kmscube -V setup
* alyssa
just did some memory leak stuff
<alyssa>
Still a very serious memory leak in sway
<alyssa>
Easiest way to demonstrate is to open and close weston-terminal repeatedlyt
<alyssa>
Wonder if Weston has the same issue
<alyssa>
Weston also has a leak caused by starting/closing a lot of terminals, but its usage creeps up at like one-tenth speed as sway...
<HdkR>
Woo leak investigation :)
<alyssa>
"stub: Tried to free slab"
<alyssa>
This just got interesting
<alyssa>
"leaking 33554432 bytes" This just got interesting, didn't it
<tomeu>
alyssa: awesome, will be adding a backend callback to find out GPU version and implementing it in the DRM backend
<alyssa>
tomeu: Cool :)
<tomeu>
guess for the non-drm one, it can be hardcoded
<alyssa>
Nah, I can implement the GET_VERSION syscall
<alyssa>
Er
<alyssa>
GPUPROPS
<tomeu>
ah, saw it was hardcoded in the patch you pasted above and thought you were fine with that for now :)
<alyssa>
tomeu: I mean, for a tiny moment in time it's fine ;)
<alyssa>
Any idea how to free a SAME_VA region on mali_kbase?
<alyssa>
It says "SAME_VA must be freed through munmap"
<tomeu>
alyssa: btw, do you happen to know how close we are of running gnome-shell as well as weston?
<alyssa>
tomeu: :+1:
<alyssa>
Ehh, I haven't test g-s in a little while. Last time, it was showing some output but severe visual corruption and I wasn't sure specifically how to debug
<alyssa>
It's desktop GL which is.. harder
<alyssa>
FWIW, I'm *really* uncomfortable with these PAN_GPU_ID_MALI_T760 / PANFROST_PARAM_GPU_ID_MALI_T860 defines
<alyssa>
There's an official GPU ID numbering scheme which, afaik, is backed by the hw registers
<alyssa>
We should be following that unless we have a reason to do otherwise, no?
<ezequielg>
alyssa: lol
<ezequielg>
alyssa: what is my setup you are trying to reproduce?
<alyssa>
ezequielg: I saw you had
<alyssa>
kmscube -V something
<alyssa>
working (for the Bunny film cube thing on Twitter?)
<alyssa>
No matter what video I pass, it either fails due to IYUV not being supported, or it blackscreens with errors from gstreamer on the console
<robher>
alyssa, tomeu: perhaps we don't want to expose any GPU ID, but rather just lists of features/bugs. A given GPU is just a collection of certain features and bugs. Using those is mostly what the vendor driver seems to do to handle differences. Plus the bifrost IDs don't seem to match the marketing names.
<robher>
A lot of the places in the code I've found working around bugs are only for early T604 versions. I hope we don't have to care about them, but I'm guessing the exynos 5250 in the chromebook has an early version. Hopefully no one cares about it (I still have one).
<Lyude>
I've still got one as well
<cwabbott>
robher: From what I understand, the other open-source drivers list features and bugs mostly in userspace
<cwabbott>
ARM develops both drivers in the same tree so they're not affected, but I imagine it would be more of a pain if adding some workaround were a matter of updating both the kernel and userspace
<robher>
Lyude: do you run mainline kernels on it? There didn't seem to be much of that in my quick search. Getting a dump of the mali ID registers would be useful.
afaerber has quit [Quit: Leaving]
<Lyude>
robher: not yet, I'm in the process of trying to get all of my arm machines running fedora
<Lyude>
although the chromebook is probably going to be one of the last ones
<robher>
I know there was some interest early and it was one of the first platforms that could do KVM.
<Lyude>
I'm assuming you guys saw the more detailed specs that the kernel can give out that aren't just model numbers correct?
<robher>
alyssa: no, but who is going to backport a drm driver to 3.ancient kernel?
<robher>
Personally, I don't care if snow is supported or not. I'm not going to mess with it. But if someone wants to figure out what it has that would be useful to know for when I'm ripping out code from the kbase driver.
<alyssa>
robher: That's fair, yeah
<alyssa>
RK3288, RK3399, and S912 are the 3 midgard targets I'm personally interested in (T760, T860, and T820 respectively) so
BenG83 has joined #panfrost
<memeka>
I can run mainline on
<memeka>
Xu4
<memeka>
Also run kvm on it
<alyssa>
Tasty
<alyssa>
I wonder what Panfrost hw is most usable right now
<alyssa>
(on mainline, no blobs)
<alyssa>
I guess RK3288 probably
<alyssa>
ezequielg: Recreated your setup, nice :)
<alyssa>
..Slow, tho. Guess that's the price I pay for sw csc
<alyssa>
Still cool :p
<alyssa>
I bet the sway leak has to do with freeing imported bo's..?
<ezequielg>
you got the leak and then eventually BOOM! ?
<alyssa>
ezequielg: Hm?
afaerber has joined #panfrost
<alyssa>
ezequielg: Pretty sure I fixed the leak in question
Elpaulo has quit [Quit: Elpaulo]
<ezequielg>
interesting
<alyssa>
(That's why I asked how to get it workkng so I could test)