ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
<marex> austriancoder: how do I generate etnaviv_hwdb.c records from the viv kernel driver tables ?
alarumbe has quit []
chewitt has joined #etnaviv
chewitt has quit [Ping timeout: 480 seconds]
chewitt has joined #etnaviv
<austriancoder> marex: I asked the freebsd person - and yes he had to disable BLT. Looks like they have messed up their gc_feature_database.h :/ And this is problematic, as we trust these files and always use the one from the SoC vendors. This should help for conversion: https://github.com/gizmo98/hwdb-converter/
cphealy_ has joined #etnaviv
cphealy has quit [Ping timeout: 480 seconds]
pcercuei has joined #etnaviv
alarumbe has joined #etnaviv
<marex> austriancoder: sigh ... I'll start preparing patches then
<marex> austriancoder: and uh ... check the AXI error too, any idea what that might be about ? Probably something is shut down which is then not brought back up, MMU maybe ?
<marex> the chip does need SEC_KERNEL
<marex> austriancoder: maybe ST didn't screw it up, the chip does have gcFEATURE_BIT_REG_BltEngine 0 , so I wonder why mesa enabled BLT
<marex> I think I need to comb through the hwdb next
chewitt has quit [Quit: Zzz..]
<austriancoder> marex: from hwdb point of view (in mesa) it should be fine
<marex> austriancoder: maybe I messed something up
<marex> austriancoder: that said ... there is one more thing
<marex> austriancoder: the HWDB indicates this is a combo GPU and NPU, is that possible ?
<marex> austriancoder: and if so, is the NPU just another pipe ?
<marex> austriancoder: maybe that is something which needs to be tweaked in etnaviv in mesa ?
<austriancoder> marex: ahhh.. thats the problem :)
<austriancoder> marex: lets see how to fix it
<austriancoder> marex: quick hack to test it out
<marex> austriancoder: I have that in mesa already
<marex> austriancoder: I'll open MRs once I clean the patches up, probably tomorrow
<austriancoder> marex: and ETNA_MESA_DEBUG=dbg_msgs is telling it is using RS?
<marex> austriancoder: but how do you propose to handle this combined GPU/NPU device, so it can be used as both ?
<marex> austriancoder: I hacked mesa to not use BLT, so it is telling me it is using RS now
<austriancoder> marex: where did you hacked it up? the source of this information is in etna_hwdb.c
<marex> iirc in etna_screen , there is some ->use_blt = feature check
<marex> I think the root cause of this might have been missing hwdb entry in the kernel (?)
<austriancoder> marex: that feature check calls into etna_core_has_feature(..)
<austriancoder> which gets is info form the hwdb in mesa based on model, rev, product_id, vendor_id, and eco_id
<austriancoder> and this information is coming from the kernel
<marex> austriancoder: err, wait, what ? why does mesa etnaviv driver have its own tables of hardware then ? is the kernel hwdb entry the representative one ?
<austriancoder> to support npu and gpu a good starting point is to remove the union in struct etna_core_info
<austriancoder> marex: the on in meas are based on soc vendor gc_feature_database.h files - the kernel ones mimic the old gpu feature register. I have a good summary of it here: https://christian-gmeiner.info/2024-04-12-hwdb/
<marex> austriancoder: if you want to fiddle with the MP2 now, I can give you the patches I have locally
<marex> austriancoder: although, bringing up the MP2 with mainline Linux can be grueling
<austriancoder> marex: I would love to have a look at the patches and play with them, but xdc is coming too fast for me and I need to prep a talk and some MRs for my talk :/ After xdc I am open for the challenge, but I think you have solved it by then.
<marex> austriancoder: when is XDC ?
<marex> austriancoder: and I think this is fine, I think once I figure out the AXI error, the GPU will be in good shape
<marex> austriancoder: and the AXI error seems easy to figure out
pcercuei has quit [Quit: dodo]