<Marijn[m]>
lumag_: I recently migrated an Android build over to `minigbm` for graphics buffer allocation and mapping, but its `msm` backend assumes UBWC buffers to be available and presentable which is true on DPU1 but not on MDP5. Now, I could probably change `minigbm` to check if this modifier is supported by the planes before allocating a buffer like that (it's probably requested for SCANOUT), but we could also "add" support for it to MDP5 by
<Marijn[m]>
exposing `DRM_FORMAT_MOD_QCOM_COMPRESSED`. This seems to work just fine, and I don't see DPU1 set up any special registers or configuration for that format besides switching to a different QoS LUT table. What are your toughts, can we safely set this for the MDP5 planes or am I skimping over something?
<lumag_>
Marijn[m], good question. I don't have early datasheets at hand. Let me dig it through.
<Marijn[m]>
lumag_: Thanks for that!
<lumag_>
Marijn[m], the generic answer would be that typically you'd like to support running your userspace with older kernels too
<Marijn[m]>
This is on an sdm660 device which we may want to migrate to DPU1 at some point, but I also have an msm8976 device that's also on mdp5 but may not make the cut. Depends on how many things we can or are willing to hide behind feature flags in DPU1 afaik.
<Marijn[m]>
lumag_: Yeah, maybe I'll want to write up that support code anyway. But exposing support from the driver side may be nice too to actually use and present UBWC render targets
<Marijn[m]>
I'm just surprised that the hardware block isn't told anything about that, or does it autodetect some metadata being available in the buffer or something like that?
<lumag_>
Marijn[m], see the dpu_hw_sspp_setup_format
<lumag_>
I don't remember, which of devices had UBWC 1.0
<lumag_>
UBWC 1.0 support is not currenty present in DPU1 driver (it can be easily enabled though)
<lumag_>
Interesting. it looks like flto missed sdm845 (DPU 4.x) when refactoring the UBWC reset support in DPU1.
pevik_ has joined #linux-msm
<Marijn[m]>
lumag_: Okay, so there is a global UBWC config for all SSPPs, not per-plane? But we should still be able to present both linear and UBWC with planes?
<Marijn[m]>
Ah I see `ubwc_meta_enable`
<Marijn[m]>
I had only been grepping for `DRM_FORMAT_MOD_QCOM_COMPRESSED` but there's also `DPU_FORMAT_IS_UBWC`.
<Marijn[m]>
Really surprising that I wasn't seeing any corrupted planes then (on top of what was already corrupted, but that's within planes because the GPU is bonkers), or maybe hardly any plane is UBWC...
<lumag_>
the latter one.
<lumag_>
ubwc is not used for typical planes. It's mostly video & camera thing
<flto>
lumag_: that's wrong, UBWC should be used in almost all cases with display.. (not just video/camera, but also anything rendered with GPU)
<lumag_>
Marijn[m], citing one of documents: "Universal bandwidth compression (UBWC) is supported by all Adreno 5x GPUs"
<lumag_>
flto, yep, and GPU
<Marijn[m]>
I thought GPU also used it quite often. Was surprised to see this being allocated from the bootimage, hence found that minigbm also uses it
<Marijn[m]>
Ah, that is exactly what flto wrote :)
<Marijn[m]>
(I should stop switching between terminals and not leaving half-finished sentences in IRC)
<lumag_>
flto, btw, as I've stumbled upon this. Could you please check if DPU_HW_VER_4xx is missing in the the dpu_mdss_enable()?
<Marijn[m]>
lumag_: Yeah, so our a5xx GPU can easily render to it or use it as intermediates... But can mdp5 hardware also present to it?
<flto>
lumag_: before 544d8b96150dea, it was just writing zero to a bogus address (to UBWC_STATIC+0x1000 instead of UBWC_STATIC) - so presumably UBWC was working OK on 4xx with the reset value
<lumag_>
flto, ok
<lumag_>
Marijn[m], judging from downstream kernels, 8996/8937/8937/8917 have ubwc
<lumag_>
Not sure about the 8916
<Marijn[m]>
lumag_: ah yes, I can of course also look at the downstream implementation
<Marijn[m]>
Will check that out then
<Marijn[m]>
But implementing ubwc support properly in mdp5 may be a rather significant task, and is perhaps more useful to see if we can migrate more devices to the dpu1 driver?
<lumag_>
Marijn[m], that would be great. Especially if I finish the src split support in dpu
<Marijn[m]>
What SOCs do you reckon it can support? Everything on mdp5 given that we may need to hide some things behind feature flags?
<konradybcio>
it probably depends on how much hiding is reasonable
<konradybcio>
s/reasonable/required and reasonable
<lumag_>
There were several discussions, but I think there was no real conclusion.
<konradybcio>
first iterations of the downstream SDE driver had traces of 8996
<lumag_>
At some point it was suggested than we can migrate all SoCs which do not use LM's cursor support
<Marijn[m]>
lumag_: Alright, thanks for the info - I'll just try converting either SoC and see where we end up then. Likewise, I'll also queue proper plane-supported format modifier checks in minigbm on my list. Finally, I should check if the presented planes were using UBWC already (as they were coming from the GPU) and somehow magically just work, which seems extremely unlikely
<Marijn[m]>
I've seen mostly similarities in the encoder, haven't visited many other places of these drivers just yet
<Marijn[m]>
Still lots (of terminology) to learn :(
<lumag_>
The mdp5 and dpu1 should be pretty similar, as the hardware was slowly changing
<lumag_>
kholk[m], posted 8998 patchset for dpu1 some time ago
<konradybcio>
sdm630 wasn't far off working at one point
<lumag_>
One would have to also support rgb and cursor planes in hw catalog
<konradybcio>
there were (you guessed it) pingpong issues, and i think Angelo had posted a patch for that on lkml at one point, but it's been a while..
<lumag_>
on 630?
<konradybcio>
yep
<konradybcio>
let's see if i can dig up the relevant code that fixed 8998 and might have done the same for 630 (though as i had mentioned, i'm not 100% sure it did)