ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
vstehle1 has quit [Ping timeout: 480 seconds]
JulianGro2 has joined #panfrost
JulianGro has quit [Remote host closed the connection]
JulianGro has joined #panfrost
JulianGro2 has quit [Read error: Connection reset by peer]
ente` has joined #panfrost
ente` has quit [Ping timeout: 480 seconds]
ente` has joined #panfrost
ente` has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
ente` has joined #panfrost
anholt has joined #panfrost
camus has joined #panfrost
JulianGro2 has joined #panfrost
JulianGro has quit [Read error: Connection reset by peer]
JulianGro2 has quit [Remote host closed the connection]
anholt has quit [Quit: Leaving]
jambalaya has quit [Remote host closed the connection]
jambalaya has joined #panfrost
vstehle1 has joined #panfrost
tolszak has joined #panfrost
guillaume_g has joined #panfrost
sigmaris has quit [Server closed connection]
sigmaris has joined #panfrost
MajorBiscuit has joined #panfrost
camus has quit [Read error: Connection reset by peer]
camus has joined #panfrost
tolszak has quit [Remote host closed the connection]
<alyssa>
bbrezillon: and I were chatting more seriously about replacing the indirect infrastructure with OpenCL C stuff
<alyssa>
icecream95 has the plumbing for clc, jekstrand seems to be in favour, I think I am as well.
<alyssa>
(Based on previous conversation here and elsewhere)
<alyssa>
I am firmly against checking in compiled blobs in-tree. This includes both SPIR-V blobs and especially Mali shader blobs.
<alyssa>
So if we go down this route, we effectively mandate that anyone compiling Panfrost have working clang + llvm-spirv
<alyssa>
Given we want OpenCL + Panfrost anyway, this seems more reasonable than it used to. It looks like everything needed is in Debian stable, surely other distros have it too.
<alyssa>
As a stopgap, we could disable missing functionality if the dev deps are missing, but I worry that will create a new stream of bug reports...
pch has joined #panfrost
pch_ has joined #panfrost
kinkinkijkin has quit [Ping timeout: 480 seconds]
<tomeu>
exciting!
<alyssa>
tomeu: ..is it?
<tomeu>
to me it is for sure, even if there's llvm+clang in the picture :)
<alyssa>
Mostly about reducing some a dev pain point
<alyssa>
Valhall does not seem to like 8192x8192 framebuffers
<HdkR>
:<
<alyssa>
wonder if the DDK allows em
ente` has quit [Ping timeout: 480 seconds]
<alyssa>
need to set the hierarchy mask differently. ok
bluebugs has quit [Read error: Connection reset by peer]
bluebugs has joined #panfrost
guillaume_g has quit []
rcf has quit [Remote host closed the connection]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
pjakobsson_ has joined #panfrost
hl` has quit [Server closed connection]
hl` has joined #panfrost
pjakobsson has quit [Ping timeout: 480 seconds]
floof58_ has joined #panfrost
floof58_ has quit []
floof58_ has joined #panfrost
floof58 is now known as Guest864
floof58_ is now known as floof58
Guest864 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
ente` has joined #panfrost
JulianGro has joined #panfrost
rcf has joined #panfrost
erle has quit [Ping timeout: 480 seconds]
<alyssa>
biggest source of fails is not supporting legacy geometry flow, or infra to make memory writes play nice with IDVS
erle has joined #panfrost
<alyssa>
oh and separate shaders
<alyssa>
For separable shaders, the "easy" way is to lay out varyings as (location - VARYING_SLOT_VAR0)
<alyssa>
er
<alyssa>
(location - VARYING_SLOT_VAR0) * 16
<alyssa>
but...
<alyssa>
1. That doesn't work for compat GL
<alyssa>
2. That doesn't optimize fp16
vstehle1 has quit []
ente` has quit [Quit: rebooting]
icecream95 has joined #panfrost
ente` has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
<icecream95>
alyssa: One other problem is cross-compiling.. either we compile util and clc twice or the build machine has to be able to emulate host binaries
<alyssa>
Right. That too.
<alyssa>
I wonder how intel handles this?
<icecream95>
I don't think they've found a solution yet?
<icecream95>
And.. usually Intel GPUs are connected to Intel CPUs? Though IIRC they were talking about x86 Android
rkanwal has quit [Ping timeout: 480 seconds]
rkanwal has joined #panfrost
<alyssa>
I talked to a Debian developer for perspective
<alyssa>
They think compile clc for host (slightly longer cross compile time) is fine, and generally Debian doesn't use cross-compiles anyway
<icecream95>
alyssa: Another question is whether there is a better way of specifying kernel arguments
<icecream95>
Currently I'm using a wrapper which puts all of the arguments in a uint64_t[], but I'd rather have some way to have a shared prototype between the CL source and .c
<icecream95>
I'm not sure if that can be done without extra indirection on the kernel side... currently we can upload kernel arguments as push constants
<alyssa>
memcpy(&push, &struct, sizeof(struct))?
<alyssa>
I guess alignment needs care. I don't care about supporting Midgard for this I don't think.
<icecream95>
Wait.. it seems that OpenCL *does* support structs as arguments? That would make things easier..
<Rathann>
FWIW, Fedora does native compilation as well
<alyssa>
Rathann: Good, that's two distros down :)
<alyssa>
If it's good enough for Debian and Fedora it's good enough for everyone :x
<Rathann>
I think we only do cross-compilation to mingw targets
<alyssa>
Yep not my problem ;)
<Rathann>
and I'm told some developers love being able to develop and build Windows applications on Fedora
<icecream95>
A problem is that I don't think Meson supports compiling a single library for two architectures, so there would be a lot of duplication in the meson.build files
<Rathann>
icecream95: wouldn't out-of-source build solve this problem?
<alyssa>
what does clc depend on anyway?
<icecream95>
util
<alyssa>
right
<icecream95>
Maybe only a subset of that, but still...
* Rathann
waves sleepily
<Rathann>
goodnight
<alyssa>
icecream95: Just u_dynarray no?
<alyssa>
oh and everything from clc itself
<alyssa>
right ok
<alyssa>
oh it pulls in all of NIR indirectly
<alyssa>
even though we just want to compile c to spirv, no nir involved?
<icecream95>
I don't think we need anything which uses NIR, so we can move the NIR stuff to a separate source file
<alyssa>
yeah, I think with some discipline it could be self-contained
<alyssa>
and u_dynarray is header only anyway
floof58_ has joined #panfrost
<icecream95>
I still wonder if using SPIR-V is the best idea.. the main reason I went with it was to be able to enable/disable printf at runtime
floof58 has quit [Ping timeout: 480 seconds]
floof58_ has quit []
floof58 has joined #panfrost
<alyssa>
Anything earlier adds a runtime dependence on LLVM or at least llvm-spirv
rkanwal has quit [Quit: rkanwal]
<alyssa>
Anything later adds a build-time dependence on NIR
<alyssa>
SPIR-V seems by far the easiest
Rathann has quit [Remote host closed the connection]
<icecream95>
I guess we can always do caching if compilation time becomes a problem
<icecream95>
How high a memory usage can I get to before the system falls over?.. zram:11.0G used:2.21G uncompressed:7.06G
<icecream95>
alyssa: I've pushed a 'v9-images-newvec8' branch...
rasterman has quit [Remote host closed the connection]
* icecream95
gets breakfast
* alyssa
eyes
JulianGro has quit [Remote host closed the connection]