alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
austriancoder has joined #panfrost
lvrp16 has joined #panfrost
lvrp16 has quit [Max SendQ exceeded]
lvrp16 has joined #panfrost
stikonas has quit [Remote host closed the connection]
kaspter has joined #panfrost
kaspter has quit [Excess Flood]
kaspter has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #panfrost
paulk-leonov has quit [Ping timeout: 246 seconds]
paulk-leonov has joined #panfrost
kaspter has quit [Quit: kaspter]
kaspter has joined #panfrost
davidlt has joined #panfrost
_whitelogger has joined #panfrost
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
BenG83 has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
warpme_ has quit [Quit: Connection closed for inactivity]
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
davidlt has quit [Ping timeout: 272 seconds]
anarsoul has quit [*.net *.split]
gcl_ has quit [*.net *.split]
remexre has quit [*.net *.split]
Depau has quit [*.net *.split]
rcf has quit [*.net *.split]
rcf has joined #panfrost
anarsoul has joined #panfrost
remexre has joined #panfrost
gcl_ has joined #panfrost
Depau has joined #panfrost
BenG83 has quit [Quit: Leaving]
guillaume_g has joined #panfrost
raster has joined #panfrost
kaspter has quit [Remote host closed the connection]
kaspter has joined #panfrost
davidlt has joined #panfrost
raster has quit [*.net *.split]
davidlt has quit [Ping timeout: 264 seconds]
MastaG has joined #panfrost
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
camus1 is now known as kaspter
raster has joined #panfrost
warpme_ has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
stikonas has joined #panfrost
kaspter has quit [Ping timeout: 258 seconds]
kaspter has joined #panfrost
stikonas has quit [Remote host closed the connection]
gcl_ is now known as gcl
icecream95 has joined #panfrost
gcl is now known as gcl_
gcl_ is now known as gcl
gcl is now known as gcl-
gcl- is now known as gcl
icecream95 has quit [Quit: Quit]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #panfrost
raster has quit [Remote host closed the connection]
kaspter has quit [Quit: kaspter]
raster has joined #panfrost
tgall_foo has quit [Read error: Connection reset by peer]
tgall_foo has joined #panfrost
buzzmarshall has joined #panfrost
<alyssa> tomeu: Something that's bugging me is the texture/sampler count fields in the shader descriptor.
<alyssa> To Mali, these are evidently shader properties (sandwiched between attribute/varying count and work register count)
<alyssa> Logically, the # of textures/samplers you can access is known at compile-time. Uh, I think... not really sure how indirect access plays in.
<alyssa> OTOH Gallium provides this information only at texture/sampler bind time, so we can't bake it in.
<alyssa> I'm trying to figure out who's correct here.
<alyssa> (I mean, obviously the hardware is authoritative on what we do with the hardware..)
<alyssa> When no indirect samplers/textures are used, we can do static analysis, that's fine
<alyssa> It's when indirection is used that things get more.. icky. Let's check the spec
raster has quit [Quit: Gettin' stinky!]
raster has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
<chrisf> alyssa: you should know the complete set of interesting binding points at link time
<chrisf> alyssa: indirect access is restricted to indexing into arrays of things which [in GL] occupy some contiguous range of binding points
gtucker has joined #panfrost
<alyssa> chrisf: *nods*
<alyssa> Did that and it seems to work
<alyssa> which means now non-fragment shaders can have their shader descriptor completely packed at compile-time
<alyssa> (and fragment shaders have a lot less work)
<karolherbst> hey.. does Xorg 1.20 work on panfrast? Or is 1.21 required due to modifiers?
<karolherbst> asking because 1.20 is totally busted for tegra + nouveau
<karolherbst> mainly wondering if that's a common problem or not
<alyssa> I seem to be running 1.20.8 right now
<alyssa> OTOH we're still using linear for scanout
<karolherbst> alyssa: right...
<karolherbst> alyssa: I am asking because I was working with tagr on getting tegra+nouveau fixed on 1.20.8
<karolherbst> alyssa: but I assume your are handling that part inside mesa?
<alyssa> hm?
<karolherbst> alyssa: the issue was, that forcing to linear inside mesa made X work, but mutter broke
<alyssa> why is that necessary?
<karolherbst> so if you run mutter modifier unawared (default) it doens't work
<karolherbst> but yeah.. I am not quite sure myself on why that is necessary
<karolherbst> the X bits I mean
<karolherbst> but it doesn't seem like tagr was able to fix mesa in a way it works everywhere
<alyssa> :|
<karolherbst> uhm....
<karolherbst> wrong MR
<karolherbst> that one
<karolherbst> the mesa MR fixes it for modifier unaware compositors
<karolherbst> the X one fixes modesetting on 1.20.8 for us
<karolherbst> alyssa: my initial fix was this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6300
<karolherbst> but that didn't work with wayland
<karolherbst> and using always linear there causes issues when you render depth stencil buffers
<karolherbst> as this can only be tiled for us
<karolherbst> or rather, you can mix and match
<karolherbst> *can't
<karolherbst> anyway
davidlt has joined #panfrost
<alyssa> :|
<karolherbst> I am mainly wondering how all of that works on other SoCs
<alyssa> I dunno, I copied what v3d did and things seemed to just work
<karolherbst> mhhh I see
<alyssa> (actually hit a kernel bug but.. meh)
<karolherbst> alyssa: but are you sure that eg gnome just works on panfrost as well?
<karolherbst> or kmscube without modifiers?
<alyssa> no, I didn't test this much
<alyssa> since I was hitting the more serious kernel bugs
<alyssa> and so had to hide the whole thing behind a debug field
<karolherbst> mhhh
<karolherbst> I see
<karolherbst> so, X works, but wayland without modifiers is an unkown?
<alyssa> I didn't test wayland w/o modifiers
<alyssa> since weston/mutter both did modifiers ok
<karolherbst> ahh
<karolherbst> mutter doens't use modifiers by default afaik
<alyssa> (out-of-box, didn't touch the mutter setting)
<alyssa> it does for window->compositor buffers, SHARED
<alyssa> it doesn't for SCANOUT
<karolherbst> ohhh
<karolherbst> I see
<karolherbst> yeah well.. we have issues on the scanout level
<alyssa> everyone does
<karolherbst> nouveau works, it's tegra which is busted :)
<karolherbst> ahh okay
<alyssa> that's why we're LINEAR for scanout on master :<
<karolherbst> so it's an issue for everbody
<alyssa> different issues
<karolherbst> okay
<alyssa> in our case it's because of kernel fustercluck
<karolherbst> right..
<karolherbst> okay.. then I guess if we make it work with tegra+nouveau it might actually also help for other SoCs later on.. mhhh
<karolherbst> mhhh
<alyssa> ^ I can't enable AFBC for scanout until this is merged and backported far enough that nobody will use mesa master on a rk3399 without that patch
<karolherbst> this is all very annoying somehow....
<karolherbst> we can't release 1.21 because people say "ahh this hurts us"
<karolherbst> but we need 1.21 for modifiers
<karolherbst> :/
<alyssa> what's wrong with 1.21
<karolherbst> "This is dangerous. On Intel GPUs, enabling modifiers can increase bandwidth usage and prevent extra CRTCs from being enabled." is what we got on !497
<karolherbst> but I think 1.21 is a deeper thing we have to figure out somehow
<karolherbst> I notcied more discussions on that
<alyssa> yes, modifiers aren't always a win
<karolherbst> yeah
<karolherbst> .. as I said " annoying"
davidlt has quit [Ping timeout: 265 seconds]
<karolherbst> I would be fine with just releaseing 1.21 and let people seeing regerssions to sort it out
<karolherbst> I think that would help most SoCs, no?
<alyssa> dunno, our AFBC issues are deeper than 1.21
<karolherbst> right... but I suspect you want X to use modifiers regardless, no?
<alyssa> yeah
<alyssa> we have uncompressed tiled format which we use for SHARED, so that'd be a win for 1.21
<karolherbst> okay.. cool
<karolherbst> I am inlcined to ignore 1.20 being broken if 1.21 works
<karolherbst> but for that we need to release 1.21 :)
<alyssa> { static unsigned panfrost...() {
<alyssa> osh I wonder why gcc is angry
<karolherbst> hitting compiler bugs again? :p
<alyssa> which compiler? =p
<karolherbst> right...
<karolherbst> all of them :p
<karolherbst> which.. with clover can actually happen. you at least have like 4 compilers involved :D
<alyssa> .....Yup
davidlt has joined #panfrost
<HdkR> 1"Throw an error in CMake if someone attempts to compile with GCC" That's a recent change of mine because gcc is busted on my project :P
<alyssa> HdkR: :<
<macc24> HdkR: alias gcc='clang'
<HdkR> I've...optimized for clang
<alyssa> oh no
<alyssa> Ha-ha! Now the entire descriptor associated with a vertex shader can be uploaded at CSO create time, so draw-time is literally just the cost of tracking the BO
davidlt has quit [Read error: Connection reset by peer]
davidlt has joined #panfrost
<HdkR> alyssa: From the earlier texture discussion, I guess Midgard doesn't support bindless sampler and textures, so it can't support the bindless GL extension yet?
<alyssa> HdkR: I don't think so.
<alyssa> I'm not sure how the vk blob handles that
<alyssa> Possibly there is a trick I don't know about but \shrug/
<HdkR> I think you need descriptor indexing with Vulkan to have true bindless?
<alyssa> Perhaps
<HdkR> Internet seems to concur
<HdkR> Whoa, G77 exposes descriptor indexing
<alyssa> HdkR: of course, you could just use gigantic sampler/texture tables and have your handles be indices to emulate bindless on a decidedful bindful architecture
<alyssa> (for midgard)
<alyssa> no idea if the vk blob does something more clever, I imagine doing that will thrash the cache terribly
<HdkR> Except you still have an upper limit cap on number of bound images before that extension
<HdkR> Which looks like ARM sets that cap to 16 per stage
davidlt has quit [Remote host closed the connection]
<chrisf> one annoying thing to think about for the VK case is the api requires you to support 4 simultaneously bound tables
<chrisf> err, descriptor sets
<alyssa> chrisf: ...hm?
<chrisf> on most of this hw you're going to be doing a bunch of copying to make that work
<HdkR> Yea, the four descriptors being bound end up being weird
<HdkR> At least Valhall supporting descriptor indexing implies that there were significant improvements to support bindless there :)
<alyssa> HdkR: ooi does Bifrost support that?
<HdkR> Doesn't show up in gpuinfo
<HdkR> So I'd guess nope
<alyssa> boo :p
<chrisf> and.. do we have to separate descriptors by type?
<HdkR> I believe so
<HdkR> I think that's imposed by the extension
<chrisf> ignoring extensions; im thinking about mapping of vk descriptor sets to physical layout for the hw
<HdkR> ah
<chrisf> ~ will bifrost tolerate textures base == samplers base == ubos base, etc
<chrisf> similarly curious about the exact function of the resource count fields alyssa mentioned before. does the hw bounds check against them? does it assume to be able to *prefetch* all descriptors up to those limits, and so likely to explode if you have something else in there?
<alyssa> chrisf: "will bifrost tolerate textures base == samplers base == ubos base, etc", Probably, if you are very careful about alignment
icecream95 has joined #panfrost
<alyssa> "does the hw bounds check against them?" yes, silently failing if OOB (e.g. texture reads return 0)
<alyssa> (at least on midgard I saw that, I haven't tested on Bifrost)
<chrisf> my understanding is that midgard actually makes vulkan binding model slightly easier due to indirection?
<alyssa> "does it assume to be able to *prefetch* all descriptors up to those limits" No idea
<alyssa> which indirection?
<alyssa> textures?
_whitelogger has quit [Ping timeout: 240 seconds]