<Lyude>
I got it ages ago when arm accidentally released a coupon (it was only intended for people at some conference apparently) that brought the price of any AM335x starter kit down from ~$200 to like, $4
<Lyude>
i regret not buying way more then one at the time
<Lyude>
(yes-they did discover their mistake but still honored the coupon!)
<tomeu>
so one would have lots of counters in a timeline, and would be able to see when we miss a frame because rendering being too slow, which units were at 100%
<tomeu>
a bit out of scope, though :p
<alyssa>
:P
pH5 has quit [Quit: bye]
<gtucker>
fwiw the counters exposed via gator are primarily used by the DS-5 Streamline tool
<raster>
odd that the colors of icosn at the bottom are messed up. i smell something about state changes messing up like switching shaders messes up because icons at the top are ok (they will be rendered before thats at the bottom due to stacking)
<raster>
i did ask too much though. compositor trying to be its own wl client via wayland-egl etc. falls apart on panfrost :)
<raster>
ggive me some mins - my desktop is doing odd things...
<tomeu>
raster: I'm assuming not all fixes are GL-specific
raster has quit [Remote host closed the connection]
raster has joined #panfrost
belgin has joined #panfrost
<raster>
tomeu: i merged those 2 branches - rendering is still just as broken as before. :|
<raster>
lets see if the out of memory errors happen though
<raster>
so far - not
<tomeu>
ah yes, she has done some work on that
<tomeu>
ship it!
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<raster>
yeah
<raster>
i suspect the mem overhaul did fix that
<raster>
so thubms up
<raster>
SHIP IT!
<raster>
:)
<raster>
the opengl fixces seem to do nothing so i'm ambivalent on that :)
BenG83 has joined #panfrost
<raster>
ooh glmark gets a lot further now with these
<raster>
nice work alyssa
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
yann has quit [Ping timeout: 250 seconds]
<raster>
hmm
<raster>
glmark doesnt work well ...offscreen
<raster>
with panfrost
<HdkR>
Apparently FBOs are having a hard time atm
belgin has quit [Remote host closed the connection]
<raster>
indeed
<raster>
but hey - WIP. :)
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<alyssa>
gtucker: Sure, but I don't have access to Streamline =P
<gtucker>
I haven't used it in a while, but iirc there's a free version that runs on Linux
<alyssa>
Ashy: A cube! Hooray! :)
<alyssa>
raster: Panfrost can only render to tile granularity, so RTs with widths that aren't multiples of 16 have the stride issue
<alyssa>
Known issue, lemme open an issue on gitlab tho so I don't keep forgetting
<raster>
alyssa: so i have noticed :)
<raster>
resizing the window showed me that :)
<raster>
you noticed the wooden box test in glmark has z problems for the texture coord fetches right?
<alyssa>
Is that the issue? I did notice something was weird, but never could put my eye on why. Thanks for the pointer :)
<alyssa>
Not sure why I pinged Ashy, that was supposed to also be raster
<raster>
yup
<raster>
it is
<raster>
basically its dropping to an affine transform rather than perspective correct. ti;s not dividing by z per texture fetch
<raster>
i can tell the effect from a mile off. i've done my own shortcut software 3d engines that got awesome speed at the expense of avoiding the divide per pixel :)
<raster>
i chose to use more triangles to hide the issue :0
<raster>
:)
<raster>
(and tried to stick to organic content that doesn't have regular sharp lines so its hard to tell) :)
<alyssa>
Cute :p
<raster>
so it's definitely that - some divide by z missing in a shader output somewhere :)
<raster>
i havent done internal driver work before - but i've built the sw engines before and used gl enough to guess whats up :)
<raster>
i'll help out
<alyssa>
:tada:
<raster>
:)
<alyssa>
raster: "the opengl fixces seem to do nothing so i'm ambivalent on that" FWIW, those were specifically for desktop apps and don't matter too much on embedded (except for indexed draws which work better now)
<raster>
yeah
<raster>
i hoped maybe by luck they fixed something
<raster>
they didnt
<raster>
:(
<alyssa>
:(
<alyssa>
HdkR: FBOs are indeed a major painpoint right now, for a lot of reasons
<raster>
i still have lots of flickering of buffers and seird jumbled messes in pixels - looks like on what i'd guess isa gpu tile boundary
<raster>
like texture swizzle tile (8x8? 16x16?)
<alyssa>
Hm?
<raster>
i need screenshots that demo it well
<alyssa>
(Flickering is a known issue and I'm hoping to get some inspiration soon, since it doesn't necessarily look like cache issues like I thought)
<raster>
also we use buffer age extn - not even sure if panfrost exposes that yet
<raster>
didnt look yet
<alyssa>
tomeu: ^^
<raster>
but that'd maybe cause issues where we try to partial update
* alyssa
poofs for clas
<alyssa>
*class
<raster>
we have rounded out update regions to 16x16 tiles .. due to.. historical input and suggestions from ... various closed binary gpu driver vendors :)
<Lyude>
:P
<Lyude>
wait what
<Lyude>
oh-I guess I must have had ":P\n" typed into mosh when I connected to my bouncer
<Lyude>
whoops
<raster>
hahahaha
<HdkR>
16x16 is a good working size :)
<raster>
funny that that was typed there...
<raster>
one of these days i need to make my sw renderer with tiled layout for pixels
<raster>
i need some way to make 256 cores do something good for me
<HdkR>
16x16 is sort of the sweet point for utilizing all the hardware + small enough for things like cross-tile conflicts to not be too much of an issue
<HdkR>
fragment shader interlock sort of situations
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<raster>
well i like 16x16 as at 32bpp thats exactly 1kb :)
<raster>
1 row in 16x16 is 1 cacheline (generally)
<HdkR>
That works as well
<raster>
so its a nice setup
<raster>
i have always wanted to make a cpu side tiled renderer like gpu's do
<raster>
as scanline has issues with all the scaling i end up doing these days
<HdkR>
I was planning on making one a few years ago then got sidetracked
<HdkR>
Too much compiler fun to be had
<raster>
hehehehe
<raster>
well for me i get to work on a subset for 2d rendering
<raster>
i dont have to conform to gl etc.
<raster>
so i et a bit more freedom to make it fast
raster has quit [Remote host closed the connection]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
stikonas has joined #panfrost
anarsoul|2 has joined #panfrost
pH5 has quit [Quit: bye]
Prf_Jakob has joined #panfrost
afaerber has quit [Quit: Leaving]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
pH5 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
BenG83 has quit [Quit: Leaving]
BenG83 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
NeuroScr_ has joined #panfrost
NeuroScr has quit [Ping timeout: 258 seconds]
NeuroScr_ is now known as NeuroScr
AntonioND has joined #panfrost
afaerber has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
<HdkR>
TIL that SPIR-V has native support for int64.
<HdkR>
No extensions or feature levels. It's just there in core
<HdkR>
Magical
<bnieuwen1uizen>
HdkR: you sure?
<bnieuwen1uizen>
vulkan has a int64 feature bit
<bnieuwen1uizen>
(Int64 is a capability that is optional)
AntonioND has quit [Quit: Quit]
<HdkR>
Interesting. I was just grepping the latest spirv spec and it didn't claim to require a feature
<HdkR>
Oh!
<HdkR>
It was part of the capabilities section, derp
<bnieuwen1uizen>
yeah, SPIR-V spec is incomplete in many ways
<bnieuwen1uizen>
like explaining that you need a cap to do something, even when you look at the cap it can have no other purpose :P
<HdkR>
Oh hey, I've seen that
<HdkR>
reminds me of image_load_formatted on the GLSL side is about the same
<HdkR>
`#extension GL_EXT_shader_image_load_formatted : enable` in the shader just changing behaviour. Might as well as be a pragma