ella-0 has quit [Remote host closed the connection]
fab has joined #dri-devel
dcz_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Leopold_ has joined #dri-devel
mhenning has quit [Quit: mhenning]
bgs has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
sdutt_ has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
frieder has joined #dri-devel
MajorBiscuit has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
danvet has joined #dri-devel
fab has joined #dri-devel
pendingchaos_ has joined #dri-devel
jkrzyszt has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
<pq>
dcz_, maybe you could start by explaining *why* do you think you need to use GBM at all?
<graphitemaster>
lol, why does vec4(a_vec3, a_vec3) compile
<graphitemaster>
Am I learning about some obscure glsl vector constructor thing
<dcz_>
pq: I want to allocate a buffer that looks as close to a buffer allocated by the video device
<pq>
dcz_, why not use vivid for that job? You need specific contents in it?
<dcz_>
I need arbitrary contents in it
<pq>
ok, that makes sense
<dcz_>
I need to look at vivid
<pq>
vivid is kernel driver for virtual v4l2 device which you configure in many different ways to act as a testing device without needing a real device.
<pq>
I believe it also supports dmabuf export.
vliaskov has joined #dri-devel
<dcz_>
it would be good enough for me, considering that I'm doing that for libcamera, and vivid is supported in libcamera
<dcz_>
but I'm not sure if I want to pull an entire video device for this kind of testing
<pq>
then you're going to need vgem instead
<pq>
you need some device that can allocate and export dmabuf, if you want to test with dmabuf.
<pq>
I presume this is about CI, maybe even in generic Gitlab runners?
<dcz_>
just manual testing for now, but I will move there
<dcz_>
isn't a gbm already a dmabuf?
<pq>
gbm needs a device to initialize on
<pq>
it cannot run in void
<dcz_>
so vgem only relies on generic kernel infrastructure?
<pq>
gbm cannot create a dmabuf if it has no device to actually allocate and export on
<pq>
vgem is a kind of virtual memory allocation device, yes
<dcz_>
oh, so it's what I was trying to find originally and failed
<pq>
then there is vkms for a virtual KMS driver for testing, in case you need to test display side
kts has joined #dri-devel
<dcz_>
nope, no display
<pq>
however, if you have an actual hardware GPU in the system, I'm not sure if there are any guarantees that vgem buffers are going to be compatible with it.
<dcz_>
now that's a showstopper
<pq>
not really, just don't use the real GPU
<dcz_>
use llvmpipe or something?
<pq>
make sure everything runs on software and virtual drivers
<pq>
yup, theoretically that should work
<dcz_>
the point of the thing I'm doing is to leverage the GPU :)
<pq>
then you must use the real GPU device, not vgem
<dcz_>
and also gbm will never lack a device
<pq>
how do you know gbm will never lack a device?
<dcz_>
isn't a gbm device a render node?
<pq>
yes, how do you know you will always have a render node?
<dcz_>
okay, I guess GPUs didn't always have render nodes
<pq>
how do you know you always have a GPU? That's the question.
heat has joined #dri-devel
<dcz_>
because if I don't have a GPU, then you won't use my library :)
<dcz_>
*you->I
<pq>
Usually CI test runners have no DRM devices (that can be used), but if you use special bare-hardware runners explicitly, they can provide a GPU. Or maybe some cloud environments can provide a virtualized GPU.
<pq>
so would I test e.g. Weston in general CI runners with libcamera then? :-)
<pq>
*libcamera applications
<pq>
but ok, if you can make that assumption, good for you. I cannot assume that with Weston CI.
<dcz_>
is that kind of a test even useful (for Weston)? if you're testing libcamera with GPU processing, then you want to test the actual GPU behaviour. Otherwise, you can settle for the CPU fallback without losing any coverage
<dcz_>
I barely even got this off the ground, so what we're talking about is a matter for the uture at best :) For now I'll make any assumptions that make my job easier without painting myself into a corner
<pq>
I want to test the Weston and application code. I don't actually want to test any hardware in that case, when the goal is to ensure that Weston and app code remains working. Hardware and drivers can have their own bugs I'm not interested in.
<pq>
sure :-)
<Kayden>
graphitemaster: I wouldn't expect vec4(some_vec3, some_vec3) to compile.
<dcz_>
fair enough, so it would suffice to provide any sort of software fallback that looks the same on the outside
<Kayden>
graphitemaster: GLSL 4.50 section 5.4.2, "If a vector is constructed from multiple scalars, one or more vectors, or one or more matrices, or a mixture of these, the vector's components will be constructed in order from the components of the arguments. The arguments will be consumed left to right, and each argument will have all its components consumed, in order, before any components from the next argument are consumed.
<dcz_>
sadly, I had to ditch plans for sotware fallback due to too much effort for something too far out of the way. I might revisit it at some point
<Kayden>
graphitemaster: "... It is a compile-time error to provide extra arguments beyond this last used argument."
<Kayden>
graphitemaster: Ah, no, sorry. That will in fact compile
<Kayden>
graphitemaster: because both vec3s are used. the first vec3 gives xyz, and another value is needed. so it takes w from the second vec3. there are extra unused components, but that's fine.
swalker_ has joined #dri-devel
<Kayden>
graphitemaster: vec4(a_vec3, a_vec3, anything) would fail, because the third value is strictly an extra argument that isn't needed for any purpose
swalker_ is now known as Guest2241
<Kayden>
it is rather odd, I'll admit!
swalker__ has joined #dri-devel
lynxeye has joined #dri-devel
Guest2241 has quit [Ping timeout: 480 seconds]
rkanwal has joined #dri-devel
fahien has joined #dri-devel
mattst88_ has joined #dri-devel
tursulin has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
kj_ is now known as kj
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
gouchi has joined #dri-devel
ahajda has joined #dri-devel
gouchi has quit [Quit: Quitte]
Leopold_ has quit [Remote host closed the connection]
<dcz_>
daniels: R8 works as an input buffer, thanks for hinting me in the right direction
Leopold_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
rkanwal has quit []
JohnnyonFlame has joined #dri-devel
Leopold_ has quit []
srslypascal is now known as Guest2252
srslypascal has joined #dri-devel
Guest2252 has quit [Ping timeout: 480 seconds]
<tzimmermann>
vsyrjala, can i ask you for a review of v3 of the primary-plane check?
fahien has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
<vsyrjala>
i still don't understand what we're actually trying to check, and why
<tzimmermann>
vsyrjala, some hardware cannot disable the primary plane individually. the crtc should then only be enabled with an attached primary plane. AFAIU simplekms helpers also do this check to ensure that they always have a plane state for an enabled crtc. that is part of their callback helper's interface
<tzimmermann>
the fixed code was part of the simplekms helpers. moving it into a helper added a regression. at least that regression should be fixed
<daniels>
dcz_: glad to hear, np
<vsyrjala>
tzimmermann: so this thing checks just that at least one primary plane is logically enabled. something else then i guess checks that all primary planes are actually enabled and never just logically enabled but invisible?
<tzimmermann>
vsyrjala. that test is supposed to be in the driver if it needs it
<vsyrjala>
sure. so this check is also only useful to such drivers
<vsyrjala>
i guess the generic name of the function is what throws me off a bit. makes you think this is somehow useful to all driver
<vsyrjala>
s
<tzimmermann>
vsyrjala, that helper is supposed to be something like drm_atomic_helper_check_plane_state(). something you can call and it does a number of standard tests. but it's just a single test for now. maybe rethinking this idea, would make sense
Lucretia-backup has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
fahien has joined #dri-devel
<vsyrjala>
tzimmermann: yeah. i tend to prefer "one function == do one thing". esp. the "modify the function behaviour wiht bools/flags" approach is a bit counter to the whole idea of functions impo
<vsyrjala>
imo
<tzimmermann>
vsyrjala, ok. i'll make a v4 patchset that renames the function. there aren't too many users yet anyway
kts has quit [Quit: Konversation terminated!]
<jadahl>
are there any situations when I only see a connector disappearing from the retrieved KMS resources some time *after* a hotplug uevent? What I'm seeing is are uevent hotplug events, where 2 out of 3 MST connectors disappear, with the 3 being some kind of ghost connector that didn't get removed. when I later try to poke at it, I get ENOENT errors. it can be worked around by randomly querying KMS again,
<jadahl>
but that doesn't seem right...
<jadahl>
(this is i915 fwiw)
<vsyrjala>
if it's enabled then references are still held to it, and it can't disappear until those are released
<vsyrjala>
bsaically the only thing you should be able to do with it from userspace is disable it
<jadahl>
vsyrjala: the thing I do is disabling it, only that disabling it happens later
<jadahl>
with "disabling" I mean setting CRTC_ID to 0
<jadahl>
I can work around it by re-querying the kernel some time after the hotplug or just before disabling
<vsyrjala>
i thought it also disappears from the connector list. if it doesn't then there might be a bug
<jadahl>
so the connector was active, it was plugged out, userspace sees the hotplug event, looks at what connectors exist. at this point, it's still listed
Leopold_ has joined #dri-devel
<jadahl>
you're saying it should be unlisted here, or that I have to re-query after any potential references to it are gone?
kts has joined #dri-devel
<emersion>
once you disable it, kernel is supposed to send another hotplug uevent
<jadahl>
i don't disable it, because trying to do so gives me ENOENT
<emersion>
if you query again at that point, it should disappear
<emersion>
well, that's weird
<jadahl>
querying it again, some time after the hotplug, it does indeed disappear
<vsyrjala>
i thought the idea was that we unregister it immediately on hpd, then send the uevent, and then let userspace disable it
<jadahl>
problem I see is that I don't see a hotplug event that tells me when to get an up to date connector state
<emersion>
the expected sequence is: kernel sends uevent, user-space probes DISCONNECTED, user-space disables, kernel sends uevent, user-space no longer sees connector
<jadahl>
oh, so userspace must disable immediately if it sees DISCONNECTED?
<jadahl>
we don't do that; we just expect that it doesn't need any more hand holding if it isn't connected to anything
sdutt has joined #dri-devel
<jadahl>
whats the "grace period" for doing that disabling?
<jadahl>
waiting for ~3 seconds (which I do during current testing) I get that ENOENT
sdutt has quit []
<pq>
Theoretically you can keep a CRTC+connector running even if the connector is disconnected. It works on VGA, and I guess those semantics/illusion has been carried forward. Any "grace period" should be infinite in that case.
sdutt has joined #dri-devel
<vsyrjala>
you don't want to leave unconnected stuff enabled on modern intel hw at least. the tc/tbt firmware is kinda crap and doesn't like that so much
<jadahl>
pq: infinite it is definitely not
cleverca22[m] has quit []
<jadahl>
vsyrjala: so how do I do that without running into ENOENT? or should I just try, and hope for the best, and ignore any ENOENT?
<vsyrjala>
you shouldn't get ENOENT from disabling
columbarius has quit [Read error: No route to host]
<jadahl>
ok, it appears I *do* disable it (setting CRTC_ID to 0) immediately
<jadahl>
but I see no new hotplug events
<emersion>
double-disable will give ENOENT
<emersion>
i think i've experienced something similar-ish
<jadahl>
emersion: wierd, I double-disable all connectors every power save
<emersion>
haven't time to finish my investigation
<jadahl>
and it works fine except in this case
<jadahl>
(again, "disabling" as in CRTC_ID => 0)
<emersion>
but i think the kernel is missing hotplug uevents after drm_connector_unregistr
<emersion>
*drm_connector_unregister()
<emersion>
jadahl: that's expected, since disabling the connector will remove it as a side effect
<jadahl>
with the missing extra hotplug being the issue here then I guess
<emersion>
iirc, drm_connector_register() sends a uevent, but drm_connector_unregister() doesn't
<vsyrjala>
drm_dp_delayed_destroy_work() does have the uevent after unregister
<emersion>
but there's so much stuff going on when a MST hub is unplugged, it's hard to make sense of what's up
rkanwal has quit [Ping timeout: 480 seconds]
<emersion>
vsyrjala: hm, is the connector UNREGISTERED when it's waiting to be disabled?
<emersion>
or is it still REGISTERED at this point?
<vsyrjala>
looks like the latter. the unregister happens from some kref_put()
<vsyrjala>
or rathet it's put on the delayed_destroy_list, and then it gets unregisterd from a workqueue processing that list
khfeng has quit [Ping timeout: 480 seconds]
<jadahl>
so can the kernel be fixed to tell me about when to update my state?
<emersion>
reading vsyrjala's messages, it's supposed to do that already
<vsyrjala>
yeah, based on what i see it should more or less work. disconnected->uevent->disable->uevent->connector gone
<emersion>
maybe add some debug logs and see when each step happens
<jadahl>
so it should, but isn't
doras has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
Guest2171 has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
Ella[m] has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
martijnbraam has quit [Write error: connection closed]
jenatali has quit [Write error: connection closed]
x512[m] has quit [Write error: connection closed]
naheemsays[m] has quit [Write error: connection closed]
kunal_1072002[m] has quit [Write error: connection closed]
jasuarez has quit [Write error: connection closed]
zzoon_holidays_until_3rd_Oct[m has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
cwfitzgerald[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
viciouss[m] has quit [Write error: connection closed]
ralf1307[theythem][m] has quit [Remote host closed the connection]
Newbyte has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
gagallo7[m] has quit [Write error: connection closed]
Vin[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
kallisti5[m] has quit [Write error: connection closed]
Andy[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
Weiss-Fder[m] has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
Guest2187 has quit [Write error: connection closed]
Tooniis[m] has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
dcbaker has quit [Write error: connection closed]
AlexisHernndezGuzmn[m] has quit [Write error: connection closed]
nyorain[m] has quit [Write error: connection closed]
robertfoss[m] has quit [Write error: connection closed]
ramacassis[m] has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
danylo has quit [Write error: connection closed]
tomba has quit [Write error: connection closed]
michael5050[m] has quit [Write error: connection closed]
moben[m] has quit [Write error: connection closed]
Soroush has quit [Write error: connection closed]
knr has quit [Write error: connection closed]
Strit[m] has quit [Write error: connection closed]
undvasistas[m] has quit [Write error: connection closed]
kunal10710[m] has quit [Write error: connection closed]
sjfricke[m] has quit [Write error: connection closed]
pushqrdx[m] has quit [Write error: connection closed]
KunalAgarwal[m][m] has quit [Write error: connection closed]
Anson[m] has quit [Write error: connection closed]
eyearesee has quit [Write error: connection closed]
jekstrand[m] has quit [Write error: connection closed]
Mis012[m] has quit [Write error: connection closed]
DavidHeidelberg[m] has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
tintou has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
unrelentingtech has quit [Write error: connection closed]
ella-0[m] has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
arisu has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
T_UNIX has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
sigmoidfunc[m] has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
reactormonk[m] has quit [Write error: connection closed]
onox[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
masush5[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
gdevi has quit [Write error: connection closed]
kunal_10185[m] has quit [Write error: connection closed]
egalli has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
PiGLDN[m] has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
r[m] has quit [Write error: connection closed]
mairacanal[m] has quit [Write error: connection closed]
Labnan[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
neobrain[m] has quit [Write error: connection closed]
bylaws has quit [Write error: connection closed]
chema has quit [Write error: connection closed]
arisu has joined #dri-devel
jewins has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<eric_engestrom>
daniels: is *that* everyone's favourite open-source consultancy? not the *other* one? ;P
kts has quit [Quit: Leaving]
fahien has quit [Ping timeout: 480 seconds]
FireBurnUK has quit [Quit: Konversation terminated!]
<daniels>
eric_engestrom: we've done extensive market research and we're pretty sure
<pinchartl>
daniels: you may find that some people have a slightly different opinion. while still loving you a lot, of course :-)
Company has joined #dri-devel
<daniels>
pinchartl: you're my favourite margin of error <3
<pinchartl>
I'll try to take that as a compliment :-)
<eric_engestrom>
daniels: hehe
<ccr>
:)
fahien has joined #dri-devel
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Read error: Connection reset by peer]
tursulin has quit [Read error: Connection reset by peer]
khfeng has joined #dri-devel
tursulin has joined #dri-devel
chadv1 has joined #dri-devel
chadv has quit [Quit: WeeChat 1.9.1]
loothelion has quit [Remote host closed the connection]
loothelion has joined #dri-devel
agx has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
chadv1 is now known as chadv
kts has joined #dri-devel
chadv has quit [Quit: WeeChat 3.6]
chadv has joined #dri-devel
chadv is now known as Guest2279
agx has joined #dri-devel
carbonfiber has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
<graphitemaster>
Very strange
pendingchaos_ is now known as pendingchaos
<graphitemaster>
Is there an IRC channel for X11/Xcb stuff?
<graphitemaster>
Spent like 3 hours trying to figure out something terribly simple on Windows but seemingly impossible with X11
<carbonfiber>
What is the "proper" and "future proof" way of creating a headless x11 server in the context of xwayland existing and xwayland being prioritized? Are xf86-video-dummy (with xorg) and xvfb going to be deprecated? Should I use a headless wayland setup (instead of a headless x11 server) which then embeds xwayland? or are there no plans to deprecate xf86-video-dummy and xvfb?
kem has quit [Ping timeout: 480 seconds]
<soreau>
graphitemaster: #xorg-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
frieder has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
<graphitemaster>
Thanks
pochu has joined #dri-devel
kem has joined #dri-devel
fab has joined #dri-devel
ella-0 has joined #dri-devel
Duke`` has joined #dri-devel
fxkamd has quit []
loothelion has quit [Remote host closed the connection]
Andy[m] has joined #dri-devel
bluepenquin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
colemickens has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest2264 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
loothelion has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest2276 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon_holidays_until_3rd_Oct[m has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
loothelion has quit []
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
unrelentingtech has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
pmoreau is now known as Guest2292
bmodem has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
<kisak>
it would be nice if the current in use mic could be turned up 6db for the next presenter.
<kisak>
(not bad enough to adjust live)
<zmike>
how about now
Terman has quit [Remote host closed the connection]
<kisak>
I didn't notice a change
<eric_engestrom>
kisak: you have more chances of getting the right people's attention on the XDC matrix channel: https://matrix.to/#/#xdc2022:matrix.org
<kisak>
sorry, I don't have a presence on Matrix. In the start of day introduction, the person standing on camera left seemed fine, and the person on camera right had a soft mic, but I wasn't on my reference level speakers to watch yet.
tursulin has quit [Ping timeout: 480 seconds]
<eric_engestrom>
yeah jwhite was a lot louder than ivyl during the intro, but I think the mic level doesn't matter anymore when there's only one being used
bmodem has quit [Ping timeout: 480 seconds]
<ivyl>
What's weird is that the levels looks fairly okay on my end
<ivyl>
but I'll bump it between talks a bit
<ivyl>
would be to jarring to do it now
<kisak>
thanks
<ivyl>
too*
Guest2276 is now known as frytaped
<emersion>
jekstrand: what would be a good first task to start contributing to NVK?
swalker__ has quit [Remote host closed the connection]
warpme___ has joined #dri-devel
<emersion>
question: plans for more common code besides meta?
<daniels>
emersion: relayed into Matrix
<emersion>
thx
karolherbst has joined #dri-devel
<emersion>
oh but this is an NVK shirt
<emersion>
lol
<daniels>
emersion: first time I saw that logo I thought it said 'NAK'
<daniels>
with the rainbow being a nice pleasant way to let you down
<emersion>
ahah
italove9 has quit []
italove9 has joined #dri-devel
<emersion>
👏
devilhorns has quit []
devilhorns has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit []
<ivyl>
kisak: are the levels any better?
<daniels>
emersion: you're missing out on the stickers tho
<emersion>
;_;
<jekstrand>
daniels: Well, that would be a reasonable shirt for me to wear as well. :P
MajorBiscuit has joined #dri-devel
<kisak>
ivyl: there was an improvement, but the mic has unfortunately wandered away from Bas
<kisak>
can't do anything about that
<kisak>
overall close to the previous talk
<ivyl>
I'll bump it more
<ivyl>
I just want to avoid doing that during the middle of the talk so there are no sudden loud parts
lynxeye has quit [Quit: Leaving.]
aravind has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
jamesjones has joined #dri-devel
loothelion has joined #dri-devel
Guest2279 is now known as chadv
nchery_ has joined #dri-devel
nchery is now known as Guest2310
nchery_ is now known as nchery
<chadv>
jekstrand: i'm reading the comments for vk_device::timeline_mode, and discovered VK_DEVICE_TIMELINE_MODE_NATIVE, and got excited.
<chadv>
then my hopes were immediately crushed: "Currently, this isn't supported by any Linux primitives"
<chadv>
jekstrand: btw, thanks again for excellent documentation
gouchi has quit [Quit: Quitte]
<jekstrand>
chadv: :D
<jekstrand>
chadv: It works on Windows 🙃
Guest2310 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
devilhorns has quit []
<kisak>
bnieuwenhuizen: Thanks for the talk, please ignore my general audio feedback in the backscroll.
<kisak>
(main intent was not to nitpick mic placement)
karolherbst has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
<ajax>
:/
<ajax>
i am getting a very strange build failure:
<ajax>
/usr/bin/ld: src/amd/compiler/libaco.a(aco_ir.cpp.o): in function `aco::monotonic_buffer_resource::monotonic_buffer_resource(unsigned long)':
<ajax>
/var/home/ajax/git/mesa/build/../src/amd/compiler/aco_util.h:416: undefined reference to `aco::monotonic_buffer_resource::minimum_size'
<ajax>
what the actual
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<ajax>
this fixes it, and i maybe understand why, but i don't understand why it doesn't have the same problem with whathaveyou::initial_size
<Jeremy_Rand_Talos>
Are those bottlenecks documented anywhere? I see a nontrivial amount of llvmpipe CPU usage (e.g. triangle_ccw) in the main thread (as opposed to the spawned threads) via perf; is that what he meant?
<airlied>
Jeremy_Rand_Talos: I've removed some of those bottlenecks, but I think binning is probably the largest one remaining
<Jeremy_Rand_Talos>
airlied, how feasible is it to improve the remaining such bottlenecks?
<Jeremy_Rand_Talos>
airlied, and are there any docs (formal or informal) where I could read up on the current state of such things?
<airlied>
Jeremy_Rand_Talos: how much time you got? :-)
<airlied>
the main thing would be to find a benchmark where you care
<airlied>
then profile, profile, profile, and see what bottlenecks
<airlied>
most of the bottlenecks are memory bandwidth on fragment shader execution
<airlied>
those are hard to fix :-P
<ajax>
airlied: did we finally get overlapping vs/fs/present working?
<airlied>
ajax: yes it seems to definitely be bug free this time :-P