adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
kevintang_ has joined #dri-devel
Guest3615 has quit [Ping timeout: 480 seconds]
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
macromorgan is now known as Guest3617
Guest3617 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Company has quit [Quit: Leaving]
aravind has joined #dri-devel
Danct12 has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
Duke`` has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
camus1 has joined #dri-devel
vivijim has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
Kayden has quit [Quit: reboot]
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
shashank1202_ has quit []
Kayden has joined #dri-devel
thellstrom has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
kevintang has joined #dri-devel
kevintang has left #dri-devel [#dri-devel]
sdutt has quit [Remote host closed the connection]
sdutt has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
gpuman has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
crabbedhaloablut has joined #dri-devel
agd5f_ has joined #dri-devel
danvet has joined #dri-devel
kevintang has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
fxkamd has quit []
lemonzest has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
tursulin has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
itoral has joined #dri-devel
cafuffu has joined #dri-devel
pnowack has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
cafuffu has quit []
cafuffu has joined #dri-devel
f11f13 has quit []
cafuffu has quit [Remote host closed the connection]
achrisan has quit []
rgallaispou has joined #dri-devel
<pq>
haasn, do you mean whether the current framebuffer has an alpha channel you can use in GL, or whether that alpha channel is actually used by the winsys for display?
dongwonk has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
<pq>
Company, I wish you stayed in IRC long enough that I could tell you e.g. Weston already uses EGL surfaceless platform with pbuffers as a means to do GL in the test suite without any need for any display server nor GBM.
X-Scale` has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
dongwonk has joined #dri-devel
X-Scale has quit [Ping timeout: 480 seconds]
dongwonk has quit [Remote host closed the connection]
dviola has joined #dri-devel
pcercuei has joined #dri-devel
frytaped has quit [Quit: went bye bye]
frytaped has joined #dri-devel
cafuffu has joined #dri-devel
cwabbott_ has quit []
gawin has joined #dri-devel
cwabbott has joined #dri-devel
kgz has quit [Ping timeout: 480 seconds]
Prf_Jakob has quit [Ping timeout: 480 seconds]
jadahl has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
rg3igalia has quit [Ping timeout: 480 seconds]
rg3igalia has joined #dri-devel
jadahl has joined #dri-devel
kgz has joined #dri-devel
Prf_Jakob has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
Ahuj has joined #dri-devel
cafuffu has quit [Remote host closed the connection]
mclasen has joined #dri-devel
<mlankhorst>
mripard_: I've reverted the vc4 changes from drm-misc-fixes as they were not included in the last pull req to linus, I think if you want them in, you need to convince Dave or Linus to pull it.
tzimmermann has joined #dri-devel
cafuffu has joined #dri-devel
mclasen has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<airlied>
mlankhorst: I think we might need to rebase fixes if we can
<mlankhorst>
Yeah, I did that
<airlied>
mlankhorst: just saw, excellent thanks
<mlankhorst>
np :)
elongbug has joined #dri-devel
Lucretia has quit []
Lucretia has joined #dri-devel
X-Scale has joined #dri-devel
camus has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
Lucretia has quit []
camus1 has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
<danvet>
mlankhorst, yeah, but also we need to fix this properly
sdutt has joined #dri-devel
<dolphin>
danvet, airlied: Pull request sent, after you pull it, I'll do a backmerge to bring in the dma-resv stuff for mauld and mlankhorst
<mlankhorst>
thanks
Lucretia has quit []
ppascher has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
fxkamd has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
shashank1202_ has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
DPA has joined #dri-devel
<haasn>
pq: the latter
<haasn>
e.g. on vulkan the combination RGBA8 + ALPHA_OPAQUE_BIT would have no usable alpha channel
<haasn>
even though the framebuffer texture technically has one
<haasn>
I see that in mesa this decision is made (for vulkan) on the basis of whether or not the chosen visual has an alpha channel or not
<haasn>
(on X11)
ppascher has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
Bhawan has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
nchery has joined #dri-devel
Bhawan47 has joined #dri-devel
Bhawan47 has quit []
Bhawan11 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Bhawan has quit [Ping timeout: 480 seconds]
cafuffu has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
dongwonk has joined #dri-devel
Lucretia has joined #dri-devel
ccr has quit [Remote host closed the connection]
ccr has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
<pq>
haasn, GL does not know that, EGL might know it if the extension to control it is there. On X11 specifically, you'd see it from the X11 Visual if you can get that.
<pq>
haasn, for Wayland, it depends on which pixel format the EGL or WSI implementation picks. The assumption on Wayland is that if alpha channel exists, the winsys uses it, IIRC.
<zmike>
pepp: is anyone working on that tomb raider regression? I tagged it for 21.3 since it seemed like a significant issue for a AAA game, but if nobody has time now then I guess it can't block the release forever
<pq>
haasn, so your definition of "usable" is "winsys uses it", not "one can store and retrieve values to/from it".
<haasn>
the high level question I'm answering here is whether I should default to stripping the alpha channel from an image (e.g. by blending against a solid or checkered background) or default to passing it through to the framebuffer
<haasn>
and I'm basically trying to be as conservative as possible in that I only write alpha values to the framebuffer if I know the window is transparent
<haasn>
on vulkan this is easy to figure out, but on opengl the current status quo is that I'd never take this prerequisite to be true
<pq>
what result do you want to achieve with that? Do you want that image to be always opaque?
<haasn>
no, I basically want it to be blended against a chosen background color (instead of implicitly against black) whenever it can't be made truly transparent
<haasn>
simply always writing an alpha channel is equivalent to blending against black on windowing systems that don't support true transparency
<haasn>
though I guess now that I think about it again it is kind of a non-problem in a way
<pq>
that sentence seem a bit confused, but I guess I get the idea
<haasn>
and I should probably just always blend against a background color unless the user specifically requests a transparent background
<pq>
so you are doing a blit like copy in any case?
<haasn>
not entirely, I'm sampling from a texture
<pq>
that the thing
<pq>
why not do the "blend" in the fragment shader?
<haasn>
the question is what to put into the ... in if (...) { color.rgb += background * (1 - color.a); color.a = 1.0; }
<pq>
should be extremely cheap, not like another rendering pass
<pepp>
zmike: I don't own this game so it's not something I can really fix
<pepp>
zmike: unless you can maybe create a apitrace/rdc of the issue?
<haasn>
possibilities include if (!user_requests_transparency), but I was trying to go for if (!winsys_supports_alpha_compositing)
<pq>
haasn, winsys_supports_alpha_compositing is difficult to determine portably. I think at the very least you need to special-case each window system, and then on X11 you have to know if a compositing manager is even running.
<zmike>
pepp: I have an apitrace already, how can I send it to you?
<zmike>
it's big
<haasn>
hilariously even with a compositor I have never ever been able to get alpha compositing working on X11
<haasn>
(without hacks such as reading the root framebuffer and doing blending in the application code, which is what some terminal emulators will do)
<pq>
haasn, in the X11 case, you have choose the right *Config with the magical X11 Visual that makes it happen. You cannot do that with eglChooseConfig.
<haasn>
but yeah I think I'll settle for `if (vulkan_alpha_mode != alpha_pre_multiplied_bit)` and on opengl just default to `true`
<haasn>
pq: I was trying to use glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE);
<haasn>
which I'd had _hoped_ would accomplish something
<pq>
haasn, well, OpenGL on Wayland with framebuffer alpha bits > 0 you *will* get transparency, unless you use the EGL extension to make it opaque.
<haasn>
good to know
<haasn>
(does anybody use wayland yet?)
* MrCooper
shyly raises hands
<MrCooper>
haasn: could be a GLFW issue if it doesn't pick the alphaful X11 visual with that
<daniels>
haasn: nope
<haasn>
according to xwininfo it picks the right visual
<pq>
I've never even heard of GLFW_TRANSPARENT_FRAMEBUFFER. Sounds like an abstraction glfw invented trying to make things easier to users.
<haasn>
it just.. isn't transparent
<haasn>
I suspect the compositor, not glfw
cafuffu has joined #dri-devel
<MrCooper>
haasn: note that alpha needs to be pre-multiplied, in particular, fully transparent pixels need to be all 0s
<pq>
GL does not pre-multiply on your behalf
<pq>
though getting that wrong should be fairly obvious and not look like "it's simply opaque"
<MrCooper>
is it well-defined what happens if the alpha value isn't consistent with the non-alpha ones?
shashank1202_ has quit []
<haasn>
(it probably results in everything getting brighter than it should be)
<pq>
MrCooper, not in general, depend on what the drawing APIs do with overflows. GL clamps to 1.0 on blending by default IIRC.
<pq>
so yeah, brighter
<haasn>
blending math is usually current.rgb * (1 - overlay.a) + overlay.rgb
<haasn>
iirc
<haasn>
(when color.rgb is pre-multiplied)
<pq>
yup
<haasn>
I mean my transparency code works on e.g. wayland
<haasn>
so the opengl shader and pixel values being written are not the issue
<haasn>
I also have not been able to find any other programs that purport to offer transparency which offer transparency on X11 for me
<pq>
do you actually run a X11 compositing manager? which one?
<MrCooper>
sounds like a broken compositor maybe then
<zmike>
pepp: if you have a Dropbox or something let me know
<haasn>
pq: I was using picom (aka compton) with --backend=glx
<cmarcelo>
alyssa: was playing with gtest on panfrost last night... one thing that gets in the way is making some /headers/ C++ friendly, e.g. the designated initializers for arrays is something that C++ (at least g++) is not a fan -- the ones like: arr = { [N] = something, [M] = something else }.
<dcbaker>
Just make the tests require c++20?
<cmarcelo>
dcbaker: I'm not sure the array thing is in C++...
<cmarcelo>
some other time I'll see if we can workaround that without losing much -- similar "roadbump" affects anv tests too.
<dcbaker>
Yeah, relying on gnu++20 is a stretch
ybogdano has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest3673
Guest3673 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
gouchi has joined #dri-devel
adjtm is now known as Guest3674
adjtm has joined #dri-devel
Guest3674 has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
Lucretia has quit []
Lucretia has joined #dri-devel
<jekstrand>
bnieuwenhuizen, dj-death: I think I've got common sync/submit basically working.
<jekstrand>
Jenkins is blowing up but it seems fine locally so I'm still debugging that.
<jekstrand>
Over-all, though, I'm really happy with it
mlankhorst has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 483 seconds]
<dj-death>
jekstrand: cool, will look into it
ybogdano has joined #dri-devel
<zmike>
imirkin: it sounds like you're saying that gallium expects any is_format_supported call with sample_count > 1 to just return whether the driver can support multisampling at that samplecount in general and ignore the format altogether?
<mdnavare>
MrCooper: agd5f_: While running some games on a system with no display, how can we tell compositors to not require a display or perhaps use a virtual display or something?
iive has joined #dri-devel
<emersion>
depends on the compositor
<emersion>
most of them support a headless mode
<mdnavare>
Is there a way we can force the headless mode so the games dont keep wanting a display
mlankhorst has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
<emersion>
yes, but how you do it depends on the compositor you're using
<mdnavare>
We are using Wayland I believe
camus1 has joined #dri-devel
<emersion>
are you using Mutter, or KWin, or Sway, or something else?
<emersion>
Wayland is just the protocol - all of the above ^ are compositor implementations
shashank1202_ has joined #dri-devel
agd5f_ has quit []
<mdnavare>
Wayland Mutter
elongbug has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
<agd5f>
mdnavare, you can use something like vkms or in amdgpu, we have a virtual display feature that provides a software kms interface
camus has quit [Ping timeout: 480 seconds]
<karolherbst>
mslusarz: you started the ikiwiki based nouveau wiki, right?
<mdnavare>
agd5f: Okay yes VKMS is probably something we can try, but no way to just force the compositor to just go with headless mode?
<agd5f>
mdnavare, not sure off hand which compositors support that functionality
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<alyssa>
agd5f: why does amdgpu have a virtual display feature?
<jekstrand>
dj-death: Found why I was killing Jenkins. Should be fixed now, in theory.
<alyssa>
older than vkms and can't break the uabi?
pnowack has quit [Quit: pnowack]
<agd5f>
alyssa, for virtualization, servers, and emulators
<mdnavare>
jekstrand: Do we have a specific method to test Games in headless mode on Intel stack?
<jekstrand>
not sure what you mean
<jekstrand>
Kayden: ^^
<jadahl>
mdnavare: you can run mutter or gnome-shell with --headless and it will either run with a render node or with a surfaceless egl display
<dj-death>
jekstrand: you still have a few hours before I start looking :)
<jekstrand>
dj-death: :D
<jekstrand>
dj-death: Running on Jenkins again. I've got a good feeling about this time
<emersion>
mdnavare: maybe ask jadahl for the mutter headless mode
* jadahl
too tends to reply to questions and then after read the backlog :P
Danct12 has quit [Ping timeout: 480 seconds]
agd5f has quit [Remote host closed the connection]
dllud has quit [Remote host closed the connection]
agd5f has joined #dri-devel
<mdnavare>
okay great thanks emersion and jadahl
dllud has joined #dri-devel
<jadahl>
mdnavare: if you just want to run mutter and render into nothingness, then pass both --headless and e.g. --virtual-monitor 1920x1080 and it'll just paint and paint and paint into a texture noone will ever see
<mdnavare>
okay gotcha
<mdnavare>
great i think this should help
JohnnyonFlame has joined #dri-devel
<graphitemaster>
When can we expose sane precision of uvs for sampling hardware in any of these god for saken APIs
<graphitemaster>
Tired of 24 bit int, 8 bit fractional of uv selection :(
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
alatiera is now known as Guest3683
jkrzyszt has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kenjigashu has joined #dri-devel
Guest3683 has quit []
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
cafuffu has quit [Remote host closed the connection]
DPA has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
kenjigashu has quit []
<anholt>
daniels: any idea what's up with this failure I've seen a couple times recently? it seems that we never get to actually running the contents of the CI job after cloning. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/14983547
DPA has joined #dri-devel
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
curro has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
vivijim has joined #dri-devel
vivijim has quit []
ybogdano has quit [Remote host closed the connection]
vivijim has joined #dri-devel
fxkamd has quit []
shashank1202_ has quit [Quit: Connection closed for inactivity]
<emersion>
vsyrjala: oh, very nice benchmark
<emersion>
i was actually investigating amdgpu test commit perf issues
<emersion>
(on amd, if drm core passes, driver bandwidth computations take a looooong time)
<vsyrjala>
emersion: i think i saw that mentioned somewhere. which is i guess why this idea popped into my head again :)
<vsyrjala>
would be nice to have something in ci to avoid someone accidentally adding a 5ms loop into atomic_check
<emersion>
indeed!
<emersion>
i'll have a look and try it on amd
Duke`` has quit [Ping timeout: 480 seconds]
<daniels>
anholt: uh, that looks pretty wild - almost like a cache hit gets marked as a failure? shell is awesome. we haven't changed the pre-clone script any time recently tho ...
<anholt>
I think this is about #3 of this failure I've seen this week. Yeah, feels like something else maybe going on with the runner not related to pre-clone?
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
rgallaispou1 has joined #dri-devel
rgallaispou1 has left #dri-devel [#dri-devel]
gouchi has quit [Remote host closed the connection]
camus1 has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
camus has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
anholt_ has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
<jekstrand>
dj-death: I just found a bit of a hole in the timeline semaphores implementation...
<jekstrand>
I think we need to disable binary semaphore sharing whenever we don't have DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT
<bnieuwenhuizen>
why?
<jekstrand>
Otherwise, if someone uses a timeline semaphore with wait-before-signal and uses that to trigger a shared binary semaphore, we have no way to detect when that binary semaphore has materialized.
<bnieuwenhuizen>
jekstrand: in radv we do it the other way around. Disable timeline semaphore sharing if we don't have the IOCTL
<jekstrand>
But you can do it with a non-shared timeline semaphore and a shared binary one
<jekstrand>
No timeline semaphore sharing required
<bnieuwenhuizen>
why would we need to wait for the binary semaphore to materialize then?
<bnieuwenhuizen>
aren't binary semaphores guaranteed to be submit-before-wait?
<jekstrand>
sort-of
<jekstrand>
It's required that you vkQueueSubmit to signal it before you vkQueueSubmit to wait on it but the first vkQueueSubmit may be a wait-before-signal
<jekstrand>
And wait-before-signal is transitive. :-(
<bnieuwenhuizen>
I thought that was disallowed?
<jekstrand>
uh... maybe?
<bnieuwenhuizen>
"Any semaphore member of any element of the pWaitSemaphoreInfos member of any element of pSubmits that was created with a VkSemaphoreTypeKHR of VK_SEMAPHORE_TYPE_BINARY_KHR must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution"
<bnieuwenhuizen>
transitively all dependencies must have been submitted
pushqrdx has quit [Read error: Connection reset by peer]
<jekstrand>
Awesome!
<bnieuwenhuizen>
and in radv if timeline syncobj aren't supported we use a callback based system instead of a thread to make sure it evenrything happens synchronously to the submit
<bnieuwenhuizen>
to ensure the thread doesn't end up introducing any wait-before-submit cases internally
pushqrdx has joined #dri-devel
ybogdano has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
pcercuei has quit [Quit: dodo]
iive has quit []
gio has quit [Ping timeout: 480 seconds]
fxkamd has quit []
<jekstrand>
bnieuwenhuizen: This is turning out to be thornier than I was hoping....
<bnieuwenhuizen>
jekstrand: I thought that was the point of sharing it :)
<jekstrand>
bnieuwenhuizen: I've architected everything around a per-vk_sync WAIT_PENDING
<jekstrand>
bnieuwenhuizen: It is
<jekstrand>
bnieuwenhuizen: I was hoping I had it cracked and was ready to drop the wip
<jekstrand>
So much for that. :D
camus has joined #dri-devel
<jekstrand>
One option would be to never thread if we don't have shared timeline semaphores
<jekstrand>
Have some sort of device-wide lock and make each vkQueueSubmit flush out all the other queues when it gets done.
<jekstrand>
in case it unblocks something
camus1 has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
that'd be one way
<bnieuwenhuizen>
in radv we track waiters in legacy timeline semaphores
<jekstrand>
I can do that too
<jekstrand>
The emulated semaphores are in core code
<jekstrand>
It just seems really dirty
<jekstrand>
But I don't know
<jekstrand>
At the end of the day, I think it's the same in terms of locking and who executes what
<jekstrand>
It's just a matter of algorithmic complexity
<jekstrand>
Is it better to walk all queues and check their most recent submissions or is it better to walk all the waiters of a thing
<bnieuwenhuizen>
just seemed to me at the time that with up to 11 queues and needing to recheck all the queues every time progress was made that waiters might be less overhead, but with all the locking around maintaining wait_list in each time_point struct I dunno
<bnieuwenhuizen>
certainly didn't do any benchmarks
Lyude has quit [Quit: WeeChat 3.2]
Lyude has joined #dri-devel
<jekstrand>
Yeah, I don't know which is worse, TBH
<jekstrand>
I'm kind-of inclined to keep it simple. RADV can say "If you want perf, use a modern kernel" and let the kernel do all that per-waiter list management.
<jekstrand>
Other, younger drivers, like panvk or v3dv aren't going to have 11 queues.
<bnieuwenhuizen>
fair
<jekstrand>
OTOH, it probably isn't that hard to add a struct vk_timeline_waiter with a wait counter and a callback and stuff one it in each queue.
<jekstrand>
But then I have to write nasty async code
<Kayden>
simple is nice, how new of kernels are we talking?
<jekstrand>
For RADV, like 2 years old or so?
<bnieuwenhuizen>
5.4/5.5 IIRC for RADV
<jekstrand>
And ANV only has a couple queues
<jekstrand>
Yeah, I think simple is good
<jekstrand>
vk_device_flush() is easy
<bnieuwenhuizen>
yeah lets got there then
<jekstrand>
Ok, I'll start typing that up tomorrow
<jekstrand>
I think that *should* be the last piece.
<Kayden>
5.4 is November 2019 / 5.5 is January 2020, so not -all- that new
<jekstrand>
New enough that anyone who's running a recent distro (all gamers) has it
<Kayden>
sounds pretty reasonable
<Kayden>
yeah, exactly
<bnieuwenhuizen>
yep
<jekstrand>
If you're gaming on Ubuntu 18.04 LTS, you're probably not going to get the mesa update anyway
<Kayden>
well, and not just gamers, but people interested in vulkan tend to be running more bleeding edge stuff
<Kayden>
or at least not trailing edge :)
<Kayden>
excited to see more common code happening!
<bnieuwenhuizen>
yeah
<jekstrand>
Yeah, and this bit of common code is kind-of a big deal
<jekstrand>
synchronization in Vulkan is a bit of a mess and this means most drivers have to implement nearly none of it themselves.
<Kayden>
yeah, saves substantial amounts of pain :)
<jekstrand>
I've got one sync class in ANV for ancient kernels without syncobj wait
adjtm has quit [Remote host closed the connection]
<jekstrand>
I expect bnieuwenhuizen will want one for amdgpu internal fence things
<jekstrand>
I expect the ARM drivers will implement.... zero of them.
<Kayden>
I'm guessing you determined that we can't delete that yet, eh? :)
adjtm has joined #dri-devel
<jekstrand>
Yeah... chromeos....
<Kayden>
chromeos :)
<bnieuwenhuizen>
to be fair I have to figure out how to hook up this entire thing since we don't keep a raw DRM fd around in radv
<jekstrand>
We'll delete it in a couple years
<Kayden>
yup
<jekstrand>
bnieuwenhuizen: You don't? You go through winsys for all your syncobjs?
<jekstrand>
And, now that we have the vk_sync abstraction, it's very much not hurting anyone to keep it around. :)
<bnieuwenhuizen>
jekstrand: yep, everything goes through libdrm_amdgpu which internally uses a deduped fd for the device
<jekstrand>
bnieuwenhuizen: Can you get at said fd?
* Kayden
is now very familiar with this code
<bnieuwenhuizen>
so might need to extend libdrm_amdgpu with a "please give me the damn fd" function
<jekstrand>
bnieuwenhuizen: Yeah... That or re-implement vk_drm_syncobj yourself. Getting the fd from libdrm seems like a better plan. :D
<jekstrand>
gotta love PALs.....
<jekstrand>
They're great, so long as you only have one of them.
<jekstrand>
:D
<bnieuwenhuizen>
honestly I hate all this insistence on deduping the DRM fd from the amdgpu folks
<bnieuwenhuizen>
if it weren't for all the VA allocation code I'd probably drop libdrm_amdgpu completely
<jekstrand>
We have VA allocation code you can steal. :P
<Kayden>
was just going to suggest that, heheh
<bnieuwenhuizen>
out of curiousity have you implemented capture+replay there yet?