<mripard>
jani: and so the plan is still to send both drm-misc-next and drm-intel-next to drm-next, and backport drm-next once both have been merged?
<tzimmermann>
javierm, i have only briefly followed the discussion. IMHO the DT is the authoritative source
<tzimmermann>
what ard says about tracking framebuffer memory is exactly what we do in our aperture code
<tzimmermann>
as you mentioned
<javierm>
tzimmermann: agreed on both items. I agree that the patch is a workaround but IMO is the least bad option because a) is a stopgap to fix the issue and b) it's simple enough that can be cherry-picked for stable
<jani>
mripard: if I understood sima correctly, yes
<javierm>
tzimmermann: the question I had if you can think of another way to handle this due ard saying that isn't a great approach
<javierm>
tzimmermann: another option that I thought could be to make sysfb DT aware and check if there's a simple-frambuffer node present, but that sounds even a worse approach to me...
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
pcercuei has joined #dri-devel
tursulin has joined #dri-devel
<kode54>
wow
donaldrobson has joined #dri-devel
<kode54>
was it redhat that asked for vp9 and av1 to be added to the patent encumbered codecs list?
<sima>
javierm, I feel like the entire sysfb complexity has reached levels that are firmly above my head :-/
<sima>
but yeah using the aperture helpers to make sure we only have one sysfb instance feels a bit icky
<sima>
what you might want to do (but that could blow up in entirely different ways) is the resource reservation framework, with a mandatory resource
<javierm>
sima: yeah... same. The sysfb design has reached its limits
<sima>
but that might prevent the real drivers from loading properly
aravind has quit [Ping timeout: 480 seconds]
<sima>
so probably not the right thing either
<sima>
at least we tried using that somewhat in i915 for making sure we only use the stolen memory range when the bios hasn't butchered the setup somehow
<javierm>
sima: long term I think that the aperture infra should be part of the device model and hooked into the request_mem_region() helpers
<sima>
and it was endless pains
<sima>
javierm, well request_mem_region kinda is aperture helpers
<javierm>
e.g: request_mem_region_exclusive() or someting
<sima>
except see above, request_mem is also utter levels of pain
<sima>
yeah that's what I was thinking of
<sima>
we tried that for i915 stolen
<javierm>
sima: yeah but doesn't have the "remove conflicting devices" part
<javierm>
it just -EBUSY
<sima>
for entertainment dig into git history :-)
<sima>
javierm, well that too, so that part would need to be added
<javierm>
sima: ah, I see
<sima>
javierm, so yeah, my "I'm absolutely in way over my head" gut feeling is that a) yes this hack is very, very icky but also b) everything else is so much worse
<javierm>
sima: right. Do you agree then with tzimmermann and my opinion on this, to merge this workaround and then figure out how to better handle this long term?
<sima>
I think we're very firmly in "least terrible" design space here :-(
<javierm>
sima: yeah... agree
<sima>
javierm, yeah feel free to add an a-b: me onto that, and maybe try to capture some of that "yes this is terrible" understand as much as we can still grasp it ...
<javierm>
sima: that's the buffer damage series we discussed before but using a slightly different approach suggested by tzimmermann
<javierm>
basically to set the plane->ignore_damage_clips = true in the .atomic_check for drivers that need it
<javierm>
I've ack from Thomas and Zack @ VMWare, but didn't want to push before asking you. Since you suggested the previous approach
<sima>
javierm, patch 4 doesn't really explain when you have the buffer damage case
<sima>
or is a bit unclear
<sima>
so maybe add a sentence that we need to ignore damage and fall back to full damage when the buffer, i.e. &drm_plane_state.fb has changed, and that as long as when that buffer stays the same, buffer damage tracking drivers can still benefit from the damaged regions
<sima>
currently it reads a bit as if you need to unconditionally set this flag
<sima>
you kinda have that in the last paragraph, but I'd just add the very specific "this is the state structs members you need to look at" explainer in the previous paragraph
<sima>
oh for the todo entry maybe reference the &drm_plane_state.ignore_damage_clips entry
<sima>
and maybe also add a link to the overall docs from the kerneldoc for that in patch 1
<sima>
with these doc bikesheds: a-b: me, looks like a clean approach from a code pov
<sima>
and defo less work :-)
<sima>
easier to backport too since smaller, and all that good stuff
<javierm>
sima: sure. I'll make those fixups and post a v4 likely tomorrow. Thanks for your feedback!
<enunes>
emersion: so even with the accelerated pixman backend for wlroots I can't use a vulkan only driver because it still relies on gbm to import buffers from clients, even if I hack it a bit to use the dumb buffer allocator to avoid gbm for compositor allocation
<enunes>
I don't suppose there will be any other quick hack to avoid that one?
<emersion>
enunes: hm it shouldn't do that?
<emersion>
which wlr version is this?
<emersion>
actually it never used GBM to import client buffers AFAIK
<emersion>
it uses GBM to allocate GPU buffers, but if you're running with Pixman it shouldn't pick GBM?
<enunes>
it does going through the types/wlr_linux_dmabuf_v1.c path, this is the patched version 0.16.0 originally for the raspberry pi case
<jani>
sima: writing the changelog always takes me longer than I think... and I wonder if anyone ever reads them :/
<jani>
further than the highlights
<sima>
I do read them when doing the pull ...
Sumera[m] has joined #dri-devel
<sima>
imre, 191dc43935d1ece82bc6c96 thx for making that fail on compile when I get it wrong :-P
<imre>
yep, that conflicts in dm_helpers_construct_old_payload(), I resolved that based on the email I sent. but in general it should've been merged via drm-misc-next
<sima>
yeah I intentionally got it wrong just to see how gcc gets unhappy :-)
jkrzyszt has joined #dri-devel
JosExpsito[m]1 has joined #dri-devel
gouchi has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
yshui` has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
tomba has quit [Ping timeout: 480 seconds]
znullptr[m] has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.1]
jsa has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
fkassabri[m] has joined #dri-devel
shoffmeister[m] has joined #dri-devel
jsa has quit []
Duke`` has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
fab has quit [Quit: fab]
crabbedhaloablut has quit []
Ella[m] has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
aljazmc has quit [Remote host closed the connection]