Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
mvlad has joined #dri-devel
fab has joined #dri-devel
tursulin has joined #dri-devel
paulk-bis has quit []
paulk has joined #dri-devel
<javierm>
robclark, tzimmermann: I noticed that "drm/msm: Make .remove and .shutdown HW shutdown consistent" ended in both drm-misc-next and drm-msm-next branches
<javierm>
robclark, tzimmermann: would be an issue and cause merge conflicts or should git be able to cope with that ?
itoral_ has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, no idea. let upstream deal with it
<javierm>
tzimmermann: Ok
<tzimmermann>
javierm, shouldn't we see such
<tzimmermann>
conflicts in linux-next first
<tzimmermann>
?
<javierm>
tzimmermann: I don't know if linux-next pulls both trees
<tzimmermann>
they pull drm-next at least
<javierm>
tzimmermann: but the conflict will happen in drm-next first since both drm-misc-next and drm-msm-next are merged through drm-next
<javierm>
tzimmermann, robclark: I just tried merging drm-msm-next-2022-09-22 tag on top of latest drm-next and git merge seems to be able to cope with it
<javierm>
we are good then I think. The commit is just mentioned twice in the git log
<pq>
ajax, linkmauve, I did not see MESA_pack_invert at Khronos, but maybe that's because I was explicitly looking at GL ES list, since Weston is a GL ES 2 app.
<pq>
ajax, linkmauve, since the ANGLE thing appeared in Mesa 20.3 IIRC, I think it's old enough.
kts has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
apinheiro has joined #dri-devel
lynxeye has joined #dri-devel
<tzimmermann>
javierm, thank you for testing this. what i meant is that in linux-next, we will see the conflict early enough to do something about it
<javierm>
tzimmermann: right. But what I meant that we would see it even before linux-next if there were some conflicts while merging it in drm-next
<javierm>
linux-next would be useful for conflicts between drm-next and other subsystems
<javierm>
tzimmermann: I now noticed that never answered in the patch thread that I pushed to drm-misc-next... so this is probably my fault :(
<tzimmermann>
oh! my mistake. drm-msm-next *is* a drm branch. somehow i thought it was another subsystem
<tzimmermann>
?
<javierm>
tzimmermann: yes, that's what I tried to say :)
kem has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
staticfinalpengu has joined #dri-devel
staticfinalpengu has left #dri-devel [#dri-devel]
kem has joined #dri-devel
fahien has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: let me know if my comment on your patch #5 doesn't make sense. But my understanding is that these drm_gem_fb_{begin,end}_cpu_access() are to synchronize dma-bufs
<javierm>
tzimmermann: or can simpledrm export GEM buffers as dma-buf for other drivers to import?
bmodem has joined #dri-devel
<dj-death>
anybody knows how to trigger a build of the ci scripts locally?
<dj-death>
like reproducing the build of debian/x86_build but locally
<MrCooper>
you can manually run the scripts using podman/docker/...
<MrCooper>
hmm, might be a bit more complicated though, since we're using ci-templates
<MrCooper>
why do you want to run it locally?
bmodem1 has joined #dri-devel
<dj-death>
takes forever on the CI
<dj-death>
I can't inspect anything
<dj-death>
I can do what, a try every 10/20mn or so
<emersion>
would sure be nice to be able to SSH into failed jobs…
* emersion
walks away
bmodem has quit [Ping timeout: 480 seconds]
<MrCooper>
dj-death: taking https://gitlab.freedesktop.org/mesa/mesa/-/jobs/28808126 as an example, in principle you should be able to launch a container using the quay.io/freedesktop.org/ci-templates:container-build-base-2022-09-02.0 image, then manually run the commands shown in the job output
<MrCooper>
that may not allow live interaction during the actual image build process with buildah though
sdutt has quit [Ping timeout: 480 seconds]
<MrCooper>
someone on #freedesktop might have a better idea
heat has joined #dri-devel
<dj-death>
the situation looks pretty dire to be fair
rgallaispou has joined #dri-devel
<dj-death>
none of distribution used ship llvm 13+
<dj-death>
upgrade debian is not an option
<dj-death>
some of the built stuff like libclc requires its own version of llvm
devilhorns has joined #dri-devel
bmodem has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
sarahwalker has joined #dri-devel
kts has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
<jcristau>
not sure if you're aware, or if it helps, but debian 11 gained llvm 13 recently
apinheiro has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<gawin>
can someone pull my mail from "mesa-dev" purgatory? thx
<emersion>
done
fahien has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
warpme___ has joined #dri-devel
lileo_ has quit []
srslypascal has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<javierm>
tzimmermann: I think that understand now. You need special code for DRM drivers to export dma-bufs but importing dma-buf is handled by the shmem GEM BO allocator
<javierm>
tzimmermann: so even when simpledrm uses a firmware provided scanout buffer is a real DRM driver and you could for example export as dma-buf let's say v4l2 buffers and import it in simpledrm to scanout?
<javierm>
tzimmermann: without your patch then you could have sync issues if doing for example: gst-launch-1.0 v4l2src io-mode=4 ! kmssink
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<gawin>
emersion: thanks
aravind has quit [Ping timeout: 480 seconds]
abws has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
pochu has quit [Quit: leaving]
kts has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
pcercuei has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
fahien has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit []
gawin has joined #dri-devel
kts has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
devilhorns has quit []
devilhorns has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
kts has quit [Quit: Leaving]
devilhorns has quit []
devilhorns has joined #dri-devel
* kisak
makes frustrated packager noises
<kisak>
I'm not seeing any way to get around having to carry an extra n-1 llvm build just for llvm-spirv and going from 4 builds to 11 builds per distro release to bootstrap
tzimmermann has quit [Quit: Leaving]
<kisak>
is llvm-spirv needed at runtime, or is it just a build dependency?
Lucretia has quit [Read error: No route to host]
Lucretia has joined #dri-devel
<robclark>
javierm: hmm, oops, usually try and avoid that.. git won't have a problem but makes history a bit more confusing.. oh well
<MrCooper>
jcristau: I understand dj-death's issue is with spirv-llvm-translator specifically; though I'm not sure what the big deal is, since we previously used a local build of that in CI, should be easy to resurrect
<javierm>
robclark: no worries, I also missed to mention in the list that pushed already. Sorry about that
<dj-death>
anybody seen a builder fail with this kind of error :
<dj-death>
../src/util/ralloc.c:873:7: runtime error: member access within misaligned address 0x55d6d2b2d508 for type 'struct gc_slab', which requires 16 byte alignment
<dj-death>
it's a runtime check failing
<dj-death>
of the offline compiler called during the build process
camus has quit []
<alyssa>
kisak: llvm-spirv is needed at runtmie for OpenCL
<alyssa>
For OpenCL, Mesa needs to compile C code (CL kernels) to the GPU at runtime
<alyssa>
The pipeline for that on modern drivers is:
<dj-death>
kisak: you might be interested in the few commits I have in my RT MR
<dj-death>
kisak: I got rid of the llvm-spirv packages and build it from source
<alyssa>
which means clang and llvm-spirv are runtime dependencies
<alyssa>
(and libLLVM and libclc)
<alyssa>
all those LLVM versions need to match
<alyssa>
ideally all LLVM 15, though I think LLVM 14 will also work at a huge performance penalty
<dj-death>
let's just bump to llvm15 so that we can benefit from spirv generation ;)
<alyssa>
does llvm generate spirv itself now?
<alyssa>
can we ingest that in rusticl and drop the llvm-spirv dep?
<alyssa>
that sounds great if so
<alyssa>
fwiw I don't expect NIR-based OpenCL to be ready in Mesa sooner than LLVM 15 is available in distros so there's also that.
sdutt has joined #dri-devel
<alyssa>
Iris and Panfrost should both be able to pass the CTS, but there's a long road to actual production
<alyssa>
(panfrost only on Mali-G57, figured I'd pick the easiest possible target to get my feet wet)
<karolherbst>
yeah.. I didn't try the LLVM spirv target yet
<karolherbst>
alyssa, kisak: llvm-spirv will also be needed for anv raytracing
<karolherbst>
so there is that
<dj-death>
karolherbst: happy to move to llvm generation if other do too
<karolherbst>
thing is.. it doesn't change much
<alyssa>
karolherbst: dj-death: do it! ^___^
<alyssa>
karolherbst: drops 1 dep, no?
<karolherbst>
yeah.. well.. that dep accounts for like 0.1% of the build time and pain
<alyssa>
maybe for from source or for distros
<alyssa>
from my perspective, it's the 1 dep that I have to build myself
kts has joined #dri-devel
<alyssa>
llvm-15 i can drop in from apt.llvm.org
<karolherbst>
mhh..
<kisak>
alyssa: so that dependency isn't expressed in any way in the debian/ubuntu packaging. https://packages.ubuntu.com/kinetic/libclc-15 doesn't pull llvm-spirv. All I'm seeing is the build time dependency in llvm-toolchain-15 which pulls llvm-spirv-14 which pulls llvm-toolchain-14.
jewins has joined #dri-devel
<karolherbst>
kisak: guess somebody broke it
<alyssa>
kisak: libclc doesn't runtime dep on llvm-spriv, mesa itself does for nir-based opencl
<alyssa>
afaik
kts has quit [Remote host closed the connection]
<alyssa>
but also afaik, nobody is shipping nir-based opencl yet, except for microsoft who are doing their own thing anyway
<karolherbst>
if you mix llvm versions then that's kind of on the distribution
<karolherbst>
alyssa: again.. anv needs it regardless
<alyssa>
karolherbst: ack
<alyssa>
is anv RT shipping yet either?
<karolherbst>
good question
MajorBiscuit has quit [Ping timeout: 480 seconds]
<alyssa>
I was under the impression it wasn't but I also haven't paid attention to the Intel stack since jekstrand left ;-p
<MrCooper>
this discussion started from the pending MR which adds RT support to ANV
<karolherbst>
yeah.. guess distributions have to make sure they don't break their llvm-spirv-translator packages then
<alyssa>
karolherbst: I guess buy-in from all the driver changes?
<karolherbst>
just bump it to 15 and it should go from 4 to 5 packages
<karolherbst>
alyssa: mostly, yes
<kisak>
I guess this is a mess for tjaalton and the debian llvm maintainers to figure out. This is too much for me. What I'd want to see is spirv-llvm-translator-# to go away and llvm-toolchain-15 to build llvm-spirv along with the rest of the package. The problem is that they're separate build jobs
<dj-death>
alyssa: trying to land it, once I sort all the CI madness
<karolherbst>
kisak: the translator has to be bumped to 15
<alyssa>
dj-death: Ah got it
<alyssa>
karolherbst: ack
<dj-death>
dammit
<dj-death>
the embedded is just not working with structure alignment requirements
<alyssa>
karolherbst: "gallium: split up req_local_mem" is r-b me, just not sure how much my r-b is worth for drivers I don't touch
<kisak>
karolherbst: so I'm back to my original problem. I have to bootstrap llvm, build spirv-llvm-translator separately, and rebuild the first version of llvm before any users can touch the llvm build. This is garbage.
<alyssa>
most sketchy part is the freedreno change
<karolherbst>
kisak: that's not true
<dj-death>
the iterator macros do some arithmetic with empty list and that breaks
<alyssa>
AFAIU freedreno+clover was working at some point at least a bit, but this will hose freedreno+rusticl pretty bad
<alyssa>
and possibly hose freedreno+clover too
<karolherbst>
well.. it might be true for broken packaging
<karolherbst>
but nothing in LLVM depends on the translator
<karolherbst>
once you have llvm, you can build llvm-spirv
<karolherbst>
and they should use the same base version
<alyssa>
karolherbst: Yeah, I think that commit will break freedreno cl on either clover or rusticl for different reasons
<kisak>
karolherbst: yes it is, because in Debian/Ubuntu, they're separate build jobs to be sent to the build farm, and files are missing for libclc in the llvm package the first time around.
<alyssa>
which means even with clover and no variable shared mem, we go from allocating local mem to allocating 0 local mem
<alyssa>
because of your clover change
<karolherbst>
kisak: sounds like broken packaging to me
<alyssa>
- cs.req_local_mem = mem_local;
<alyssa>
+ // we only pass in NIRs or LLVMs and both IRs decode the size
<alyssa>
+ cs.static_shared_mem = 0;
<kisak>
hence my frustration
<karolherbst>
libclc shouldn't be part of the llvm build job
fab has quit [Quit: fab]
<karolherbst>
it might work all out with the new llvm spirv target, but I don't know if libclc is updated to make use of it. Anyway
<karolherbst>
the solution is quite simple: 1. split libclc into its own build 2. build llvm-spirv after llvm and before libclc 3. build libclc
<alyssa>
ir3 will need compute shader variants for that commit to work with it
<alyssa>
robclark: ^^
<karolherbst>
alyssa: yeah... maybe
<alyssa>
definitely.
<alyssa>
ir3 depends on knowing the actual shared size when compiling the shadefr
<karolherbst>
I think I looked at the code and figured it's probably fine
<alyssa>
it's only fine because freedreno/opencl isn't shipping yet
<alyssa>
but it was working somewhat, and after this commit it won't be working at all (since *anything* using shared mem will break)
<kisak>
in any case, I'm done with this riddle. If people want working opencl with upstream debian, then that's something to be worked out without me bothering people anymore.
<kisak>
I'm now considering emergant OpenCL issues with the kisak-mesa PPA a non-starter
<alyssa>
kisak: I wish I knew enough about deb packaging to help :(
<karolherbst>
well.. as I said: it all comes from broken debian packages, so it needs to be brought up with the llvm maintainers there
<karolherbst>
and I showed what needs to be fixed
<pendingchaos>
dj-death: that gc_slab alignment thing sounds like it's my fault
<pendingchaos>
is this a non-x86 arch?
<alyssa>
pendingchaos: I don't think it can be, the intel stack doesn't build on non-x86 :(
<alyssa>
(much to my annoyance because sometimes I'd like to build test NIR/gallium/vulkan core changes)
<dj-death>
pendingchaos: no
<alyssa>
(Ideally every driver would build on every architecture...)
<dj-death>
pendingchaos: appears to be x86_64
<dj-death>
pendingchaos: it's only on the debian-vulkan test
<karolherbst>
does anybody here have ties to the debian llvm people? Not sure if that was ever brought up, but for ANV I guess it needs to be solved anyway
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<pendingchaos>
I guess that's not always working for some reason
<pendingchaos>
we try to allocate gc_slab with 16 byte alignment on x86_64
<dj-death>
pendingchaos: allocations are fine
<dj-death>
pendingchaos: I'm getting errors on empty lists
<dj-death>
pendingchaos: because the first of the pointer arithmetic in the iterator loop
<tjaalton>
kisak: is spirv-llvm-translator merged in llvm-15 now?
<tjaalton>
if so, great news!
<karolherbst>
tjaalton: it's not merged, it's new code
<kisak>
tjaalton: no, it's just a mess. Maybe you can coordinate with them on #debian-llvm?
<tjaalton>
karolherbst: what is new code? we've had spirv-llvm-translator packaged for a long time
<karolherbst>
yes, but the spirv support in llvm-15 is new code
<tjaalton>
okay
<karolherbst>
it's more of a target and you use it differently and all that
<karolherbst>
don't even know if it just works or not
<karolherbst>
sure, it all needs to be version locked
gawin has quit [Ping timeout: 480 seconds]
<tjaalton>
karolherbst: that's.. nice
<tjaalton>
-15 was released upstream after that
<karolherbst>
so?
<tjaalton>
sorry, meant kisak
<tjaalton>
about the llvm packaging change
<karolherbst>
anyway.. it's a debian packaging bug and debian needs to figure this out
<karolherbst>
should probably just enfore the version lock somewhere so people don't accidentally ship mixed versions
<tjaalton>
that shouldn't be possible
<karolherbst>
well.. but here is kisak running into this issue
<kisak>
I'm just ahead of the curve here.
<karolherbst>
the translators main branch usually always builds against the current llvm-release. So even if there is a ~9 day delay of a release, the git archive should build when the llvm release is done (or use the relevant release branch of the translator)
<karolherbst>
but anyway.. once llvm-15 is packaged, the translator should also get packaged for the same version
fahien has quit [Ping timeout: 480 seconds]
<karolherbst>
tjaalton: also.. it looks the libclc + llvm-spirv are kind of packaged in a weird way
<karolherbst>
libclc can't be part of the llvm source package anymore
<karolherbst>
libclc-15 is there, but that depends currently on the llvm-14 toolchain because of the llvm-spirv thing
<karolherbst>
and that depends on llvm14
<karolherbst>
anyway.. this is a terrible circular dependency
<tjaalton>
yes
<tjaalton>
I'll poke sylvestre, later
<tjaalton>
someone else is packaging s-l-t-15
<karolherbst>
cool thanks. though there is an alternative approach you could follow: move the spirv-llvm-translator into the llvm tree and build it alongside llvm
<tjaalton>
intel is always late to the game updating these ocl libs against latest llvm
<karolherbst>
which probably solves all this mess in an easier way
<tjaalton>
and that doesn't play well with the llvm maintainer doing snapshot/rc releases
<karolherbst>
right...
<karolherbst>
but the best approach here is to let it fail to compile
<karolherbst>
if there is a version mismatched is caught before anything reaches users
<tjaalton>
that's why I asked if the translator got merged upstream, my understanding is that it's WIP but maybe I'm mistaken
<karolherbst>
it's very much WIP
<tjaalton>
that's also why it's in experimental
<karolherbst>
the translator itself isn't WIP
<karolherbst>
just the SPIRV target inside LLVM
<karolherbst>
but if it's built there.. mhh.. though I suspect you can still package both
<karolherbst>
dunno
<dj-death>
finally all the builds passing
fab has joined #dri-devel
<karolherbst>
mhh.. not sure what "-DLLVM_TARGETS_TO_BUILD=Native" enables
<kisak>
karolherbst: to add salt into the wound, if libclc is split back out into a separate build, then it won't get focal/jammy/kinetic i386 builds due to the distro release i386 allowlist and will fail out the mesa build when that becomes required.
<karolherbst>
yeah.. then move the translator into the llvm build
kts has quit [Ping timeout: 480 seconds]
<dj-death>
hmmm crap
<dj-death>
the llvm upgrade apparently makes some changes in clover testing on llvmpipe
ybogdano has quit [Read error: Connection reset by peer]
gawin has joined #dri-devel
ybogdano has joined #dri-devel
jfalempe has quit [Quit: Leaving]
<dj-death>
DavidHeidelberg[m]: does your comment counts are Rb?
<DavidHeidelberg[m]>
currently it's more Ab, if you address comments, Rb for sure :)
<dj-death>
except for the debian thing, I think I addressed them all
lemonzest has joined #dri-devel
<DavidHeidelberg[m]>
dj-death: send few more ideas for the script, sorry for sending it in batchews
<DavidHeidelberg[m]>
*batches
<dj-death>
no worries
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
JohnnyonFlame has joined #dri-devel
<robclark>
pq, emersion: btw was chatting w/ abhinav__ earlier about adding solid-fill kms plane support.. one idea is userspace just attach a 1x1 fb to the plane, and driver detects the special case and reads back the color (alternatives are solid colorfill prop or special fb).. it occurred to me that you might have opinions from userspace PoV
<emersion>
robclark: it's a bit annoying to go through the alloc
<emersion>
i think intel has posted some series about this?
<emersion>
plane background color
* robclark
not finding it
<danvet>
I think it was crtc background color or something
<danvet>
until we agreed that all we wanted was black anyway
<robclark>
emersion: the nice thing about 1x1 fb is it is actually not any new uapi.. and it would work on hw that didn't have upscaling limits
<danvet>
and the solid fill would then be the u64 or something in the blob
<emersion>
w/ discussion about what to use for color values etc
<emersion>
t;dr 32-bit RGBA should be enough
<emersion>
i mean
<danvet>
getfb2 would need some opt-in flag I guess
<emersion>
RGBA32323232
<danvet>
emersion, blobs can be made biiiiiiiiiiig :-)
<emersion>
yup
<emersion>
a blob would be good for this
<danvet>
I'm not sure whether it's a Too Clever idea, so maybe sanity check how badly it blows up
OftenTimeConsuming has quit [Remote host closed the connection]
<emersion>
danvet: oh you mean arbitrary precision via blob size?
<danvet>
but getfb2 is about the only one, and I think that could just fail if you don't set a flag or something
<danvet>
emersion, ah maybe not _that_ clever :-)
<emersion>
ah, good
<emersion>
seemed a bit much
<danvet>
just if you feel like rgba64646464 that's doable too
<robclark>
not sure about special fb.. not sure if we cause too much confusion about fb->obj[0]==NULL
OftenTimeConsuming has joined #dri-devel
<danvet>
robclark, yeah that's a bit my fear, keeping the fb around just means we push it down one level for most drivers
<danvet>
since everything except vmwgfx is gem and most use helpers now
<danvet>
robclark, internally I think drivers should just access a plane_state->solid_fill_color or so, with plane_state->fb being null in that case
<danvet>
the solid fill blob would just be uapi
<robclark>
I guess there are limited # of places where we go from obj id to obj so might not be too bad to handle the special case at the setprop level..
<robclark>
it does mean that what "looks" like what is going on is very different from the way it actually works
<danvet>
robclark, helper/core don't have a lot of these checks, and driver would need to opt-in anyway
<danvet>
and generally drivers don't replicate !!rb == !!crtc checks since core does that
<danvet>
so it shouldn't be a lot of work I think
<robclark>
yeah, the !!rb == !!crtc checks are I think just a couple spots in the helpers
<vsyrjala>
next someone gets to implement this with a replicated dummy page, and either fill that with the color, or just use some plane lut or something to pretend it's not scanning out memory at all
ngcortes has quit [Remote host closed the connection]
<danvet>
vsyrjala, anything that doesn't avoid the memory reads seems a bit silly for this
<robclark>
yeah, I'd just let atomic-check fail if driver didn't support it
ngcortes has joined #dri-devel
<vsyrjala>
maybe. would have a very good tlb hit rate though. also could use exterme upscaling to minimize the memory reads
<ajax>
one dword per frame doesn't seem too burdensome
carbonfiber has joined #dri-devel
<dj-death>
DavidHeidelberg[m]: you only have reservations on the last patch? "ci: disable no-sanitize-recover=all from debian-vulkan"
<vsyrjala>
robclark: what hw has this btw?
apinheiro has joined #dri-devel
<robclark>
the plane solid fill color? qc / msm/dpu
<vsyrjala>
and it actually disables memory fetch? ie. not just some test thing to force it to output solid color
<DavidHeidelberg[m]>
dj-death: I don't know enough to say it's fine :)
<robclark>
I believe it is similar purpose to the crtc solid fill color... older gens of qc had a solid fill in the crtc (but it consumed a mixer slot, so in that way it was similar to a plane)
<robclark>
but abhinav__ knows the hw side of display block better ;-)
<dj-death>
DavidHeidelberg[m]: okay, but the first 5 are Rb?
<danvet>
vsyrjala, yeah I guess ridiculous upscale might work
<danvet>
if the hw doesn't refetch every line :-)
<vsyrjala>
unfortunately at least on intel hw scalers are a scarce resource, so wasting them on random stuf might not be a great idea either
jkrzyszt has quit [Ping timeout: 480 seconds]
rgallaispou1 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
rgallaispou has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
<linkmauve>
emersion, I don’t quite understand this single-pixel-buffer protocol, we already could do that in a very slightly more cumbersome way by using a 1×1 wl_shm buffer.
mvlad has quit [Remote host closed the connection]
<linkmauve>
Compositors could (and IIRC Weston does) optimise that into a solid color fill or even clear.
<linkmauve>
And even if they don’t, texturing from a single texel is quite cheap.
<daniels>
yes please to FB from pixel values
<daniels>
linkmauve: saves the mapping
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
tjaalton has quit []
<linkmauve>
Right, and one fd.
<jekstrand>
Is there a helper for converting PIPE_FORMAT <-> fourcc?
<zmike>
I think it's all hardcoded?
<jekstrand>
:(
<zmike>
it's a feature
pcercuei has quit [Quit: dodo]
apinheiro has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Duke`` has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<abhinav__>
robclark vsyrjala sorry was away for a while. Yes this does disable memory fetch
<abhinav__>
robclark so are we going to go ahead with a plane property
<abhinav__>
and relax the conditions for !fb
<abhinav__>
if the driver supports solid_fill property
carbonfiber has quit [Quit: Connection closed for inactivity]
<robclark>
abhinav__: kinda.. the proposal was that userspace creates a blob property with the solid fill color, and then attaches the blob-prop id to the plane's FB_ID
<robclark>
then in plane's atomic_set_prop path, for FB_ID check if the obj looked up from id is an fb or blob-prop, and either set plane_state->fb or plane_state->solid_fill (and fixup the !!plane_state->fb == !!plane_state->crtc checks to also consider the solid_fill)
<robclark>
so from userspace PoV it is kinda just a special kind of fb but for drivers it looks more like a plane prop
<abhinav__>
robclark thanks for summarizing it. Understood. From the initial proposal statement, this looks fine to me and should work .... we can write up a RFC for this