ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
vivijim has quit [Ping timeout: 480 seconds]
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<jekstrand>
bnieuwenhuizen, dj-death: Got started on common sync code. Currently living at wip/vk-common-sync. I *think* I've got vk_sync general enough that I can do everything we need.
<jekstrand>
In theory, the driver can insert its own sync type with a few wrappers. ANV will use it to use BOs for VkFence on old HW.
<jekstrand>
dj-death: One change this is goint to make: ANV will always use a submit thread, even when we don't have timeline syncobj.
<jekstrand>
It's a tiny bit more overhead but I think the unification is worth it given that timeline syncobj is pretty common these days.
<jekstrand>
No sense fast-pathing the legacy stuff
<bnieuwenhuizen>
jekstrand: are timeline BOs that end up not being used wait-before-submit legacy too now?
<jekstrand>
bnieuwenhuizen: Yeah, it's legacy but I'm going to do it in core code
<jekstrand>
In theory, the driver will be unaware it's happening
<bnieuwenhuizen>
on radv we only start the thread the first time we have something that is waited upon but not submitted yet
<jekstrand>
It'll get a `vk_sync **` and the timeline will be auto-converted into binary `vk_sync`s of the desired form before the driver sees it.
<jekstrand>
We can do a lazy thread
<jekstrand>
That's fine
<bnieuwenhuizen>
jekstrand: I mean with full timeline syncobj
<jekstrand>
Right, if they create any timeline syncobj vk_syncs, they'll get those
<bnieuwenhuizen>
also any plans on MRing the shared cache stuff?
<jekstrand>
Yeah, I need to get back to that. You wanted me to delete the double deserialization. I've got a plan, I just need to go type it.
<jekstrand>
I just MR'd the sync stuff so we can chat on the MR while I keep typing
<jekstrand>
This is going to be a LOT of typing before it's all done
<jekstrand>
But, also, it's going to be a LOT of code we can delete from ANV and RADV and, more importantly, not re-type in turnip, v3dv, panvk, etc.
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<airlied>
karolherbst: hey I've pushed 3 patches from me to that branch, would be good if you could take a glance, other than that it's just sorting out the whole images_used mask stuff left
sadlerap has quit [Quit: WeeChat 3.3]
sadlerap has joined #dri-devel
<karolherbst>
airlied: okay, cool
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
jewins has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
sadlerap has quit [Quit: WeeChat 3.0]
sadlerap has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
eric_engestrom_ has joined #dri-devel
ezequielg has quit [Ping timeout: 480 seconds]
mattrope has quit [Read error: Connection reset by peer]
jjardon_ has quit [Ping timeout: 480 seconds]
hwentlan has quit [Ping timeout: 480 seconds]
steev has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
ezequielg has joined #dri-devel
jjardon_ has joined #dri-devel
hwentlan has joined #dri-devel
eric_engestrom has quit [Ping timeout: 480 seconds]
cwabbott has joined #dri-devel
steev has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
fxkamd has quit []
unsolo_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<airlied>
jenatali: where did you work out spec constant ids could change after link?
<airlied>
I'm reading the spirv-tools linker code and I'm not really seeing it
unsolo has quit [Ping timeout: 480 seconds]
<airlied>
though I'm not really sure how linking would go down if two spec consts had the same id.
<airlied>
so it's probably good to just eliminate them at compile stage for CL
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
mlankhorst has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest3355
Guest3355 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
pnowack has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
unsolo has joined #dri-devel
camus has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
dongwonk_ has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
<MrCooper>
pinchartl: "wallet on legs" reminds me of the Discworld Luggage :)
<pinchartl>
:-)
<pinchartl>
we also use "stomach on leg" in French to mean someone who eats a lot
<pinchartl>
"wallet on legs" is mostly used to refer to companies that consider their customers solely as a source of revenue
<pinchartl>
I started re-reading Discworld recently
<MrCooper>
I'm craving to do the same now
elongbug has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<pq>
vsyrjala, re: gitlab autoclosing issues; that can be really annoying when a comment references an issue in another gitlab project implicitly, you cherry--pick that commit to something of yours, and it closes a completely unrelated issue that just happened to have the same id.
<pq>
vsyrjala, another variant of that is having commits in branches closing issues prematurely.
<pq>
karolherbst, I can't hear my Thinkpad T420, FWIW. I have my desktop and QNAP fans drowning it out when it's not loaded. :-P
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
<vsyrjala>
if you can hear the fans your music isn't loud enough. ie. you're too old, but also too young that you still have enough hearing left to hear the fans
<vsyrjala>
i just had a great idea for a product. fans with so high pitched whine old people can't hear them
<pq>
I gave up listening to music while working more than a year ago. It seems nowadays I need more of my brain for the work.
pcercuei has joined #dri-devel
<imirkin>
hm, music enables me to focus better
<vsyrjala>
i sometimes put on some music from youtube, but then youtube autopauses after a while. and then i work the rest of the day without even realizing the music stopped
<imirkin>
there's a loop option that i like. the other key is that i can't understand any of the lyrics to almost any song, so it's just noise to me :)
<vsyrjala>
same here
<pq>
I use the fans for that.
* vsyrjala
just realizes the phone meeting ended an hour ago. time to hang up the phone
<imirkin>
lol
<imirkin>
my BT headset makes an annoying background sound when it's in "headset" mode (vs aptX mode), so i can't really forget it
<pq>
After sitting for 8 hours in that constant, unchanging pink(?) noise, going home where there is no such noise feels really... different.
xexaxo_ has quit [Ping timeout: 480 seconds]
shashank1202 has joined #dri-devel
frytaped has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kmn has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
Company has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
mclasen has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
<pinchartl>
(the article I read about that, written by a French journalist who translated an English journalist trying to vulgarize the research results, started by stating that the absolute zero was a limit "difficult to exceed", and went on telling that 34pK was "trillions on degrees")
<jani>
danvet: stephen writes, "This may only have been revealed because of another fix I have had to apply today."
<jani>
danvet: but I figured we shouldn't be using stack depot "namespace" anyway
camus1 has quit [Ping timeout: 480 seconds]
<karolherbst>
pinchartl: no... that requires a fan as well :P
<karolherbst>
I meant more tweaking the bios to spin up fans quite late and such...
<pinchartl>
you can also unplug the fan. no more noise
<karolherbst>
:D
<karolherbst>
problem is, I have to do git bisects occasionally
<karolherbst>
and it's not as loud on the desktop as on the laptop
<karolherbst>
equally fast though...
<karolherbst>
Just noticed recently, that my desktop was capped at 65W TDP and that my laptop is able to cool away 70W :D
<karolherbst>
and both have six cores
<pinchartl>
I'm tempted to get a 32+ cores build machine, to double as a heater for the winter
<karolherbst>
:D
<ccr>
better get a personal powerplant too, while at it
<karolherbst>
there is actually a cooling case which is able to cool away 150W passivel
<karolherbst>
y
<pq>
karolherbst, pinchartl, submerge the machine in oil so that all parts get cooled and not just the CPU. :-)
<karolherbst>
pq: yep
<pinchartl>
pq: how many kernels do I need to compile to make french fries ?
<karolherbst>
I was thinking about building a home servier with something like that
<karolherbst>
pinchartl: probably 20, because the 128 core machine compiles quite fast
vivijim has joined #dri-devel
<pq>
depend on how big the tank is
<karolherbst>
well... you kind of have to produce the thermal energy
<karolherbst>
and normally you need a lot to make french fries
<karolherbst>
even with smaller tanks
thellstrom has joined #dri-devel
<karolherbst>
but I see there are even some which work without oil....
<karolherbst>
or fat
<pinchartl>
there was a funny video of a professional cyclist who tried to grill a toast with a bike connected to a generator connected to a toaster. he failed
<karolherbst>
uff
<pinchartl>
producing 700W for a couple of minutes isn't possible for humans
<karolherbst>
yeah..
<karolherbst>
and even 700W isn't much
<karolherbst>
mine is around 1200W I think and even that sucks
<karolherbst>
seems like for french fries you need like 2000W
<karolherbst>
for a small one
itoral_ has quit [Remote host closed the connection]
<pinchartl>
we're getting dangerously close to the "will it blend" videos of apple products :-)
<pinchartl>
(a friend of mine was nearly in tears when those were released)
JohnnyonFlame has quit [Ping timeout: 480 seconds]
unsolo has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
flto_ has quit []
flto has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
jkrzyszt has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
macromorgan is now known as Guest3385
macromorgan has joined #dri-devel
Guest3385 has quit [Read error: Connection reset by peer]
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
shashank1202 has joined #dri-devel
jewins has joined #dri-devel
<ajax>
700W is just under one horsepower
<ajax>
non-metric units have occasional uses
mattrope has joined #dri-devel
<zackr>
Does anyone know how prime synching works with GEM userspace? i.e. if app A renders to a buffer that app B is about to map it, is app A expected to hold a dma-buf fence on the bo which will make app B wait for it? Or is the map going to fail while the fence is grabbed? Or are the user-space apps expected to sync between each other? Or are the results undefined?
pjakobsson has joined #dri-devel
<ajax>
jekstrand: do we remember why we're using a wsi thread for x11 in the first place? the longer i look at this the less i think we need it
<bnieuwenhuizen>
ajax: for acquire or for present?
jkrzyszt has quit [Remote host closed the connection]
<jekstrand>
ajax: FIFO
fxkamd has joined #dri-devel
<jekstrand>
Why are the rest of the modes using it? Mostly to make them all the same, IIRC.
<jekstrand>
But FIFO was the original motivation
Duke`` has joined #dri-devel
<jenatali>
airlied: I'm not sure that I did, I might've come to the same conclusion as you, that an overlap means it can't be independently specialized in a linked kernel
<zmike>
jenatali: can you (or someone on your team) check out my recent ci MR to make sure I didn't miss any gallium/aux components you're using in d3d12
<zmike>
trying to cut down unnecessary hardware jobs
jasuarez has quit []
egalli has quit []
apinheiro[m] has quit []
chivay has quit []
exit70[m] has quit []
Sumera has quit [Quit: Bridge terminating on SIGTERM]
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
kusma has quit [Quit: Bridge terminating on SIGTERM]
Vin[m] has quit []
undvasistas[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
unrelentingtech has quit [Quit: Bridge terminating on SIGTERM]
aperezdc has quit []
Mershl[m] has quit []
ella-0[m] has quit []
MatrixTravelerbot[m] has quit []
kallisti5[m] has quit []
cwfitzgerald has quit []
xerpi[m] has quit []
LaughingMan[m] has quit []
Tooniis[m] has quit []
robertmader[m] has quit []
nielsdg has quit []
MrR[m] has quit []
YaLTeR[m] has quit []
reactormonk[m] has quit []
gdevi has quit []
gnustomp[m] has quit []
Eighth_Doctor has quit []
chema has quit []
danylo has quit [Quit: Bridge terminating on SIGTERM]
pmoreau has quit [Quit: Bridge terminating on SIGTERM]
HayashiEsme[m] has quit [Quit: Bridge terminating on SIGTERM]
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
DrNick has quit []
Strit[m] has quit []
gagallo7[m] has quit []
T_UNIX has quit []
ServerStatsDiscoverertraveler4 has quit [Max SendQ exceeded]
zzoon[m] has quit [Quit: Bridge terminating on SIGTERM]
zzag[m] has quit []
neobrain[m] has quit []
RAOFhehis[m] has quit []
PiGLDN[m] has quit []
aura[m] has quit []
Anson[m] has quit []
tintou has quit []
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
atulu[m] has quit []
cleverca22[m] has quit []
jekstrand[m] has quit []
pushqrdx[m] has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
naheemsays[m] has quit []
sigmoidfunc[m] has quit []
Venemo has quit [Quit: Bridge terminating on SIGTERM]
tomba has quit [Quit: Bridge terminating on SIGTERM]
_alice has quit [Quit: Bridge terminating on SIGTERM]
Guest2215 has quit [Remote host closed the connection]
jenatali has joined #dri-devel
sneil has quit [Remote host closed the connection]
Lucretia has quit []
_alice has joined #dri-devel
Lucretia has joined #dri-devel
sneil has joined #dri-devel
<ajax>
bnieuwenhuizen: at all
<ajax>
jekstrand: why tho. just submit present requests with monotonically increasing target_msc, let the server queue like it already has to.
<ajax>
it's not incumbent on the client to only submit frame n+2 after frame n+1 is presented
sravn has joined #dri-devel
<jekstrand>
ajax: It's entirely possible that I don't understand and/or don't trust X11 :)
<jekstrand>
ajax: Feel free to blame it all on my
<jekstrand>
This is what you get when someone learns x11/dri3/present while writing the present code and literally no one else is willing to help them.
<zmike>
:(
<ajax>
haha, not blaming you at all
<ajax>
we are all sisyphus, here
<daniels>
jekstrand: so what you're saying is that you're now qualified to take over GLX
<ajax>
was more wondering if non-threaded had been tried and found wanting for some real app
<jekstrand>
daniels: Clearly, I'm not. :P
<jekstrand>
ajax: Not in my memory
<ajax>
right on
<ajax>
because i'm on my third crack at fixing this particular deadlock and "you can't deadlock if you only have one thread" has a certain appeal at this point
<ajax>
(and to be clear i entirely don't blame you for not trusting Present)
<jekstrand>
heh
<jenatali>
zmike: just noticed that I had a reconnect and had to re-auth. Did you get my message about pipebuffer?
<zmike>
no
<jenatali>
zmike: We use pipebuffer. You could skip running the Windows jobs on pipe-loader and target-helper changes though
<zmike>
eh every other gallium driver uses them though, and having a single special case like that feels messier than necessary given how infrequently those get changed
<jenatali>
Yep makes sense
<jenatali>
If we ran tests on WSL we'd use em, but not on Windows
<bnieuwenhuizen>
ajax: I added the fence wait before present in mailbox mode because there seemed to be some real mess going on inside the X11 server which meant that the GPU got blocked on the WSI, which is not what you want with mailbox. (and you don't want a blocking fence wait in the vkQueuePresent)
<ajax>
:|
<emersion>
there's also the Xwayland case, which needs to map everything to Wayland's mailbox model
<ajax>
i find the is_xwayland detection in wsi distasteful tbh
<emersion>
yeah…
jkrzyszt has joined #dri-devel
<ajax>
aw yiss
shashank1202 has quit [Quit: Connection closed for inactivity]
nchery has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
<LaserEyess>
do any mesa devs want to comment on the switch to meson and whether or not they think it was 'worth it'?
<LaserEyess>
someone in another channel said that some projects may be "too big" to make a switch, and this is the largest project i know that did, so I'm curious whether or not people think it was a good decision
<kisak>
LaserEyess: I think a big part of that transition is that multiple build systems were retired/removed in the transition. Three independent build systems down to one.
<jekstrand>
bnieuwenhuizen, dj-death: I've got vk_fence and vk_semaphore typed now. Time to type the queue submit stuff
<jekstrand>
Unfortunately, I don't see a good way to roll this out gradually.
<jekstrand>
+2.3K LOC so far but, also, it's going to delete most of anv_queue.c :D
rgallaispou has left #dri-devel [#dri-devel]
<LaserEyess>
kisak: that sounds pretty worth it from a maintenance burden viewpoint
dongwonk has joined #dri-devel
swivel has quit [Read error: Connection reset by peer]
<alyssa>
LaserEyess: My opinion isn't worth very much since I don't work on the build system stuff
<alyssa>
but 100% worth it for me
<bnieuwenhuizen>
as a non-expert in the build system I think it is an improvement in that it IMO is way easier to get into. As a random dev I can now write my own build system changes instead of blundering through autotools
<alyssa>
meson is the only build system I can actually work with and not screw up (with cmake, makefiles, god forbid autotools... at best could cargo cult and even then usually screw it up)
jkrzyszt has quit [Remote host closed the connection]
<alyssa>
having a single build system for all of mesa is a big reduction in annoyances (not having to worry about updating two build systems every time I add or delete a file when I can only test 1..)
<alyssa>
Ninja is great
<alyssa>
I can't comment on transitioning a large project (and I wasn't involved on the mesa side)
dcbaker has joined #dri-devel
<dcbaker>
LaserEyess: I did a lot of the work, and I work on Meson upstream, so my opinion is a little biased :) Other big projects that switched you could talk to are systemd, gnome/gtk/glib, and xorg (off the top of my head)
<alyssa>
but I can't imagine starting a new nontrivial C project and using anything but meson
<alyssa>
then again I can't imagine starting a new nontrivial C project in $CURRENT_YEAR 😉
<bnieuwenhuizen>
alyssa: they never start nontrivial :P
<LaserEyess>
dcbaker: biased is fine, especially if the bias comes from working with upstream
gawin has joined #dri-devel
<LaserEyess>
oh, I read that wrong, you *are* upstream
anujp has joined #dri-devel
gouchi has joined #dri-devel
<dcbaker>
To be fair, I started working on Meson upstream for the benefit of Mesa
<dcbaker>
So from the point of view of "Can I get reasonable changes upstream?" I can say that yes, you can
<alyssa>
"I am upstream" is such an intimidating sentence. Such power.
<dcbaker>
I was thinking of the guards from the original Baulder's Gate
<zmike>
oh
<dcbaker>
but I'm sure they stole it from Judge Dredd
<zmike>
prob
unsolo has joined #dri-devel
aperezdc has joined #dri-devel
apinheiro[m] has joined #dri-devel
atulu[m] has joined #dri-devel
aura[m] has joined #dri-devel
chema has joined #dri-devel
<alyssa>
Upstream thinks downstream is too slow, downstream thinks upstream is too fast, ~~we get home and cuddle~~
chivay has joined #dri-devel
RAOFhehis[m] has joined #dri-devel
cleverca22[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest3404 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
exit70[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
go4godvin has joined #dri-devel
HayashiEsme[m] has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
Mershl[m] 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
nielsdg has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
MrR[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
ServerStatsDiscoverertraveler4 has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
Venemo__ has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
zzag[m] has joined #dri-devel
aperezdc is now known as Guest3425
<bnieuwenhuizen>
alyssa: the fun part is when you're both upstream and downstream. Cue stuff with ChromeOS
camus1 has joined #dri-devel
pmoreau is now known as Guest3426
<dcbaker>
I am the stream!
<bnieuwenhuizen>
nah, you don't do the middle :P
camus has quit [Ping timeout: 480 seconds]
<MrCooper>
ajax bnieuwenhuizen: another issue with mailbox was that the X server happily replaces an old PresentPixmap with a new one even if the new buffer isn't ready yet, which can result in missed refresh cycles if the client queues multiple frames with the same target MSC
macromorgan is now known as Guest3431
Guest3431 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
frytaped has quit [Quit: went bye bye]
frytaped has joined #dri-devel
frytaped is now known as Guest3433
Guest3433 has quit []
frytaped_ has joined #dri-devel
ybogdano has joined #dri-devel
go4godvin is now known as Guest3436
frytaped_ is now known as go4godvin
<ajax>
LaserEyess: worth it.
xexaxo_ has quit [Ping timeout: 480 seconds]
<ajax>
LaserEyess: i would say larger projects stand to benefit _more_ from switching, ceteris paribus
<ajax>
like, tiny autotools project, cost of switching fairly high, benefit relatively low. huge autotools project, moderate cost, high benefit.
aravind has quit [Ping timeout: 480 seconds]
<ajax>
i would probably even say that if we'd had meson at the time, we probably still would have broken up the x11r6 monorepo, but not nearly as finely as we did
<ajax>
MrCooper: um. why is it xserver's job to make sure the pixmap is ready to present, other than the fences/etc named in the present request itself?
<bnieuwenhuizen>
ajax: why is not xserver's job? I think whose job it is is underspecified, and in practice X11 doesn't so we have to do it in the WSI though the fence waits
<ajax>
uh
<ajax>
we say so because we are the xserver implementors
<ajax>
and the direct parallel is mit-shm pixmaps
<ajax>
in which by the time the server gets the CopyArea request to source from, the client has promised the pixmap's data is fixed and ready
<bnieuwenhuizen>
yeah, in practice with implicit sync the GPU is still processing stuff
<bnieuwenhuizen>
which is funny when you miss the flip because KMS ends up doing implicit sync
<bnieuwenhuizen>
for FIFO that isn't too problematic as you would have been late anyway, but for MAILBOX it matters
<ajax>
bnieuwenhuizen: okay but. the PresentPixmap request has a wait fence, which can be a shm fence. if the client needs to signal that dependency there's an in-band way to do so
<LaserEyess>
ajax: thanks for the feedback, it does look like once the initial hurdle of converting to meson, everything else becomes much easier
<ajax>
and we're just not using it because... we're choosing? to be bad?
<ajax>
i would like us not to be bad, please
<bnieuwenhuizen>
IIRC for the mailbox stuff that still resulted in issues (tried that before putting the fence wait for the present), but I don't remember what the exact issue was
<ajax>
interesting
<ajax>
again, not blaming you, sorry if i sound accuse-y, just trying to get my head around the issues
<dcbaker>
LaserEyess: also gstreamer is using meson, I think they might have converted before we did actually. #mesonbuild here (or on matrix) has several people who have converted non-trivial projects as well, plus they're generally pretty helpful
<bnieuwenhuizen>
no offense taken, and I would like the fence solution to work too. But at the time I got lost in the xserver present code
* airlied
has vague memories of trying to add more options to the x11 present mode
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<bnieuwenhuizen>
I'm happy to test stuff again if you have something I just don't remember why the shm fence stuff didn't work out
Guest3425 is now known as aperezdc
tzimmermann has quit [Quit: Leaving]
xexaxo_ has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
gawin has joined #dri-devel
sadlerap has quit [Quit: sadlerap]
<gawin>
hello again, can thread sanitizer give false positive in mesa drivers?
sadlerap has joined #dri-devel
<gawin>
context: some tests in r300 are randomly failing, but when tests are running really slow (for example with valgrind) it doesn't happen, I suspect some synchronization issues, though thread sanitizer is often reporting code which is covered by mutex locking
<Ristovski>
gawin: probably a useless remark, but I remember hitting some weird corner case where the sanitizer libs were built with a different version of the compiler that was used to compile the target executable. that too ended up in "cursed" behavior. But given packaged versions from whatever distro, shouldn't really happen
<Ristovski>
again, probably useless
Ahuj has quit [Ping timeout: 480 seconds]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
swivel has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
xexaxo_ has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
<airlied>
jenatali: okay I've looked at the API exposing spec constants, and they are user picked IDs for GLSL and SYCL has some wierd internal process but they are picked to remain fixed
<airlied>
OpenCL C doesn't seem to expose them at all from what I can see
<airlied>
So I think they don't change across link, and I think we should should assign them at spirv->nir time and not bother with the compile pass
gouchi has quit [Quit: Quitte]
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
camus1 has joined #dri-devel
<jenatali>
airlied: What if you link two programs that were specialized during compile for the same spec constant with different values?
<jenatali>
I filed an issue to figure out what's supposed to happen and IIRC they said the compile specializations should stick
<airlied>
jenatali: oh where was the issue, I just asked on the spirv-tools about linking
<jenatali>
I can find it, gimme a few
camus has quit [Read error: Connection reset by peer]
fxkamd has quit []
<jenatali>
Hm, maybe I just talked myself into it working a particular way
<airlied>
jenatali: yeah I think there's a lot of scope for saying that behaviour is undefined :-P
<airlied>
esp as without APIs exposing it it's just hard to know how we'd expect users to use it
<airlied>
I've written clover support using clc codepaths for now, just fixing some bugs it and I'll push it out
<jenatali>
Fair enough
<jenatali>
I wired it up using SPIRV-Tools
<airlied>
yeah all these passes over spir-v start to add up in my mind :-P
<airlied>
jenatali: one question parseBinary does 3 passes, but you never use the iteration counter
<airlied>
is it just each pass is transformative internally, or the info from one pass reused in the next one?
<jenatali>
In theory, I think it could be done in one pass by storing more info
<alyssa>
jenatali: it's all O(n), who cares about constant factors? :-p
* alyssa
has been learning a lot at uni!
<jenatali>
I don't remember if each pass has a specific purpose and all 3 are always needed, or if some modules complete in fewer passes
* jenatali
also didn't write that :)
* airlied
thankfully never learned O(n) at uni :-P
* airlied
gets to remain blissfully ignorant on how algorithmic crap my code it
<jenatali>
airlied: I know jekstrand wanted to replace that stuff by doing the parsing in vtn
<alyssa>
airlied: well if you have for (i < n) { .. } that's O(N), but if you have it twice for (i < n) { for(j < n) { ... } } that's O(2N) and that's all you really need to know /s
<jenatali>
2N? N^2?
<alyssa>
jenatali: thatsthejoke.jpg
<jekstrand>
What did I want to do?
<alyssa>
cd /me sets up dim
<alyssa>
Setting up drm-tip ...
<alyssa>
....I do not have the disk space for this do I.
<airlied>
alyssa: probably not
<Sachiel>
time to get the new macbook, presumably it has a larger drive
<airlied>
get a usb dis
<airlied>
disk
<alyssa>
I have one but.. slow
<alyssa>
can I delete things before this runs out of space--- nope
shashank1202 has joined #dri-devel
<airlied>
no part of using dim is when you push patches that tip gets reconstructed
<airlied>
so we spot collisions early
<Ristovski>
Ok dumb question - what is "dim"?
<airlied>
drm im
<alyssa>
Ristovski: a tool to make people who use chromebooks for kernel dev feel dim witted.
<airlied>
drm maintainer tools
<Ristovski>
I see
<airlied>
"drm inglorious maintainer"
* airlied
only found that out now, after using it for years
<airlied>
but yeah you probably want some disk space, you don't usually have to actually build tip
<airlied>
just keep the source tree around for merging
<vsyrjala>
hmm. why is my dim directory 55GiB?
<vsyrjala>
CONFIG_DEBUG_INFO=y
<vsyrjala>
# CONFIG_DEBUG_INFO_REDUCED is not set
<vsyrjala>
naturally
<airlied>
my drm-tip checkout is 1.2G
<airlied>
the main worktree is 1.6G, I build into out of tree subdirs
* Ristovski
looks at his 106GB /tmp..
<vsyrjala>
hmm. can i tell git to nuke the original worktree somehow? dinq no longer a thing and it still points there
danvet has quit [Ping timeout: 480 seconds]
<vsyrjala>
seems to require manual work. meh
<airlied>
vsyrjala: I think the initial work tree is fixed
<airlied>
since all the other worktrees just point into it's .git
<vsyrjala>
the man page says something about 'git worktree repair' needed if you move it manually
<vsyrjala>
maybe i can just retarget it to the current branch
<vsyrjala>
or i just let it sit there and rot
<airlied>
I think retargetting it might be possible
<jenatali>
jekstrand: The clc code uses SPIRV-Tools to run passes over some SPIR-V to parse out metadata, you wanted to replace that with parsing the metadata in vtn
<jekstrand>
jenatali: I'm not sure I do anymore
<jekstrand>
Or at least I'm not sure how much I care