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]
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
<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 && 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!]
<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
<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
<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: 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>
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
<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?
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
<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
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]