<mahkoh>
In certain places mesa will just loop on dispatching wayland messages if this field is set. Nowadays I'd expect this sync to be mostly unrelated to buffer release message.
jfalempe_ has quit []
<mahkoh>
I saw mesa emitting a bunch of these syncs in a row (without any other wayland messages) in an application I was testing.
jfalempe has joined #dri-devel
<mahkoh>
(I'm suspecting that it was mesa. I didn't see any other involved code using wl_display_sync.)
MrCooper has quit [Read error: Connection reset by peer]
<daniels>
mahkoh: well it's right after a wl_surface_commit and other protocol requests in the snippet you posted, so you'd at least see those rather than just back-to-back syncs
MrCooper has joined #dri-devel
<daniels>
it's there for two reasons: partly because older versions of some compositors used to not flush after sending wl_buffer.release events, so you'd need something else like frame or sync to get the release event out of its queue
<mahkoh>
True, I guess it's not mesa after all.
<daniels>
and secondly, because you want _some_ kind of limiting on how fast you issue commits, rather than just sending so many messages you fill up the sendq
<daniels>
(you'll only hit that path if you have eglSwapInterval(0) i.e. completely free-running client not using fifo/ct or frame)
<mahkoh>
But isn't this already throttled by the swapchain length? If you're committing faster than the compositor can handle, you'll eventually run out of buffers.
Haaninjo has joined #dri-devel
jkrzyszt has joined #dri-devel
<daniels>
yeah, true
diffender has joined #dri-devel
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
diffender has quit [Remote host closed the connection]
<daniels>
hakzsam: hmm, I wonder if one of the shared runners is sick - python-test just died halfway through without reporting failure, then looked like it sort of spontaneously restarted
cmichael has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
aradhya7 has joined #dri-devel
glennk has quit [Remote host closed the connection]
mayank has quit []
mayank has joined #dri-devel
mayank has quit [Remote host closed the connection]
fahien has quit [Ping timeout: 480 seconds]
mceier has joined #dri-devel
warpme has joined #dri-devel
kts has joined #dri-devel
fahien has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
pcercuei has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
guludo has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
crabbedhaloablut has quit []
Jeremy_Rand_Talos__ has joined #dri-devel
crabbedhaloablut has joined #dri-devel
fahien has joined #dri-devel
Company has joined #dri-devel
legiauxmanau has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
mayank has joined #dri-devel
frankbinns2 has quit [Read error: Connection reset by peer]
legiauxmanau has quit [Remote host closed the connection]
himal has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
fahien has joined #dri-devel
fab has joined #dri-devel
<daniels>
DavidHeidelberg: so what's the plan with the fedora-release job? is there something blocking us from disabling LTO in pre-merge?
nerdopolis has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
mayank has quit [Remote host closed the connection]
tango_ has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
fahien has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fahien has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
fahien has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
himal has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
amarsh04 has quit []
Daanct12 has quit [Quit: WeeChat 4.4.2]
fahien has joined #dri-devel
JuanDaugherty has joined #dri-devel
u-amarsh04 has joined #dri-devel
thecollaboran147 has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
fahien has joined #dri-devel
frankbinns has joined #dri-devel
kts has quit [Quit: Leaving]
garrison has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
aradhya7 has quit [Quit: Connection closed for inactivity]
mdroper has joined #dri-devel
JuanDaugherty has quit [Quit: JuanDaugherty]
kzd has joined #dri-devel
sukuna has joined #dri-devel
dsimic is now known as Guest7093
dsimic has joined #dri-devel
Guest7093 has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
servik has quit [Ping timeout: 480 seconds]
<ernstp>
agd5f: is that a good list of patches for 6.11.5 stable...? only: always apply the powersave optimization & Only force workload setup on init
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
Duke`` has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
legiauxmanau has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
Duke`` has joined #dri-devel
legiauxmanau has quit [Remote host closed the connection]
legiauxmanau has joined #dri-devel
legiauxmanau has quit [Remote host closed the connection]
<legiauxmanau>
So the moment you add a next power to low end bits, it is going to be uniquely encoded , you pass indexes as inputs to the second operand. So the encoder gives 443-72-256=115 to the 6th power in pseudo code. so the bottom encoder get's also unique even though we treated it differently dma stride for indexes is some X number, it would not need the fifo mode cause they are contiguous. so
<legiauxmanau>
the operand two has passthrough indexes it get's no modifications such as last element+1+powerbase i.e 32 or 64. The dma itself should look like this: write address of source whenever 115 has 1bit in, then 120 has 1 bit in. or 0 when 125 has zero bit in. now howto replace the 1's with 115 and 1 with 120 and 0 with 0, it is possible only when something overflows or corrupts , but howto
<legiauxmanau>
make it overflow at 120, so it needs to access some register that increments the counter that says it tranferred nothing, but resumes from 120. in other words source access register needs to be at 120 and bytes transferred none, so source is not incremented, so that can be realized if you have source incr counter whatever the dest counter is, such as 120 got 0, source stride is now 0 and
<legiauxmanau>
it repeats the source location with say address 120, so if another one never comes it graduates with whatever it had, so , but if dest counter strides to base+125, next time, the source is also 125 now that is some way of doing it. But there are others.
sima has quit [Ping timeout: 480 seconds]
legiauxmanau has quit [Remote host closed the connection]
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
HerrSpliet has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
alanc has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
odrling has quit [Remote host closed the connection]
odrling has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
Duke`` has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<DavidHeidelberg>
MrCooper: Heya, I'm little bit concerned. It seems lot of people are interested in Mesa performance, thou probably no people who knows how LTO/IPO works are between them.
<DavidHeidelberg>
I was hoping doing the experiment enabling LTO on the nightly pipeline, but seems like no-one is interested to help out. I getting convinced that maybe the CPU perf doesn't matter that much to most people.
mvlad has quit [Remote host closed the connection]
guru_ has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
fahien has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
guludo has quit [Quit: WeeChat 4.4.2]
anholt has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
<Company>
DavidHeidelberg: my guess would be that Mesa doesn't benefit too much from LTO because it's (a) only a passthrough layer from app to kernel, so there's not much to gain from inlining/reordering things and (b) due to its heavy vfuncification in the relevant places not likely to gain a lot from LTO
fahien has joined #dri-devel
nerdopolis has joined #dri-devel
<Company>
I played a bit with LTO in GTK because I had hoped that it inlines all the getters we have, but it didn't help much - the big difference for GTK was around -O2 and maybe a bit from -O3 which some distros tend to forget because they do buildtype=plain and then screw up the flags
<DemiMarie>
Company: how much would there be to gain from dropping the vfuncs and going to switch statements instead?
<Company>
that was an issue in the early days of meson in aprticular, no idea if that's still a problem
docmax_ has joined #dri-devel
<DemiMarie>
For those who want long-running Vulkan compute and don’t want to wait for preempt fences integration with WSI, could there be a VK extension that, when enabled, enables long-running compute and breaks WSI, unless one has new drivers or the compositor offers drm_syncobj?
<Company>
DemiMarie: no idea, but I'd expect the gain to be when you can avoid vfuncs - or prove to the compiler that there's only one possible function ever so it ccan optimize out the vfunc
<Company>
but no idea if any compiler can do that
<DemiMarie>
Company: the idea is to change the source code so that it uses enums and switches instead of vfuncs
<heat>
compilers can devirtualize
<DemiMarie>
because CPUs hate indirect branches
<DemiMarie>
heat: can they turn vfuncs into switch/case when there are multiple possibilities?
<heat>
probably
<heat>
assuming it's a performance win of any kind
<Company>
you can play with godbolt if you're curious
<heat>
i dont know however if you can use the C struct stuff_ops pattern and still expect the compiler/LTO to do it's thing... honestly never tried that
<Company>
but compilers do unexpected things all the time
<DemiMarie>
Regarding the VK ext idea: the other purpose would be for hardware that can't preempt (like Asahi) and therefore needs everything pinned longterm
<DemiMarie>
this ensures that everything is properly allocated and accounted for
<DemiMarie>
If your compositor supports syncobj or if the driver has preempt hooked up then things work, otherwise WSI fails
<Company>
it's also a thing that inlining often doesn't help much, because the slowness is notsolved by doing less work but by having more relevant memory in L1
fahien has quit [Ping timeout: 480 seconds]
<DemiMarie>
How much of that overhead is NIR?
<Company>
at least that's the thing for most GTK code
<Company>
avoiding a pointer chase is worth more than reordering/inlining the instructions
<heat>
quite honestly depends on how the code is written
docmax__ has quit [Ping timeout: 480 seconds]
<heat>
heavy C++ code tends to benefit quite a lot, C code (particularly carefully written code like the linux kernel) usually doesn't get too much from LTO
<heat>
LTO inlining doesn't matter too much if you already static inline __always_inline'd everything into headers