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
icecream95 has joined #panfrost
pch has joined #panfrost
Danct12 has joined #panfrost
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #panfrost
jekstrand has joined #panfrost
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #panfrost
rasterman has joined #panfrost
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #panfrost
Major_Biscuit has joined #panfrost
rkanwal has joined #panfrost
<tomeu> icecream95: are you working on a driver for that NPU?
<tomeu> I'm doing that for the one in the vim3, which should be very similar IP
<tomeu> [ 182.982051] etnaviv-gpu ff100000.gpu: model: GC8000, revision: 7120
xdarklight_ has joined #panfrost
xdarklight has quit [Ping timeout: 480 seconds]
erle has quit [Ping timeout: 480 seconds]
erle has joined #panfrost
<icecream95> tomeu: Yup, eventually. How much progress have you made so far?
<icecream95> So far I've just got a panwrap-style tracing library at https://gitlab.freedesktop.org/icecream95/rockwrap and used pytorch in a QEMU-emulated x86_64 chroot to poke at things
<tomeu> icecream95: I have approached this as another vivante GPU
<tomeu> so I'm using the etna_viv RE tools
<tomeu> have hacked Mesa to compile a very simple opencl kernel and emit the same cmdstream as the blob
<tomeu> the kernel driver powers up the HW and I can read and write registers
<tomeu> but when I submit my workload the GPU times out
<tomeu> so I'm looking at what is special about the NPU regarding submission
<tomeu> I have assumed that the npu on the 3588 is also based on vivante IP, like in earlier rockchip socs, is that the case?
<icecream95> The NPUs in RK356x and RK3588 are apparently quite different from older SoCs...
<tomeu> oh, so they aren't using galcore?
<tomeu> "RV1106 and RV1103 use Cortex-A7 CPU and high-performance MCU, built-in Rockchip's self-developed 4th generation NPU"
<tomeu> hmm, indeed, this seems to be completely different silicon
<tomeu> given the mess that vivante is, I would expect it to be easier to write a driver for it
<tomeu> icecream95: btw, do you have the sources for the kernel module?
<icecream95> What sort of driver though? I don't think that Mesa would be a good fit, it seems far too limited for OpenCL. No FP32 support, AFAIK
<tomeu> icecream95: does it matter if it isn't opencl compliant? as long as it can run the workloads it is designed to support...
<tomeu> I'm afraid it has to be opencl, otherwise what are we going to do, write a new API and add a backend for it to all ML frameworks?
<tomeu> but it doesn't need to be compliant or support everything opencl has
<icecream95> I'm afraid that it'll be too limited even for the simplest "Hello World" CL examples...
<icecream95> Rockchip at least have taken the "write <N> backends" approach
<icecream95> Even some of those supported operations are executed on the CPU
<tomeu> yeah, all soc vendors are doing it, but I'm not sure this is an option for us if we want for the backends to be upstream
<icecream95> I think that Rockchip mostly relies on ONNX for supporting all the different frameworks
Daanct12 has joined #panfrost
<tomeu> hmm, if that would be enough, guess we could get a backend for our API if needed: https://github.com/microsoft/onnxruntime-openenclave/commit/edaf8a542c21b7f38cfc871fff9540ceb0e56951
Danct12 has quit [Ping timeout: 480 seconds]
<icecream95> I guess the question is... do we submit a PR to remove the vendor RKNPU code once a driver is written? :)
<icecream95> Though your linked commit appears to be for different hardware
<tomeu> ah, true, seems to be targetting a rockchip library on top of the vivante blobs
<tomeu> but the point was that if there can be a onnx backend for rknpu (whatever the IP is), we could have one for a new API
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #panfrost
<tomeu> though TBH, I'm not looking forward to adding one more API to this soup
icecream95 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
<CounterPillow> My favourite part of the rknpu driver is how it inexplicably has an ioctl to set process niceness
<CounterPillow> Like, not niceness of the npu access it seems, just in general
<urja> is that a way to get around taking higher priority for non-root process?
<urja> (that is, you get to open the device, you get to have high priority... lol)
rcf has quit [Ping timeout: 480 seconds]
xdarklight_ is now known as xdarklight
rcf has joined #panfrost
wolfshappen has quit []
wolfshappen has joined #panfrost
soreau has quit [Read error: Connection reset by peer]
soreau has joined #panfrost
greenjustin has joined #panfrost
greenjustin has quit [Ping timeout: 480 seconds]
zhxt has joined #panfrost
floof58 has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 480 seconds]
zhxt has quit [Remote host closed the connection]
wolfshappen has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
pch has quit [Remote host closed the connection]
greenjustin has joined #panfrost
wolfshappen has joined #panfrost
wolfshappen has quit []
wolfshappen has joined #panfrost
rkanwal has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
MajorBiscuit has joined #panfrost
guillaume_g has quit []
marcan has joined #panfrost
MajorBiscuit has quit [Quit: WeeChat 3.5]
greenjustin has quit [Ping timeout: 480 seconds]
macc24 has joined #panfrost
erle has quit [Ping timeout: 480 seconds]
erle has joined #panfrost
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
Consolatis_ has joined #panfrost
Consolatis is now known as Guest6137
Consolatis_ is now known as Consolatis
icecream95 has joined #panfrost
Guest6137 has quit [Ping timeout: 480 seconds]
icecream95 was kicked from #panfrost by ChanServ [You are not permitted on this channel]
icecream95 was banned on #panfrost by ChanServ [icecream95!*@*.*]