<alyssa>
It looks like it's actually kinda trivial to implement
<alyssa>
Gallium gives us the streamout format requirements, and we just use that as the formatting requirements for varyings/varying_meta
<alyssa>
(Normally those are arbitrary, now we have something specific to set)
<alyssa>
And then ofc we use the stream out BO instead of the transitive BO for the varyings memory itself
<alyssa>
And.... that's it, I think.
<alyssa>
shadeslayer: Just landed your index bias patch, thank you!
vstehle has quit [Ping timeout: 272 seconds]
megi has quit [Ping timeout: 248 seconds]
NeuroScr has quit [Quit: NeuroScr]
vstehle has joined #panfrost
<tomeu>
alyssa: yay!
<tomeu>
shadeslayer: another yay!
rcf has quit [Ping timeout: 245 seconds]
megi has joined #panfrost
anarsoul|c has joined #panfrost
rcf has joined #panfrost
rcf has quit [Ping timeout: 272 seconds]
rcf1 has joined #panfrost
rcf1 is now known as rcf
pH5 has joined #panfrost
anarsoul|c has quit [Quit: Connection closed for inactivity]
raster has joined #panfrost
<shadeslayer>
alyssa: thanks!
raster has quit [Remote host closed the connection]
<wens>
I see chrome was blacklisted :(
raster has joined #panfrost
<HdkR>
For good reason until Panfrost gets good enough to support it
<HdkR>
Don't want another Nouveau situation
<EmilKarlson>
yes, blacklisting is critical for avoiding regressions
<EmilKarlson>
it's not like people would not notice chromium not working
davidlt has joined #panfrost
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 272 seconds]
davidlt__ has joined #panfrost
davidlt_ has quit [Ping timeout: 258 seconds]
davidlt__ has quit [Ping timeout: 245 seconds]
davidlt has joined #panfrost
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 268 seconds]
<raster>
hooray. hdmi unbroke... just about when i had bisected to the kernel commit that broke it... someone found and fixed it.
<raster>
aaaah mesa segv. nice
<raster>
lock_front_buffer() is unhappy... surf->dri_private is NULL
<tomeu>
raster: I think that SIGSEGV is hit on some rarely-frequented error path
<tomeu>
so you may want to see what went wrong before then
<raster>
i get this at startup
<raster>
so i need to dig...
<tomeu>
right, something failed to initialize
<raster>
like first frame rendered
<raster>
oh yeah
<raster>
eglCreateWindowSurface() fails
<raster>
we march on and try anyway... so yeah
<raster>
it sometimes works tho...
adjtm has quit [Ping timeout: 245 seconds]
davidlt_ has quit [Remote host closed the connection]
davidlt_ has joined #panfrost
davidlt_ is now known as davidlt
<raster>
i get EGL_BAD_ALLOC as the error code for that it seems
<raster>
must have tro do with out gbm config
davidlt has quit [Ping timeout: 268 seconds]
indy has quit [Ping timeout: 245 seconds]
afaerber has joined #panfrost
<raster>
oh
<raster>
it's our SECOND call to eglCreatePlatformWindowSurfaceEXT that fails
<raster>
ok
<raster>
we create a 1x1 to start then resize it up to 1920x1080 later once we know what size it should be
adjtm has joined #panfrost
indy has joined #panfrost
<raster>
hmmm still resizing to the same size...
<raster>
ok. yup. panfrost hates a new eglCreateWindowSurface() with a new size on a gbm kms buffer
<raster>
just ends up with BAD_ALLOC
<daniels>
raster: ? you don't pass a size arg to surface create, so not sure what you mean by new size
<daniels>
usually you just destroy and recreate your native buffer
<raster>
thats what we do
<daniels>
also if you get no surface back, not sure how you'd 'march on' to render it?
<daniels>
right, so that doesn't sound like a size thing, just plain alloc failure ...
<raster>
we create with it being 1x1 then once e've figured out what to do we up it to whatever the size should be
<daniels>
maybe CMA area too small?
<raster>
eg 1920x10180
<raster>
err 1080
<raster>
and yeah - we complainw ith an err but keep going :)
<raster>
with no surf as it was during a resize
<raster>
so the engine init worked at 1x1
<raster>
then the resize later failed but nothing higher up expects a resize to fail...
davidlt has joined #panfrost
<raster>
daniels: i just wonder why it works when we just do a single surface only and just create once
<raster>
the mem usage of a 1x1 will not be major so... hmmm
<raster>
need to look into mesa where it's barfing
davidlt_ has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
<daniels>
sounds like just not enough memory to allocate 1920x1080 at all ... we exercise allocation really heavily in all our tests etc
<raster>
oh that does work
<raster>
if i forced it to only create the surface once at 1920x1080 then it works
<raster>
well ok for simple cases... :)
davidlt_ is now known as davidlt
<daniels>
i still don't follow the realloc thing - in both GBM and EGL it's a whole new surface, no?
<raster>
from our end we're resizing an existing canvas from 1x1->1920x1080
<raster>
our stuff higher up is persistent
<raster>
that turns into a "Create surface at 1x1" then "create a new surface at 1920x1080"
<raster>
further down the stack
<raster>
so we eglCreatePlatformWindowSurfaceEXT() 2 times
<raster>
when we do a 2nd one - the 2nd one fails to create
<raster>
thus for us its the mechanics of getting a resize to work :)
<raster>
we start at 1x1 because it's a generic multi-display system target thing where we start with a window where we dont know what the content is yet or sizing policies and so on and so need something to start with then we re-evaluate it later once we know what it'll be
<daniels>
so, creating a window surface doesn't actually allocate ... that's done either upfront by GBM or later when you draw
<tomeu>
raster: got a backtrace?
<tomeu>
and also, make sure you use something recent :)
<raster>
linux-next from yesterday
<raster>
and mesa from todat (master)
<raster>
daniels: correct. the 2nd one fails
<raster>
tomeu: i'm not following the breadcrumbs inside mesa to see what bad allocs :)
<raster>
will see ...
* alyssa
eats bread crumbs
<daniels>
that function is pretty tiny, so to me it looks a lot more like incorrect EGL use than alloc failure tbh
<daniels>
we test a lot of non-simple alloc paths through CTS as well as general use and it does work ...
* alyssa
doesn't see how her current code is possibly function
<alyssa>
Okey this will be a... large... refactor
<alyssa>
But hopefully fix some issues and get us closer to XFB along the way
<alyssa>
daniels: ^^ baby compute? ;p
<alyssa>
Oh gosh this code is so awful
<daniels>
alyssa: woop!
<raster>
well the attrib list and config are pretyt basic/simple
<raster>
the attrib/config are all the same each time just at 1x1 it works :)
<raster>
there is no destination_alpha here so thats never 1
<daniels>
the config definitely matches the native visual of the GBM surface?
<raster>
well it succeeds the first time with everything the same - so it does first time around :)
<raster>
ok
<raster>
_eglNativeSurfaceAlreadyUsed() is unhappy. its true for already used...
<raster>
hmm
<alyssa>
Ugh you know what, I'm just rewriting this routine from scratch.
<raster>
it doesnt like that we didnt delete our old surface yet
<alyssa>
raster: Like me, you use IRC as a twitter replacement? ;p
<raster>
is that a sane thing - to only allow a single eglsurface ?
<raster>
alyssa: heheheheh :)
<daniels>
raster: it's not a single EGLSurfacd
<daniels>
it's that you can only have one EGLSurface at a time for each native surface
<daniels>
which is both required by the spec and sane
<raster>
hmmm this has never failed before. :)
<daniels>
are you leaking handles? that might explain the mystery failures you see
<raster>
on any driver :)
<daniels>
it's Mesa core, not Panfrost
<raster>
works on intel, vc4, amdgpu....
<raster>
well previous releases. is this new?
<raster>
well i'm certainly going to add this del before realloc :)
<daniels>
yeah, you very definitely need to do that - sounds like lifetimes are not quite right
<daniels>
maybe it happens to look like it works in other places thanks to marching on and trying again later?
<raster>
i'm intrigued... why does it work everywhere* except panfrost? (* == everywhere i have tried which is a smattering of driver stacks and mesa versions)
<raster>
all of them mesa stacks too :)
<raster>
anyway... *THIS* is why open source driver stacks are awesome... you can figure out what is going on :)
<alyssa>
Also why oss stacks are annoying
<alyssa>
You have to figure out what's going on ;)
<raster>
yargh!
<raster>
asan is not happy
<raster>
oh dear... someone didnt do 64bit vs 32bit right here...
<raster>
bad programmer...
<raster>
copy & paste bug :)
<alyssa>
raster: That would probably be me
<raster>
nope - not you at all. it was us...
<alyssa>
Probably also me in other bugs
<raster>
in our wl handling code it's used a 64bit hash for wl win id's but... was copy & paste using the xwin 32bit window id still from the x codepath
<alyssa>
raster: Fun fact: I'm single-handedly responsible for the vast majority of bugs in Panfrost :D
<raster>
this isnt you - asan i run on x86 stuff
<raster>
anyway
<raster>
on intel mesa 19.1.2 ...
<raster>
we dont get issues with creating egl window surfaces
<raster>
at all...
<raster>
well well 2 gl wl clients animating at once with panfrost in e
<raster>
nice
<raster>
:)
* raster
hands alyssa an icing covered choc chip cookie
<raster>
glmark time
* alyssa
nibbles cookie
davidlt has quit [Read error: Connection reset by peer]
<raster>
oh thats why
<raster>
we seem to be figureing out its not 1x1 earlier on intel
<raster>
we arent doing the resize
<raster>
thats why it worked
<raster>
oooh
<raster>
hmm ok no wait
<raster>
we do
<raster>
with my simple case
<raster>
but 2nd createsurface succeeds tho on intel
<raster>
maybe because we hadn't swapped a buffer yet on the first one?
<alyssa>
raster: How are glmark results in E?
<raster>
hmmm
<raster>
compared to ....
<raster>
?
<alyssa>
I dunno
<raster>
the only benchmark i have to compare to is offscreen rendering with glmark using mali ddk drivers
<alyssa>
raster: Well, how does that compare? :)
<raster>
so not the same as no compositor involved
<raster>
gimme a min
<raster>
sorry - have a bunch of edits going in a bunch of windows and ssh sessions
<alyssa>
No worries!
<raster>
EXACTLY 1/2 the speed of ddk :) on avg
<raster>
202 v 404 fps :)
<raster>
panfrost only beats ddk on [buffer] tests
<alyssa>
Interesting
<raster>
but again - composited vs offscreen raw to fbo
<alyssa>
What GPU?
<raster>
i think the window in wl vs offscreen are the same dimensions
<raster>
t860
<alyssa>
Interesting
<alyssa>
(Those results are substantially different than what I've been getting for either DDK or us, so)
<raster>
i need to try get this working with ddk again but... not sure i can