ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
frieder has joined #etnaviv
frieder_ has joined #etnaviv
frieder_ has quit [Remote host closed the connection]
frieder has quit [Quit: Leaving]
frieder has joined #etnaviv
mvlad has joined #etnaviv
T_UNIX has quit []
T_UNIX has joined #etnaviv
lynxeye has joined #etnaviv
pcercuei has joined #etnaviv
pcercuei has quit [Quit: brb]
pcercuei has joined #etnaviv
<marex> there is one thing I was wondering about for a while -- is there a way to debug etnaviv without compiling and running mesa on the target ? Like via some proxy pipeline, where the BOs are prepared on development PC with enough resources and only pushed to the target for processing ?
<lynxeye> marex: Not that I know of. It should be possible if you just map the etnaviv UAPI to some network protocol and then slide the proxy under the driver on the development host, but I imagine dragging MBs of buffer content across a network pripe to be painful.
<lynxeye> marex: Do you really compile Mesa on the target? My usual workflow is just cross-compiling with nfsroot on the target to get reasonable turnaround times.
<marex> lynxeye: I crosscompile, but still ... it's not perfect
<marex> I take it gdbserver is also part of your workflow then ?
<lynxeye> right
<marex> ha
otavio__ has quit [Remote host closed the connection]
otavio_ has joined #etnaviv
otavio_ has quit [Remote host closed the connection]
otavio_ has joined #etnaviv
otavio_ has quit [Remote host closed the connection]
otavio_ has joined #etnaviv
lynxeye has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]