<cwabbott>
oh, interesting, I can also get it to do the 64-bit thing if I have a stride big enough
<cwabbott>
so loading/storing to something in an SSBO like ivec4 big[][100]; will trigger it
<cwabbott>
cuz it has to do a 64-bit multiplication of the index and 100*16 to get the byte offset
<Lyude>
What's the asm look like for that?
<cwabbott>
pretty similar
<cwabbott>
a single ope40xx in a clause type 15
<cwabbott>
but I bet I can make it do multiple if both indices are non-constant
<cwabbott>
I only did something like big[i][0]
<cwabbott>
maybe big[i][j] is more interesting...
_whitelogger has joined #panfrost
<alyssa>
hanetzer: Packaged the mainline kernel same way as any other depthcharge armbook
<alyssa>
cwabbott: If you could figure it out, that'd be great so we stop drifting :P
stikonas has quit [Remote host closed the connection]
cwabbott has quit [Remote host closed the connection]
cwabbott has joined #panfrost
_whitelogger has joined #panfrost
<alyssa>
Oh!
<alyssa>
...oh? :/
<Lyude>
Oh?
<alyssa>
Lyude: I'm wondering if the black-rectangles-in-Weston bug is a cache issue
<Lyude>
Could be!
<alyssa>
We're not asking for anything to be cached,
<alyssa>
but we're also not explicitly flushing any caches
<Lyude>
Try flushing? There are ioctls for that iirc
<alyssa>
Mm
* alyssa
blinks
<alyssa>
I've tried disabling all driver parallelism, setting both COHERENT flags, flushing immediately always, and including a sync of the whole framebuffer
<alyssa>
No dice.
<Lyude>
Is it the whole output with black rectangles btw?
<alyssa>
Lyude: No, they some renders right, others are black
<alyssa>
Visually, it would appear to be along tile lines
<Lyude>
Ahh
<alyssa>
Based on past history
<alyssa>
I'm guessing a race condition between tile writeback and framebuffer sync
<alyssa>
But I've tried minimising cache bugs from the latter a million ways now :V
<Lyude>
Huh :S
<alyssa>
Indeed
* alyssa
feels like this is going to be something super dumb
<alyssa>
Great, we're dealing with two different bugs..
<alyssa>
For the main-weston/kodi one anyway
<alyssa>
The missing tiles are _black_
<alyssa>
NOT the clear color
<alyssa>
But they're still getting cleared from last frame
<alyssa>
What?!
<alyssa>
I wonder if this is an FBO issue
<alyssa>
Might be a good time to work on -bdesktop which I recall was broken for FBO reasons as well
* alyssa
wonders if it's time to pay attention to cubemaps / mipmaps
<alyssa>
Hm, cubemaps aren't used here
AntonioND has quit [Quit: Quit]
chewitt has joined #panfrost
chewitt has quit [Quit: Adios!]
<alyssa>
Best use of time is probably working on memory handling stuff
<alyssa>
Chucking cmdstream_persistent (which never gets freed) will go a long way for stability
<hanetzer>
hey friendos :)
* alyssa
waves
<hanetzer>
did I mention I have my kevin now? :D
<alyssa>
You did :)
<alyssa>
"Did I mention I fell in love yet? :D" "17 times"
<hanetzer>
currently booting archlinuxarm on sdcard while working on gentoo on emmc :)
<hanetzer>
I intend to create a coreboot/depthcharge bootable petitboot kernel/initramfs :)
<ezequielg>
alyssa: yuv format on mali?
<ezequielg>
any hints about that?
<alyssa>
ezequielg: Should be there for T760+ (IIRC?), but I don't know the format codes
<alyssa>
Since I don't have a blob capable of running kmscube etc
<ezequielg>
how did you find out the format for the current ones?
<alyssa>
Trying a given OpenGL format for TexImage2D and seeing what format bits pop out
<ezequielg>
right
<alyssa>
But YUV isn't in core GL; you need to do some weird stuff with the EGLImage extension to pipe it through (see kmscube source)
<alyssa>
And I never got around to trying that with the blob
<alyssa>
Oh, apparently all GPUs supported by 'frost support native YUV
<ezequielg>
i've been trying to follow the code to understand what's needed.
<ezequielg>
i mean, aside from a format code
<alyssa>
Not sure
<alyssa>
If YUV images are "normal", then all we need is a format code
<alyssa>
(Normal as in, nothing special compared to RGB)
<alyssa>
We would just add a case to panfrost_find_format translating the Gallium YUV format to the Mali one and be on our way
<alyssa>
If it's something fancier, who knows, I'd have to see a trace
<ezequielg>
right, so we are on the same page.
<ezequielg>
I am wondering if I can't just try and error it :-)
<alyssa>
Hmm
<alyssa>
Admittedly format codes are pretty tiny
<alyssa>
ezequielg: Ready for an adventure? ^_^
<ezequielg>
wha?
<alyssa>
Mali format codes are 8-bit
<ezequielg>
aha
<alyssa>
But it gets better -- we can be pretty sure it'll be a SPECIAL format
<alyssa>
Which means we know the top 3 bits
<alyssa>
Leaving the lower 5-bits to brute force
<ezequielg>
20 minutes tops
<alyssa>
12 of those are already known
<alyssa>
So we're left with 20 to try, theoretically
<ezequielg>
yup
<alyssa>
At least, this will work for the packed YUV formats (where it's a single image with all three planes, not two or three)
<alyssa>
Happy hacking :P
<alyssa>
ezequielg: See the mali_format enum in include/panfrost_job.h
<alyssa>
s/_/-/
<ezequielg>
somehow i bet it'll be 0x4, 0x6 or something
<alyssa>
ezequielg: Nah, there seems to be some natural grouping
<alyssa>
My bet is on 0x1a-0x1d maybe
<alyssa>
If none of this works, it might be in MALI_FORMAT_SPECIAL2, but that may be Bifrost exclusive?
* alyssa
will be impressed if this works :p
<ezequielg>
ok, i will try.
<alyssa>
Best of luck
<ezequielg>
not today. i just came to my office to check my chromiumos build (which of course failed), and now that it's running i'm getting my ass out'a'here.
<alyssa>
Fair enough :P
<ezequielg>
i should have ssh, but that would not be good to my health
* alyssa
pities anyone compiling browsers, let alone BrowserOSes :P
<stikonas>
well, the worst compilation on Gentoo is icu
<alyssa>
Bwa?
<stikonas>
icu itself is quick, but icu ABI breaks force recompilation of all webengine/webkit/libreoffice/firefox/thunderbird
<alyssa>
Dearie
<stikonas>
I think boost is similar, so usually they stabilize boost and icu simultaneously