<pcercuei>
I have a question about the interaction between the GPU and DRM drivers
<pcercuei>
Using a standard setting (EGL + GLESv2): where do the buffers come from? Are they allocated by the GPU driver, then passed (via PRIME?) to the DRM driver?
<pcercuei>
Or are they allocated by the DRM driver, and the GPU just renders to a dumb buffer?
<lynxeye>
pcercuei: Depends on implementation of particular GPU driver. On etnaviv we (abuse) the dumb buffer API and allocate at the KMS side, then share to the GPU side via prime.
<pcercuei>
Ah. Alright
<pcercuei>
that's bad news for me
<marex>
lynxeye: oh hey btw pointsprites should now work
<pcercuei>
I want to make my KMS driver's dumb buffer cacheable, which gives a big speed boost when software rendering. But I don't know how it will affect hardware rendering...
<lynxeye>
pcercuei: The GPU driver doesn't care about the caching mode. Just make sure that you don't writeback dirty/clean cachelines, as this might corrupt the buffer.
Net147 has joined #etnaviv
<pcercuei>
lynxeye, thanks, that's good to know
philn_ has joined #etnaviv
Net147_ has quit [Ping timeout: 256 seconds]
griffinp- has quit [Ping timeout: 256 seconds]
philn has quit [Ping timeout: 256 seconds]
<pcercuei>
lynxeye: is there a case where these buffers are also accessed by the CPU? e.g. to display an overlay, etc?
<lynxeye>
pcercuei: There is a theoretical possibility that we might do a CPU access, but I'm not aware of any real-world case where the driver would do this.
<pcercuei>
ok
<lynxeye>
However the mmap is done via the dmabuf exporter mmap function, so you could give the GPU driver a coherent mapping.
karolherbst has quit [Ping timeout: 245 seconds]
karolherbst has joined #etnaviv
<marex>
lynxeye: wont you even praise me for my valiant struggle with this difficult issue ? :)
<austriancoder>
marex: you did a wonderful job - keep up the good work!
<lynxeye>
marex: I can't say that I care too much about pointsprites. ;) But good job on working your way through. :)
<lynxeye>
austriancoder: marex: Do you have any idea how far we are off from being able to switch NIR on by default?
<lynxeye>
Do you have a list of stuff that still fails with NIR vs TGSI?
<austriancoder>
lynxeye: soon.. i want to wait until the next release is branched away.
<austriancoder>
lynxeye: there is not much on my list .. some code clean ups and some ubo stuff - spend the last months/weeks only on that topic
<lynxeye>
austriancoder: Yep, I've seen your MR activity. Just wanted to get a general feel on how much is still on your list.
<pcercuei>
we've been using NIR for a few months, it works fine
<lynxeye>
pcercuei: It works fine for my use-cases for ~2 years. Doesn't mean it's good to go for everything.
berton has quit [Remote host closed the connection]
<marex>
austriancoder: aww, thank you :)
<marex>
lynxeye: I really like the way you put it ;-)
<marex>
lynxeye: nir works fine for my usecases too
lynxeye has quit [Quit: lynxeye]
kherbst has joined #etnaviv
karolherbst has quit [Read error: Connection reset by peer]
t_unix[m] has joined #etnaviv
<t_unix[m]>
has anybody had issues with etnaviv reading shifted (or missaligned or 0-padded) bytes via gpu_read for VIVS_HI_CHIP_MODEL and VIVS_HI_CHIP_REV of the GC880? The model GC 880 on my board ist ocasionally read as 8800000. Afterwards the reset fails GPU „failed to reset: FE idle, 3D not idle, 2D not idle“
<marex>
t_unix[m]: which kernel version and mesa version ? do you have a test case which triggers this ?
<marex>
t_unix[m]: I assume its mx6dl ?
<marex>
austriancoder: ^
<austriancoder>
t_unix[m]: custom board?
<t_unix[m]>
It’s a solo
<t_unix[m]>
Unfortunately, I do not have a specific test case
<t_unix[m]>
It’s the 4.19 LTS Kernel
<t_unix[m]>
I assume Mesa isn’t involved at this stage?
<austriancoder>
correct
<t_unix[m]>
AFAICT it happens after a POR
<t_unix[m]>
It’s a Phytec standard SoC
<t_unix[m]>
Is the reading of padded/ shifted values from one of the cores something anybody has come across yet?
<t_unix[m]>
Just to make sure, I’m on the right track
<austriancoder>
I never have seen something like this. maybe power issues.. brown out maybe
<t_unix[m]>
Thank you. That’s a clue
JohnnyonF has quit [Read error: Connection reset by peer]
<marex>
t_unix[m]: presumably also using the bootloader which comes with the SoM , not some ATF extras ?
<lrusak>
I looked at the dts files for each board and didn't see anything that would cause one to use cpufreq and one not to
<lrusak>
and I guess if the grade/segment doesn't match what is allow in the opp table it may not have any other frequencies, thus cpufreq isn't needed?
<marex>
lrusak: hold on, let me boot up web browser so that I can read the first part of your short text message
<marex>
lrusak: isnt cpufreq on mx8m calling into ATF ?
<lrusak>
Not sure :) uboot, ATF, and kernel version is the same
<marex>
lrusak: in that case, look into the cpufreq driver