ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<Jeremy_Rand_Talos> airlied, so, I'm from the Talos Workstation community; some of us are on up to 176 hardware threads; it would be nice to be able to actually leverage that with llvmpipe.
<airlied> now the tests that have vertex heavy workloads stall out on binning a lot
<airlied> Jeremy_Rand_Talos: it probably comes down to memory b
<airlied> bw
<ajax> then... yeah pretty much all you have left for llvmpipe perf is either smarter image layouts or reducing the cost of binning
<airlied> ajax: threaded binning was a vague handwave I had
<airlied> but I'm not so sure how to make that a thing
<ajax> i think swr had a multiply-and-surrender approach to that
<airlied> smarter image layouts would be something if you could figure out what would work on a modern CPU
<airlied> like you'd have to know where things are having cacheline pains
<ajax> 2x2 microtiles and page-sized macrotiles would go a long way
<ajax> or rather: i don't think there's much to be gained beyond that
* airlied wonders if vmware had that at one point, and didn't see enough throughput changes
<airlied> though someone suggested tiled framebuffers might be a better win
<Jeremy_Rand_Talos> airlied, has it been considered whether memory bandwidth is still the bottleneck regardless of architecture? My loose understanding is that POWER9 often has better mem bw than x86_64.
<airlied> Jeremy_Rand_Talos: again it depends on the load being tested, adding more threads with a complex fragment shader might show where things stop scaling
<airlied> like power9 might have more mem bw, but it still might get saturated
<Jeremy_Rand_Talos> airlied, "memory bandwidth on fragment shader execution" <-- what function name(s) would this show up as in perf?
<airlied> Jeremy_Rand_Talos: it will show up as some JIT code
<airlied> unfortunately that is another problem, getting JIT debugging going properly is kinda not there
<airlied> so it's not that easy to spot where the bottlenecks are
<airlied> I've never really figured out the best way to close that gap
<Jeremy_Rand_Talos> airlied, ah, ok. So if I can find some bottleneck function in perf that's not marked as JIT, that would be likely to be lower-hanging fruit?
<airlied> Jeremy_Rand_Talos: yes
<airlied> esp if it's in the main thread not one of the side threads
<Jeremy_Rand_Talos> airlied, I see, that's good info to have.
mbrost has quit [Ping timeout: 480 seconds]
<airlied> but yeah digging into anything that could make jit more debuggable might be a useful task
lemonzest has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
Duggan has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Ping timeout: 480 seconds]
pixelcluster has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
pixelcluster has joined #dri-devel
karolherbst has joined #dri-devel
Surkow|laptop has joined #dri-devel
bluepqnuin has quit []
MatrixTravelerbot[m]1 has quit []
dafna33[m] has quit []
colemickens has quit []
LaughingMan[m] has quit []
karolherbst has quit [Quit: Konversation terminated!]
heat has quit [Ping timeout: 480 seconds]
chrisf has joined #dri-devel
aravind has joined #dri-devel
sdutt has joined #dri-devel
Company has quit [Quit: Leaving]
epoll has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
mhenning has quit [Quit: mhenning]
karolherbst has quit [Quit: Konversation terminated!]
epoll has joined #dri-devel
karolherbst has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Duggan has quit [Ping timeout: 480 seconds]
dsrt^ has joined #dri-devel
aravind has joined #dri-devel
Duke`` has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
dcz_ has joined #dri-devel
chrisf has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
aravind has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
karolherbst has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
mvlad has joined #dri-devel
frieder has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
moony has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
tursulin has joined #dri-devel
<dj-death> would it be correct to assume that an SSA def in NIR is only used by a single phi instruction?
srslypascal has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
jkrzyszt_ has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2416
lynxeye has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
mattst88 has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
Net147 has quit [Read error: Connection reset by peer]
fahien has joined #dri-devel
Net147 has joined #dri-devel
pcercuei has joined #dri-devel
ahajda has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #dri-devel
apinheiro has joined #dri-devel
illwieckz has joined #dri-devel
sumoon is now known as Guest2420
sdutt has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
<Jeremy_Rand_Talos> airlied / ajax, would it be OK if I post the log of the above llvmpipe multithreading conversation on the Talos Workstation wiki? I think it would be helpful to some of our community members who would like to improve things.
srslypascal has joined #dri-devel
srslypascal has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
cleverca22[m] has quit []
lemonzest has joined #dri-devel
<pendingchaos> dj-death: no, a SSA def can be used by multiple phi instructions
<dj-death> pendingchaos: thanks
pH5 has quit [Ping timeout: 480 seconds]
pH5 has joined #dri-devel
<FLHerne> Jeremy_Rand_Talos: note the channel is already publically logged here https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2022-10-05
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<Jeremy_Rand_Talos> FLHerne, ah, thanks, that works for me.
dcz_ has quit [Ping timeout: 480 seconds]
<FLHerne> well, I can't see an objection to copying it to your wiki if it's public already
ahuillet has joined #dri-devel
Leopold__ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
Eighth_Doctor has joined #dri-devel
rgallaispou has joined #dri-devel
Leopold__ has quit []
Danct12 has quit [Read error: Connection reset by peer]
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
<eric_engestrom> XDC day 2 starts in exactly 1 hour!
<eric_engestrom> Stream available here: https://www.youtube.com/watch?v=yTO8QRIfOjA
<eric_engestrom> Matrix room (for discussions & questions to presenters): https://matrix.to/#/#xdc2022:matrix.org
fahien has quit [Quit: fahien]
apinheiro has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
Dr_Who has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
sdutt has joined #dri-devel
tintou has quit []
karolherbst has joined #dri-devel
srslypascal has joined #dri-devel
<emersion> oh, i thought there was the mupuf talk before isaspec?
jewins has joined #dri-devel
<emersion> robclark: this makes me think of https://kaitai.io/ a bit
<emersion> robclark: with insight, was XML a good pick, instead of e.g. a DSL?
<eric_engestrom> emersion: "the mupuf talk" is a discussion and it's happening on this jitsi: https://workshops.ivyl.gg/CIWorkshop
srslypascal has quit [Quit: Leaving]
<emersion> oh it's a workshop
<emersion> i completely missed that, my bad
kts has quit [Quit: Konversation terminated!]
<emersion> eric_engestrom: do you know if all workshops will be available on jitsi?
<daniels> eric_engestrom: they should be yeah
gawin has joined #dri-devel
<emersion> awesome
<ajax> Jeremy_Rand_Talos: feel free
<ajax> airlied: i kind of feel like the only untiled images in llvmpipe should be winsys surfaces and the in/output of Read/DrawPixels
<robclark> emersion: thx I'll look at that..
<robclark> emersion: re: xml.. well, the <expr>foo &amp;&amp; 0xf</expr> type stuff kinda sucks.. otoh I guess some things that might be a reasonable extension (like mixins) could probably be done as xml transforms
<emersion> ah, right, escaping…
karolherbst has quit [Quit: Konversation terminated!]
fab has quit [Quit: fab]
kem has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
kts has joined #dri-devel
itoral has joined #dri-devel
srslypascal has joined #dri-devel
kem has joined #dri-devel
tzimmermann_ has joined #dri-devel
heat has joined #dri-devel
pcercuei has quit [Quit: Lost terminal]
tzimmermann has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
tzimmermann_ has quit []
tzimmermann has joined #dri-devel
<tzimmermann> jfalempe, hi. have you committed the ast gamma patch?
fab has joined #dri-devel
robert_mader has joined #dri-devel
iive has joined #dri-devel
mbrost has joined #dri-devel
<robert_mader> daniels: Regarding my issue with llvmpipe / LIBGL_ALWAYS_SOFTWARE=1 and EGL_EXT_image_dma_buf_import_modifiers - turns out that the later is advertised for the GBM platform. Does that make sense to you? Or is that a clear bug?
<emersion> robert_mader: the GBM plateform with which DRM node?
<robert_mader> P.S. The driver is kms_swrast instead of swrast
<robert_mader> emersion: is there a way to tell from `eglinfo`?
<emersion> i have no idea how eglinfo picks one
<emersion> but you need one to initialize the GBM platform
<bl4ckb0ne> iirc it picks all
<robert_mader> I suppose it's actually my AMD card, i.e. /dev/dri/renderD128, but the amdgpu init code fails and falls back to kms_swrast or so
<emersion> that's weird
<emersion> maybe it tries to use the primary node instead of the render node?
<jfalempe> tzimmermann, not yet.
<tzimmermann> well, go ahead if you like
<jfalempe> tzimmermann, I'm investigating some poor performances with aspeed, remote BMC, and Gnome/Wayland.
<tzimmermann> oh, well!
<tzimmermann> how bad is it?
<jfalempe> you mention you've converted the driver to shmem
<tzimmermann> javierm, one sec
<jfalempe> it is like 0.2 FPS from BMC, so really unusable
<swick> daniels: where does one find the link for a specific workshop?
<robert_mader> emersion: but just for the record - kms_swrast is supposed to support EGL_EXT_image_dma_buf_import_modifiers? From a quick look it does indeed look like it should.
<dianders> Hi! I'm probably confused, but I just pushed to drm-misc-next (via `dim push-branch drm-misc-next`) and I noticed it say: `Out of merge window. Pushing drm-misc-next to for-linux-next`. Is this accurate?
<tzimmermann> jfalempe, that's terrible. i'm in the process of converting it, but haven't done so
<tzimmermann> because there is a regression that needs to be fixed first
<jfalempe> each time we change the gpu addr in ast_primary_plane_helper_atomic_update(), the BMC output freezes for 5s
<emersion> robert_mader: i am not sure tbh
<tzimmermann> jfalempe, then I might have a patch already :)
<emersion> my gut feeling would be yes, since there is a DRM node to play with
<jfalempe> tzimmermann, good news, I only have an awful hack, that don't swap buffers (so only display half of the frames)
<javierm> tzimmermann: sure, there's no rush. Just making sure that it didn't fell from your radar :)
<tzimmermann> jfalempe, converting to shmem can solve this problem. we won't have to update the gpu address very often
<emersion> swick: which workshop?
<emersion> hm, i don't see links anywhere
<tzimmermann> jfalempe, maybe try the patcheset i linked, specifically the first patch. once it has been merged, i'll hurry with the shmem patchset. it's done and waits for the regression fix to land
<swick> emersion: mostly asking for the HDR one tomorrow
<tzimmermann> jfalempe, thanks for bringing this to my attention
<emersion> swick: presumably it will appear in https://workshops.ivyl.gg
<tzimmermann> 5s delay is crazy
<emersion> hm
<emersion> nvm
<jfalempe> tzimmermann, ok will do that, thanks
<danvet> tzimmermann, did you see the comment from dianders about drm-misc-next going to linux-next instead of drm-misc-next-fixes?
<emersion> i see the CI workshop in there but probably it's because i've joined it
<emersion> via a link
<danvet> mlankhorst, probably more for you I guess
<jfalempe> yes I think the BMC is resetting the video stream when the gpu address changes.
<tzimmermann> danvet, no
flto has quit [Remote host closed the connection]
<danvet> <dianders> Hi! I'm probably confused, but I just pushed to drm-misc-next (via `dim push-branch drm-misc-next`) and I noticed it say: `Out of merge window. Pushing drm-misc-next to for-linux-next`. Is this accurate?
<danvet> tzimmermann, ^^
<tzimmermann> javierm, this looks good. let me ack on the list
flto has joined #dri-devel
<swick> hwentlan_: do you know about the jitsi thing for your workshop tomorrow?
<javierm> tzimmermann: perfect, thanks!
<dianders> tzimmermann: I can give fuller logs if needed. ;-)
<tzimmermann> danvet, dianders, what's confusing?
ella-0_ has joined #dri-devel
<dianders> tzimmermann: Aren't we in the merge window?
<dianders> ...at least I saw v6.0 was released...
* danvet betting on drm-misc-next-fixes not rolled forward
<daniels> robert_mader: heh, right - it's because it runs on GBM, so it sees that the device is dmabuf-capable, so src/gallium/frontend/dri/dri2.c enables the dmabuf ext
Duke`` has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
<daniels> robert_mader: in fairness, there's no reason why llvmpipe can't support it? linear is a valid modifier, you can mmap dmabufs ...
ella-0 has quit [Read error: Connection reset by peer]
<tzimmermann> dianders, good point. i have no idea what exactly the scripts test for TBH
<tzimmermann> danvet, we should forward it then
<dianders> tzimmermann: OK. Presumably at this point drm-misc-next shouldn't be flowing into linux-next. Someone else I should report this to?
<danvet> tzimmermann, dim uses the relationship between the branches (i.e. forwarded or not) to make that decision
<danvet> from the link "During the merge-window blackout, i.e. from -rc6 on until the merge window closes with the release of -rc1, try to track drm-next with the -next-fixes branch. Do not advance past -rc1, otherwise the automagic in the scripts will push the wrong patches to the linux-next tree."
<emersion> robert_mader: if you want to check whether EGL is using software rendering, there's an EGLDevice incantation to do that, fwiw
<robert_mader> daniels, emersion: right, I'm currently checking if this is indeed the right track. IIUC the issue currently is that llvmpipe doesn't implement the function required by the extension -> crash on use. And sure, one can check for the mesa-private string, but I guess that shouldn't be necessary (but might work as a workaround in the meantime).
<emersion> robert_mader: there's a more reliable way https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/egl.c#L299
<emersion> robert_mader: but yeah a crash would be a mesa bug for sure
<emersion> which function?
<emersion> do you have a backtrace etc?
<robert_mader> emersion: eglQueryDmaBufFormatsEXT and eglQueryDmaBufModifiersEXT
<emersion> ouch
<daniels> robert_mader: yeah, I mean the ideal would be fixing Gallium, either to not advertise it when it isn't actually there, or to just implement it :P
<robert_mader> Yeah, will give implementing it a go :P Maybe just not advertise any supported formats/modifiers?
<emersion> it would be better to not advertise in this case
<emersion> if you want to implement it, advertise support for LINEAR
<robert_mader> emersion: unfortunately I don't have a good backtrace yet, it's all vague thoughts I extracted from CI crash logs :/
<robert_mader> but will try to confirm with a reproducer now
<emersion> cool
<emersion> CI environments are pretty different from regular workstations
<robert_mader> virtio is apparently part of the mix here...
<tzimmermann> javierm, i won't have time now. please add my a-b to the patch
<emersion> robert_mader: if you want a "dumb" DRM node to give to the EGL GBM platform, you can look into vgem
<emersion> (to reproduce)
<daniels> robert_mader: heh yeah, that would give weston as drm master
<daniels> (or whatever in CI that's crashing)
mbrost_ has joined #dri-devel
<robert_mader> chromium...
<robert_mader> chromeOS actually
<daniels> ahhh, right
mbrost has quit [Ping timeout: 480 seconds]
<robert_mader> (context is to implement linux_dmabuf v3/v4 in Exo/chromeOS and the CI is giving me hell :P)
thaytan has quit [Ping timeout: 480 seconds]
agx has quit [Remote host closed the connection]
agx has joined #dri-devel
fxkamd has joined #dri-devel
<jfalempe> tzimmermann, I just pushed the ast gamma patch.
kj_ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
kj has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
kj_ is now known as kj
simon-perretta-img has joined #dri-devel
userbyte has joined #dri-devel
userbyte has quit []
zlice has joined #dri-devel
Guest2416 has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
zlice has quit []
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
zlice has joined #dri-devel
<zlice> messing around with 22.2 and was told you have to config with `-Dvideo-codecs=...` for vaapi to pick up things like h264. but it doesnt seem to work since vainfo only has maybe 6 things and is a dozen or more with 22.1.7. something i'm missing?
<psykose> could you post a before/after vainfo and the meson invocation for the build
<psykose> (in a pastebin)
<zlice> im using void-linux xbps-src, i could try a vanilla build. h/o ill get vainfo
<emersion> yay for VESA specs
<emersion> thanks VESA
zlice has quit [Quit: Leaving]
<emersion> thanks bill
<ajax> yay! thanks!
zlice has joined #dri-devel
JohnnyonFlame has joined #dri-devel
ybogdano has joined #dri-devel
<psykose> well, that build doesn't pass video-codecs, so the result is as expected
<ajax> zlice: if you used that to build 22.2, it doesn't have a -Dvideo-codecs option in the meson setup
<zlice> no that one doesnt, but ive added -Dvideo-codecs and it doesnt change
<ajax> what exactly did you add?
<zlice> ill pastebin the one i just used, one sec
<ajax> that... ought to work, i'd think
<psykose> if configure_args does what it says it does, and you are sure you installed that after building it, then it should work
<psykose> so probably it's not the one actually installed
itoral has quit []
<zlice> hm...im wondering if it's doing something weird because i'm in a branch
fxkamd has quit []
devilhorns has quit []
zlice has quit [Quit: Leaving]
MajorBiscuit has quit [Read error: Connection reset by peer]
zlice has joined #dri-devel
<zlice> sigh yep. the package is in its own directory.
<zlice> thx all
<robert_mader> emersion, daniels: so it turns out that kms_swrast (using the primary node) does actually implement eglQueryDmaBufFormatsEXT and eglQueryDmaBufModifiersEXT. eglQueryDmaBufFormatsEXT also returns the formats supported by the hardware - but eglQueryDmaBufModifiersEXT returns zero modifiers. Does that imply it supports the invalid modifier?
<emersion> yes
<ajax> zlice: np, glad we could help
zlice has quit []
<robert_mader> emersion: thanks!
mhenning has joined #dri-devel
Leopold_ has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
Nimr-alIslam has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.4.1]
rcf has joined #dri-devel
devilhorns has joined #dri-devel
gawin has joined #dri-devel
Nimr-alIslam has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this in error. (2022-10-05 18:17:27)]
oneforall2 has quit [Ping timeout: 480 seconds]
<emersion> siqueira: thanks a lot for doing that amdgpu doc work!
<emersion> ahah, my bug report is in a presentation
tzimmermann has quit [Quit: Leaving]
<emersion> ah, 3D LUT \o/
<emersion> oh, writeback \o/
fxkamd has joined #dri-devel
<pinchartl> do we have an API for 3D LUTs in KMS these days ?
Leopold_ has quit [Remote host closed the connection]
<emersion> see the next talk ;)
<emersion> okay, the one after the next
karolherbst has joined #dri-devel
<emersion> ah no, it really is the next
* emersion confused
<emersion> oh, different tracks…
<zmike> mupuf: I blame you for not reminding me to upload my slides
* pinchartl looks at the time table
Haaninjo has joined #dri-devel
<emersion> pinchartl: i've seen 3D LUTs pentioned
<emersion> mentioned in the workshop tomorrow
<pinchartl> are the workshops live-streamed ?
<vsyrjala> someone should fix 1d luts first
<emersion> pinchartl: yes :)
<emersion> and you can even participate
<pinchartl> emersion: nice !
<pinchartl> hmmm I'll have to skip the first 45 minutes :-( I'll have a conflicting meeting
<swick> someone should fix KMS first :p
<emersion> "redder"
<emersion> ah, here comes the color management wording
oneforall2 has joined #dri-devel
<emersion> why are the two not the inverse of each other?
<emersion> content creators like to fiddle with the TF?
<emersion> ah, right, i915 wants a lot of LUT points just to sample them in one segment and discard most in other segments
<karolherbst> zmike: mind implementing load_global and store_global?
Kayden has quit [Quit: reboot to change kernels]
<emersion> i get bug reports about blending in linear space -_-
<emersion> (ie, people find that correct blending looks bad…)
<emersion> watching XDC > watching netflix
Kayden has joined #dri-devel
<pinchartl> will HDR content always provide the EOTF for the kernel to calculate the EOTF^-1, or would be end up going from EOTF^-1 to EOTF in userspace to then convert back to EOTF^-1 in the kernel ?
<emersion> 3D LUT on non-linear, oof
<emersion> that's an interesting twist
<zmike> karolherbst: huh?
<emersion> that diagram is not controversial: on the kernel side there are two drivers: "amdgpu", and "…" :D
<karolherbst> zmike: in nir_to_spirv
<zmike> what happened to passing the shader directly
<karolherbst> that's why you get nir_intrinsic_load_global?
<karolherbst> it takes the 64 bit address as the source
gawin has quit [Ping timeout: 480 seconds]
<mupuf> zmike: sounds fair! Thanks for offering your Steam Deck to the CI gods!
<zmike> 👍
<karolherbst> ohh, passing the shader directly
<zmike> karolherbst: I meant with a pnext
<zmike> or just spirv directly
<zmike> once you get me that I can do something
<karolherbst> right... I am still wondering about that, but nir_to_spirv looks "good enough" for now and it doesn't really change that much
<karolherbst> could probably just skip most passes
<karolherbst> and we don't have to adjust vulkan drivers for now
<zmike> if that's really all it needs then I guess why not
devilhorns has quit []
<karolherbst> the ubo lowering shifts the offset a little, but I can hack that out
<emersion> hwentlan_: that mpv diagram is correct AFAIK
<karolherbst> but for now for clinfo everything seems fine. I have a rusticl/zink branch with some stuff
<zmike> karolherbst: I don't think ubo emission will work at all if you hack that out
<karolherbst> zmike: I meant the shift
<zmike> the shift is expected
<karolherbst> mhh..
<karolherbst> maybe it just works then
<zmike> let me see if I can do this easily
<emersion> get HDR with these 3 simple steps
bgs has quit [Remote host closed the connection]
<clever> emersion: what if you just put your non-linear LUT into a texture, where the X coord into the texture was just the input value, and the value within the texture is your non-linear ramp?
<pinchartl> clever: as Harry mentioned, we want to bypass shaders and use fixed-function hardware as much as possible to save power
<clever> ahh
<clever> same reason i shake my head every time i see the rpi 3d core being used for composition
<clever> the 2d core can already do composition and even LUT's
<emersion> hm, 3D LUT protocol, interesting
<emersion> hwentlan_: is it easy to combine multiple 3D LUTs together into one?
<emersion> i guess it is easy
<emersion> maybe more complicated if the dimension differs
<pinchartl> emersion: it may be tricky to get enough precision. the size of the 3D LUT is fairly small (as the number of items is N³)
<emersion> hm, so we really want all of CTM, 1D LUT, and 3D LUT?
<vsyrjala> and then figure out which order those happen on which hw
<clever> for vc4 hvs, i think the lut is just a single uint8_t[256], and r/g/b each go thru the same table?, but i need to confirm things still
<emersion> right, fun stuff
<clever> for bcm2711 hvs, the hardware now has 10bit support, but the lut is still 256 long, so it has to do linear interpolation between points
devilhorns has joined #dri-devel
<clever> so there will be some error on your log curve, due to only using 256 points on the log curve, and linear between points
<emersion> ah, dat last bullet point
<emersion> clever: what about the 3D LUT?
<clever> i dont know about the 3d lut side
<emersion> ok
<emersion> ❤️
<airlied> zmike: not sure if you should have wrapped the nvk slide in </s> tags :-p
<clever> pinchartl: oh, speaking of the rpi, i recently got hw accelerated yuv working: https://www.youtube.com/watch?v=xetQIdKBRS0
<zmike> airlied: enjoy the free publicity
gawin has joined #dri-devel
<pinchartl> clever: nice :-)
<clever> pinchartl: the fixed-function pipeline also accepts a conversion matrix for the yuv->rgb operation
<clever> complete with more typos in the comments
<clever> 1011/1014 claim to both be an offset for CB, but the math says Cr in one
<pinchartl> hwentlan_: nice talk
robert_mader has quit [Quit: Leaving.]
dcz_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
h0tc0d3 has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
lileo_ has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
fab has quit [Quit: fab]
lemonzest has quit [Quit: WeeChat 3.5]
lileo_ has quit []
lileo has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
sdutt has quit []
sdutt has joined #dri-devel
mbrost_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
devilhorns has quit []
Duke`` has quit [Ping timeout: 480 seconds]
<jessica_24> hey robclark, vsyrjala: so I'm working on the RFC for solid fill overlay support following the suggestion to set the fb_id to a prop_blob id with the solid fill color, and I'm hitting an issue where setting the PROP_BLOB flag for FB_ID is failing this check (https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71).
<jessica_24> (for context, the reason I'm adding this flag to FB_ID is that, if we don't, drm_property_change_valid_get() in drm_atomic_set_property() fails because it tries to find a drm_mode_object with the prop_blob id). Is it possible to relax this check?
<emersion> jessica_24: we probably want another prop, not literally FB_ID
moony has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<abhinav__> emersion the earlier consensus was not to have a new property and re-use the FB_ID
<abhinav__> as we will have to handle the !fb checks in many places in the driver anyway
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
vliaskov has quit [Remote host closed the connection]
<pinchartl> jessica_24: what are solid fill overlays ?
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
srslypascal has joined #dri-devel
<jessica_24> pinchartl: sorry, the original wording was confusing -- I'm basically trying to add support for users to specify the fill color of a plane
ahajda has joined #dri-devel
<pinchartl> would that be planes that have no fb associated with them, and are filled with a solid color ?
<abhinav__> yes thats right
ahajda has quit []
<pinchartl> I'm curious, what are the use cases for that ?
h0tc0d3 has quit [Quit: Leaving]
* ccr glances fearfully in zmike's direction.
<abhinav__> we have seen many applications which typically have just one layer which is constantly updating like some messaging applications but parts of the screen are just solid colors
<abhinav__> if we can use solid color for that plane, we can disable memory fetch
moony has quit []
moony has joined #dri-devel
iive has quit [Quit: They came for me...]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<pinchartl> that's a peculiar use case
<pinchartl> so you want to detect rectangle regions with a solid color on the composed output, and replace them with solid color planes ?
leandrohrb8 is now known as leandrohrb
pcercuei has quit [Quit: dodo]
<anholt> 4 tu_QueueSubmits per frame of glxgears under zink is about 3 more than I would hope for.
<anholt> zink makes 2 batches (one with one submitinfo, one with 2, which gets split up by vk common into 2 separate submits), then also wsi_common_queue_present generates another.
Jeremy_Rand_Talos has quit [Remote host closed the connection]
mattrope_ has quit [Remote host closed the connection]
mattrope has joined #dri-devel