<macc24>
btw, mediatek marketing has decided on a name for mt8192. "Kompanio 820"
cphealy has joined #panfrost
thecycoone has quit [Ping timeout: 260 seconds]
thecycoone has joined #panfrost
cphealy has quit [Ping timeout: 250 seconds]
davidlt has joined #panfrost
vstehle has joined #panfrost
kaspter has quit [Remote host closed the connection]
camus has joined #panfrost
camus is now known as kaspter
archetech has quit [Quit: Konversation terminated!]
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #panfrost
<chewitt>
somewhere there's a marketing guy sipping a cocktail in self-celebration thinking "yeah, we nailed it!"
guillaume_g has joined #panfrost
<bbrezillon>
icecream95: Re assert(): yes, we should allow src_samples = 1 && dst_samples > 1
<bbrezillon>
icecream95: Re freeze_batch(): I guess we could avoid freezing the batch since the surface attached to the batch key is created in the blit path and nothing can end up re-using the same batch to queue unrelated draws
<bbrezillon>
and yes, glFlush() will not flush those blits, but they should be flushed before the resource is used if we have the proper dep set
<bbrezillon>
given you reported blit ordering issues, we might miss a dep here
<bbrezillon>
icecream95: do you have a trace to share?
cowsay has joined #panfrost
cowsay_ has quit [Ping timeout: 240 seconds]
camus has joined #panfrost
kaspter has quit [Read error: Connection reset by peer]
camus is now known as kaspter
raster has joined #panfrost
rcf has quit [Ping timeout: 265 seconds]
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #panfrost
yann has quit [Remote host closed the connection]
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #panfrost
rcf has joined #panfrost
<bbrezillon>
alyssa, icecream95: ok, so we garbage-collect batch fences too early (before the batch is done), which explains the missing dep
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
catfella has joined #panfrost
robmur01_ is now known as robmur01
rcf has quit [Quit: WeeChat 3.0.1]
rcf has joined #panfrost
rcf1 has joined #panfrost
cphealy has joined #panfrost
rcf is now known as rcf2
rcf1 is now known as rcf
rcf2 has quit [Quit: WeeChat 3.0.1]
<alyssa>
bbrezillon: What's the status for !10423? It looks like there are unresolved threads but also you seem to have good reasons for doing things the way you do and have the acks.
<bbrezillon>
was waiting for a reply from icecream95, I guess
<bbrezillon>
alyssa: oh, and I still don't know if we should keep the first patch
<alyssa>
bbrezillon: I think I agree with daniels that by the time we're in that code path, it's probably too late to do anything.
<bbrezillon>
alyssa: hm, I'll keep it then
<alyssa>
I admit I'm very much not a winsys person
<alyssa>
and trying hard to keep it that way
<alyssa>
speaking of, anyone want to do some macOS winsys work? ;-)
<alyssa>
bbrezillon: panblit breaks glmark2 -bterrain pretty bad, will check if your fixes branch fixes it
camus has joined #panfrost
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
sphalerite has quit [Quit: reeeeebooooooooot]
<bbrezillon>
alyssa: I don't really a difference between panblit and ublit here
<bbrezillon>
how is it broken?
<bbrezillon>
nevermind, I do see it now
<bbrezillon>
and yes, might branch is fixing it
<alyssa>
ack
<alyssa>
-bterrain makes heavy use of per-frame mipmap generation
<alyssa>
which I think panblit could optimize better in the future
<bbrezillon>
I guess we could avoid preloads if we had proper sub-resource state tracking
<alyssa>
hm?
<alyssa>
I mean sticking all the fragment jobs in a single chain with deps between them
<alyssa>
to skip a lot of back and forths with the kernel
<bbrezillon>
ah, no, nm, this is 3D texture issue
<bbrezillon>
oh, that. I thought we had a good reason for not stuffing multiple fragment jobs per submission
<alyssa>
bbrezillon: the good reason was "it'd be hell to do with u_blitter based mipmapping" ;-)
<alyssa>
bbrezillon: rework being the get-rid-of-freezing thing?
<alyssa>
bbrezillon: note: `update_varyings` in indirect_draw is technically wrong
<alyssa>
it works by "coincidence" (and it's a good coincidence to keep) but that doesn't make it 'right'
Ntemis has joined #panfrost
<Ntemis>
hola/hello
<Ntemis>
jump over to ask about t628 support on panfrost/midgard
<Ntemis>
is it still cooking? or abandoned
<bbrezillon>
alyssa: yep, rework = getting rid of the uneeded dep tracking complexity
<alyssa>
bbrezillon: ack
<Ntemis>
because in next circle is very hard to keep supporting it if it still relies on libmali so hopefully mesa support will come sooner or later to resurrect it
<alyssa>
Ntemis: hola/hello a ti tambien/to you too :-p
<Ntemis>
:D
<bbrezillon>
alyssa: what's wrong in update_varyings()?
<Ntemis>
am part of batocera and lakka team and the only target we are not sure about its future is the Odroid-XU4
<alyssa>
bbrezillon: PAN_VARY_* aren't actually the indices of the buffers, they're just... labels? i guess?
<alyssa>
the CPU linking path constructs a bit mask of which buffers are present (1 << PAN_VARY_FOO) | (1 << PAN_VARY_BAR)
<alyssa>
and then the actual buffer indices are calculated from the bit masks (so the buffer_index = n corresponds to the n'th _enabled_ buffer, where the ordering is arbitrary but fixed by the ordering of PAN_VARY_*)
<alyssa>
The effect is skipping over holes in the enabled buffer mask.
<alyssa>
Anyway for position/general/psiz those never have holes under the current allocation scheme, so the indirect code still works
<alyssa>
but it works unintentionally so to speak :)
<bbrezillon>
yeah, I assumed those would keep the same IDs
<bbrezillon>
and always be present
<alyssa>
I guess we should declare that an invariant of varying linking and then add the asserts() in indirect_draw and call it a day.
<bbrezillon>
IIRC I was passing a varying_buf bitmask in one of the preliminary version
<bbrezillon>
and got rid of it at some point
<alyssa>
Right, I'm happy not to have to worry about it there
<alyssa>
just a matter of declaring it correct ;p
<bbrezillon>
don't know if XFB+indirect-draw is a thing, but if it is, we'll have to pass this bitmask anyway
<bbrezillon>
so we might have to make the code more generic anyway
<Ntemis>
can you point me to where i need to whitelist t628 on mesa? i lost the link you gave me last time
<alyssa>
pan_screen.c
<Ntemis>
i will try my luck on 21.1.0 to see if something comes out
<alyssa>
bbrezillon: sadly it is.
<Ntemis>
thanks
<alyssa>
bbrezillon: {xfb, indirect, geom, tess} is a "oh god make it stop" set of interactions.
<alyssa>
at some point (XFB enabled, primconvert required, etc) falling back to util_draw_indirect() might not be such a bad idea
<Ntemis>
case 0x620: /* T628 */ <- is this correct?
<alyssa>
probably
<Ntemis>
thanks on it
davidlt has quit [Ping timeout: 268 seconds]
sphalerite has joined #panfrost
<macc24>
Ntemis: iirc kmscube was working some time ago
<macc24>
kinkinkijkin: ^
stikonas has quit [Ping timeout: 260 seconds]
<kinkinkijkin>
yes
<kinkinkijkin>
this is correct
stikonas has joined #panfrost
tomboy64 has quit [Remote host closed the connection]
tomboy64 has joined #panfrost
stikonas has quit [Read error: Connection reset by peer]
guillaume_g has quit [Quit: Konversation terminated!]
stikonas has joined #panfrost
<Ntemis>
@macc24 what is the remaining issues and its left out of proper support?
<macc24>
Ntemis: i don't know
<Ntemis>
i guess that's a good thing :)
<anarsoul|2>
Ntemis: iirc T628 is midgard gen3 (or gen2?), basically it has too many hw errata to be compatible with gen4 (t720) and thus needs workarounds in driver. These aren't implemented
<Ntemis>
yes for one it cant use vulkan
<anarsoul|2>
it's not about being compatible with vulkan
<Ntemis>
yes i know what you mean
<anarsoul|2>
it's about hw bugs that need workaround in driver
<anarsoul|2>
s/workaround/workarounds
<Ntemis>
are they going to be integrated or is consider not supported
<alyssa>
that's up to you
<anarsoul|2>
no idea. Panfrost development is driven by Collabora, so it really depends on what their customers want
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
bschiett has joined #panfrost
<bschiett>
hi all, I have an issue using 2d texture arrays. i'm on rk3288 platform, kernel 5.9.12, mesa3d 20.2.2. i'm using opengles 3.x context and EGL with DRM/KMS. i'm not getting any errors via gl debug callback so I'm assuming my code is OK. any ideas?
<bschiett>
just wondering if this is potentially a problem with the driver, perhaps due to not supporting 2d texture arrays.
stikonas has quit [Quit: Konversation terminated!]
alyssa has quit [Remote host closed the connection]
alyssa has joined #panfrost
<bschiett>
@Ntemis I have a custom board I designed based on rk3288 so this image probably won't work out of the box (i'm using buildroot and custom DTS)
<Ntemis>
batocera is based on buildroot too
<bschiett>
@alyssa do you think this feature was working with my kernel and mesa version? or was it broken at that time?