<MrCooper>
ajax: can an SHM fence be signalled without a thread in the client? :)
<MrCooper>
ajax: also, right now in the server the fence wait comes after the logic which determines the target MSC and replaces previous PresentPixmaps with the same target, which would need to be fixed for that to be feasible
<MrCooper>
ajax: anyway, for Xwayland my long term goal is to leave the fence waiting and mailbox logic to the Wayland compositor, just forward PresentPixmaps as directly as possible
mlankhorst has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
thellstrom has joined #dri-devel
gpuman has joined #dri-devel
kevin_tang2 has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
f11f12 has joined #dri-devel
dsrt^ has quit [Remote host closed the connection]
kevintang has joined #dri-devel
kevin_tang2 has quit [Ping timeout: 480 seconds]
dongwonk has quit [Remote host closed the connection]
kevin_tang12 has joined #dri-devel
kevintang has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
rasterman has joined #dri-devel
<pq>
Kayden, oh my, you reminded me of Unreal Tournament, the original - happy days :-D
camus1 has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
anarsoul|2 has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
kevin_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kevin_ has quit []
kevintang has joined #dri-devel
Ahuj has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
kevin_tang12 has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
pcercuei_ has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
kevintang has quit []
kevint_ has joined #dri-devel
mclasen has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<mlankhorst>
You can use openal-soft to improve sound, if you compile it with an old gcc, and drop it in place of the original openal lib.
<vsyrjala>
old gcc because some c++ abi mess?
adjtm has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
shashank1202 has joined #dri-devel
<mlankhorst>
Yeah, that old
itoral has quit [Remote host closed the connection]
gpuman_ has joined #dri-devel
itoral has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
adjtm is now known as Guest3532
adjtm has joined #dri-devel
Guest3532 has quit [Ping timeout: 480 seconds]
The_Company has quit []
Company has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
itoral has quit []
yogesh_m1 has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
vivijim has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
<Ristovski>
Alternatively -D_GLIBCXX_USE_CXX11_ABI=0 perhaps? Depends what sort of c++ abi mess it is
shashank1202 has quit [Quit: Connection closed for inactivity]
mlankhorst has quit [Remote host closed the connection]
jewins has joined #dri-devel
xexaxo has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
f11f12 has quit [Remote host closed the connection]
gpuman_ has joined #dri-devel
f11f12 has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
<ajax>
MrCooper: k well, you could do an explicit (x11) sync fence first instead? i'm starting to want to do an errata release of presentproto.txt to nail down some of these semantics
<ajax>
MrCooper: and agreed, Xwayland should be where the smarts live for this as much as possible
<ajax>
or... the client should do as little as possible different between Xwayland and anything else, and Xwayland should be as literal as it can to the wl server
gawin has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<MrCooper>
ajax: what kind of fence, which is signalled how? FWIW, a Wayland compositor doesn't strictly need any fence, it can wait as needed by polling a dma-buf fd
gpuman has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
f11f13 has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
<emersion>
ping jekstrand about that DMA-BUF extract fence IOCTL
cafuffu has joined #dri-devel
<jekstrand>
emersion: Still stuck, I'm afraid. :-(
<emersion>
:S
<jekstrand>
danvet: ^^
<emersion>
i consider this a blocking feature for continuing explicit sync work FWIW
<emersion>
it's so much nicer when you can just assume you'll always have a proper fence
<cafuffu>
ah, that sounds better than wl_egl_window_resize, but anyway shouldn't that allow changing the offset without having to change the size?
<danvet>
emersion, we can also land it with compositors as userspace
<danvet>
and I don't think they're stuck any more
<emersion>
ah, okay
<danvet>
I think ckoenig got that things work differently, and amdgpu is fixed to obey the same rules
<emersion>
well
<emersion>
will we get a brand new sync primitive?
<emersion>
iirc the answer is "likely"
<danvet>
in 10 years maybe
<emersion>
lol
<danvet>
for compositors
<danvet>
for compute and maybe VR and stuff like that hopefully a lot sooner
kevintang has joined #dri-devel
<danvet>
but for compositors I think dma_fence is here to stay for quite a while
ezequielg_ has joined #dri-devel
<emersion>
okay, so you think it's worthwhile to invest significant time to make things work with sync_file?
<danvet>
least because a lot of the smaller socs just dont do anything more
<danvet>
yeah I think so
<danvet>
we might need to add sync_file extensions for the fancy new sync primitive
<danvet>
but the container itself should survive I think
<emersion>
i also don't really like the explicit sync protocol, which carries 2 FDs each frame
<emersion>
i'd prefer something closer to timeline semaphores
<danvet>
2fd?
<emersion>
2 file descriptors representing a sync_file each
<danvet>
and yeah the compositor protocol should maybe be based on timeline fences
<danvet>
why do you need 2?
steev has quit [Ping timeout: 480 seconds]
hwentlan_ has joined #dri-devel
<emersion>
one for acquire, one for release
cwabbott_ has joined #dri-devel
jjardon__ has joined #dri-devel
<danvet>
ah yeah
steev_ has joined #dri-devel
<danvet>
well make wayland not suck, and use drm_syncobj
<emersion>
do you think it's worth it to invest time into a timeline based protocol?
<emersion>
i have the protocol all typed up already
cwabbott has quit [Ping timeout: 480 seconds]
<danvet>
yeah I think for protocol it'd be good to go with drm_syncobj
<emersion>
for drm_syncobj
<emersion>
okay
<emersion>
daniels: ^
<danvet>
since that's going to be the thing with the userfences going forward too
<danvet>
the dma-buf import/export is strictly only for implicit sync
jjardon_ has quit [Ping timeout: 480 seconds]
<emersion>
hm you mean drm_syncobj will work fine with userspace fences?
hwentlan has quit [Ping timeout: 480 seconds]
cwabbott_ has quit []
<danvet>
and frankly I don't think pipelining that will work together with user memory fences
<danvet>
yea
<danvet>
ish
<emersion>
"ish" :D
<danvet>
conceptually it has exactly the semantics of user memory fences
<emersion>
yeah
<danvet>
since that's what vk wants
kevint_ has quit [Ping timeout: 480 seconds]
ezequielg has quit [Ping timeout: 480 seconds]
cwabbott has joined #dri-devel
<danvet>
so we can stuff a user memory fence in there
<danvet>
sync_file otoh is trickier
<danvet>
but also I don't buy the plan to stuff user memory fences into implicit sync
<emersion>
alright
<danvet>
I think the only viable plan there is to just block until rendering finishes on the client side
<danvet>
maybe in a thread, maybe not
<danvet>
and once you've blocked, you don't need a fence anymore
<emersion>
i'll write a compositor impl which heavily relies on drm_syncobj timelines and assumes jekstrand's extract sync_file is available
<danvet>
so import ioctl still "works", just gives you an empty sync_file :-)
<emersion>
plz no threads
<emersion>
ah we don't have poll on drm_syncobj yet…
<emersion>
i guess it's not required to wire stuff up
<danvet>
well poll on drm_syncobj is a bit tricky
<emersion>
yea
<pq>
so that "yeah use sync_file" turned immediately into "yeah don't use sync_file" in this discussion? :-)
<danvet>
since there's no easy way to pass the "which syncobj do you care about" along
<emersion>
i'd be happy with "wait on any new sync point"
<danvet>
pq, sync_file for dma-buf import/export for interop with implicit sync
<danvet>
but maybe not sync_file for new protocols
<emersion>
sync_file can be converted to drm_syncobj
<emersion>
and back
<danvet>
emersion, yeah I guess we could have "wait on any new sync point to materialize" and "wait for any dma_fence behind a sync point to signal"
<danvet>
since you might be interested in either, depending
<emersion>
hm
<danvet>
aside from POLLIN/POLLOUT there's a few funny ones too
alyssa has left #dri-devel [#dri-devel]
<emersion>
i guess it would kind of make sense to wait for a sync point to materialize, then the user can extract a sync_file and poll on that
<emersion>
but hm
<emersion>
poll is strictly "something happened", and you don't get more feedback
* emersion
thinks about read() returning an event struct
<danvet>
that doesn't work
<danvet>
read state is per file, not per fd
<emersion>
ah, rip
<danvet>
so the app could steal events from the compositor and create fun
<danvet>
whereas I think at least that poll state is per fd
<pq>
Anything that is built on "wait in thread in the client before submitting" is not going to work for Wayland if that's going to happen behind the app's back, like in EGL or Vulkan WSI.
<ajax>
sounds more like a socket than a file then
<danvet>
but would be a good thing to double-check before we create a security bug :-)
<emersion>
then maybe add an IOCTL to create an eventfd or w/e signalled when a user-spacified event ahppens?
<danvet>
yeah, that might be more robust
<danvet>
ajax, it's pretty much af_unix, except only for dma_fence, and no actual data :-)
kevintang has quit []
gpuman has quit [Ping timeout: 480 seconds]
<ajax>
it could literally be af_unix and the messages pass the fd of the fence
<ajax>
expensive in fds though
gpuman has joined #dri-devel
<emersion>
could also be "send this value over this existing eventfd when the sync point materializes"
<ajax>
yeah, i'm liking eventfd
<ajax>
can you make an eventfd that also obeys drm ioctls and if not why not
<ajax>
because then you could reduce this problem to the one already solved for classic drm events lik evblank
<emersion>
hm i guess we could also just re-use core drm events
<emersion>
(note, that would be more friendly to BSDs, among other things)
<danvet>
headless compositor might be unhappy with that?
<danvet>
like if you neither have a render nor kms drm device
<emersion>
headless compositor can have a DRM render FD?
<emersion>
hm
<emersion>
then why are you dealing with drm_syncobj?
<danvet>
it's neat?
<ajax>
if you don't have a render device then what hardware are you talking to
* danvet
no idea
<emersion>
use vgem?
<danvet>
but yeah probably can assume a drm device exists
<ajax>
headless doesn't mean deviceless
<emersion>
^
<ajax>
it means wholly offscreen
<danvet>
the thing I'm thinking off is if v4l or camera ever gets sync support
<danvet>
then there might be some work to wean drm_syncobj from drm
<emersion>
i'd assume it won't depend on drm stuff
<danvet>
but doable
<emersion>
hm
<danvet>
so hence very mildly vary of relying on drm stuff for drm_syncobj support
<karolherbst>
soo mhhh... it seems like there is no real way of getting to know how assigned to marge, but what if dim just calls marge on the specified MR and all one need is to create an auth token and store it locally inside dim?
<karolherbst>
and then dim just calls marge-bot locally
<danvet>
but also v4l has been talking about dma-fence for years and gotten nowhere, so *meh*
<ajax>
does the kernel not already have this kind of synchronization primitive for other subsystems?
<karolherbst>
danvet, airlied: ^^
<danvet>
karolherbst, sounds like character soup to me, but go ahead?
<danvet>
ajax, wrt dma_fence we're the only ones
<ajax>
karolherbst: can you clarify "getting to know how assigned to marge" for me?
<ajax>
danvet: amateurs
<karolherbst>
danvet: well.. the idea was to let marge add s-o-b tags from the person "merging"
<karolherbst>
ehh
<karolherbst>
who
<karolherbst>
not how
<ajax>
oh i bet i can get that. the ui has it after all.
<karolherbst>
not via the API
frytaped has quit [Quit: went bye bye]
<karolherbst>
but there is also no access control in marge-bot, so anyone who can assign is able to merge stuff
frytaped has joined #dri-devel
frytaped is now known as Guest3545
gpuman_ has joined #dri-devel
<danvet>
karolherbst, marge doesn't check for "was it a developer"?
<danvet>
I thought it does that
fxkamd has joined #dri-devel
<danvet>
karolherbst, the bigger problem might be getting at the email through the uapi
Guest3545 is now known as go4godvin
<danvet>
that's hidden because it's pii
gpuman has quit [Ping timeout: 480 seconds]
go4godvin is now known as frytaped
<karolherbst>
danvet: nope
<danvet>
karolherbst, oh it's only hidden in the ui, but not in the api?
<karolherbst>
danvet: well if you have to call dim anyway, you can also configure the email to use
<ajax>
karolherbst: i'm digging at the api now and i think i may have good news in a minute...
<karolherbst>
ajax: I thought so as well when I was digging into it
<karolherbst>
danvet: it seems that way
<karolherbst>
unless I missed something
<MrCooper>
danvet: only developers can reassign MRs
<danvet>
MrCooper, yeah I had vague memories I checked that it's all sound, thx for confirming
<karolherbst>
ahh
enick_879 is now known as go4godvin
<karolherbst>
well
<MrCooper>
np, yeah we had to make sure of this when we started using Marge for Mesa :)
<karolherbst>
on the kernel level that's not enough though
<karolherbst>
you really want maintainers who can merge and developers who can do other stuff or something
<karolherbst>
dunno
<MrCooper>
what other stuff?
steev_ has quit []
<ajax>
hngh, deceptive docs
<karolherbst>
good question
steev has joined #dri-devel
<karolherbst>
maybe picking patches from the ML and stage them on a branch and create an MR for it later?
<karolherbst>
but I guess that can be done in forks
<ajax>
you can get a list of state changes to the MR, as long as you're satisfied with that list being of length 1?
<ajax>
but note how the example has "opened" and "closed"
<karolherbst>
well
<karolherbst>
what I want to know is who assigned to marge
<ajax>
right
<ajax>
and the example makes it seem like "assigned" might be an event it remembers
<karolherbst>
mhhh
<MrCooper>
karolherbst: running marge-bot locally may work for adding tags, but not for the queue of MRs to merge?
soreau has quit [Ping timeout: 480 seconds]
<karolherbst>
MrCooper: sure it does
<ajax>
but the lists i'm getting back are of dimension one, and they're just "merged"
<ajax>
and i'm a gitlab supercow so
<karolherbst>
it does the same thing
<karolherbst>
it just doesn't wait for new things to happen
<karolherbst>
but you could restrict it to one MR if you really wanted to
<karolherbst>
we could even script away the assigning part
<karolherbst>
and then just "dim merge-mr 45" and it does all the magic
<MrCooper>
O-o how does it coordinate with other marge-bot instances running for other MRs?
<karolherbst>
MrCooper: ehhh.. mhh, true, I didn't think about that
<daniels>
how is that any different to just 'merge when pipeline succeeds'?
<karolherbst>
it would at least add all the tags and stuff
<karolherbst>
but yeah.. I guess we want this one bot who runs for all and just works
<MrCooper>
I guess for projects less busy than Mesa it's easy to forget that was the main motivation for using Marge :)
<karolherbst>
but that s-o-b tag issue is problematic
<karolherbst>
yeah...
<karolherbst>
it might be feasible
<karolherbst>
especially as we do want merges on the drm level
<karolherbst>
but having something adding all the tags and checking CI and everything is already a win
<karolherbst>
so worst case we only have that
<MrCooper>
CI needs to check the result of merging the MR, so there still needs to be a single queue of MRs
<karolherbst>
well it still would do that, just without queuing
<karolherbst>
so it fetches the list of assigned MRs
<karolherbst>
and processes through all of those
<karolherbst>
and then quits
<karolherbst>
as long as you don't have multiple people doing it at the same time, it would work out
<karolherbst>
well.. unless your post merging pipeline is any different
<karolherbst>
but anyway
<karolherbst>
if it's already merged..
<haasn>
is there any way to detect if the current framebuffer has an alpha channel, in OpenGL?
<emersion>
haasn: i use glGetRenderbufferParameteriv with GL_RENDERBUFFER_ALPHA_SIZE
<haasn>
oh right, I do that in my code as well it seems
<danvet>
karolherbst, there's some other controls to only allow non-linear merges for maintainers
<danvet>
iirc
<danvet>
so that's covered
<danvet>
or limiting pushes to branches to maintainers, and then just make marge one too
<karolherbst>
right
<karolherbst>
but "developers" can assign to marge
<karolherbst>
even for branches only for maintainers
<karolherbst>
marge-bot doesn't check any of that at all
<danvet>
karolherbst, yeah but that's fine imo
<danvet>
gitlab developers = git committers with dim
<karolherbst>
yeah
<danvet>
I thought you can create an MR without anything?
<karolherbst>
yeah, everybody can create MRs
<danvet>
there's also the intermediate level that allows you to changes tags and stuff
<karolherbst>
I am more thinking about issue handling
<danvet>
and wrestle issues
<danvet>
so that's what everyone would get who asks
fxkamd has quit []
<karolherbst>
there is "reporter"
<karolherbst>
not quite sure what those can do
<danvet>
and the developers thing is the "show so merged patches pls"
<daniels>
ajax: btw, you can get the MR notes, filter on note.system == true, then look at the body for assigning
<daniels>
it's kind of lame, but eh
<karolherbst>
daniels: reporters can't edit the wiki
<karolherbst>
only developers can
<karolherbst>
or edit milestones
<karolherbst>
so you have to hot your wiki somewhere else I guess
<karolherbst>
*host
<karolherbst>
another project or...
<daniels>
the wiki sucks anyway, just use Pages
<daniels>
I mean there's nothing stopping marge from filtering on an allowlisted set of approvals if you use the approve button
<karolherbst>
daniels: well.. then only develoeprs can push to the Pages branch
<karolherbst>
but yeah.. we can hack up marge enough to do what we want it to do anyway
<karolherbst>
I hope at least
<karolherbst>
ajax: that state event API wouldn't be so bad if you could filter it...
<karolherbst>
and sort it
<MrCooper>
karolherbst: for a busy project, the main point of using Marge is not to waste resources due to trying to merge multiple MRs at the same time
<karolherbst>
yeah
<karolherbst>
but I don't know if drm-misc is already busy enough
<karolherbst>
or intel or amds trees or if they want to use something else anyway
<daniels>
ajax: filter() and sort() do exist :P
<daniels>
s/ajax/karolherbst/
<karolherbst>
yeah... I guess I'll do it in python then :P
<karolherbst>
anyway.. away for a bit
ezequielg_ has quit []
ezequielg has joined #dri-devel
<MrCooper>
karolherbst: also, if real merges are allowed, merging multiple MRs at the same time may actually work, but possibly invalidate all CI pipelines but that of the MR which makes it over the line first
<karolherbst>
MrCooper: I think for drm we want real merges when merging the other trees in and in the "driver" trees we might want to go linear...
<daniels>
>>> assign = filter(lambda x: x.system and x.body.startswith("assigned to "), mr.notes.list())
<daniels>
>>> mesa = gl.projects.get("mesa/mesa")
<daniels>
>>> mr = mesa.mergerequests.get(12345)
<daniels>
['assigned to @marge-bot and unassigned @thomas.wagner', 'assigned to @thomas.wagner and unassigned @marge-bot']
<daniels>
>>> print([a.body for a in assign])
<karolherbst>
nice
<karolherbst>
will look into it in a bit, have to do other stuff :D
shashank1202 has joined #dri-devel
<daniels>
er, last line should be print([f"{a.author['username']} - {a.body}" for a in assign])
<daniels>
but you get the picture
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
<haasn>
emersion: hmm doesn't work for me, always returns 8 for the default framebuffer evne though I absolutely do _not_ have support for alpha transparency
<haasn>
seems like the framebuffer is rgba8 (visual 0x21)
<haasn>
but I guess that's on glfw for picking that visual when visuals without alpha are available
<haasn>
SDL gets it right
JohnnyonFlame has joined #dri-devel
<haasn>
and by "gets it right" I mean "always picks that even when I would have wanted a visual with alpha"
<haasn>
I guess the bottom line is, screw opengl, I don't care if windows are transparent or not
<haasn>
people should use vulkan if they want things to work
nchery has joined #dri-devel
dongwonk has joined #dri-devel
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
elongbug has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
Daaanct12 is now known as Danct12
Daanct12 has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
achrisan has joined #dri-devel
<karolherbst>
daniels: sadly marge-bot uses the HTTP endoints directly
<karolherbst>
but if "notes" is the correct term here
<karolherbst>
just didn't know it's part of the notes
<karolherbst>
currently writing the code to dump the data
<karolherbst>
mhhh
<karolherbst>
having to parse the string feels wrong though :D
ybogdano has joined #dri-devel
<daniels>
yeah, it's not ideal
<Company>
there's not really a portable way to gete a GL context without a Display of sorts, right?
oneforall2 has joined #dri-devel
<Company>
I'm looking into GDK's GL testsuite code and wondering if I need a GdkDisplay
<karolherbst>
Company: SDL2 abstracts that away if you can use SDL2
<karolherbst>
kind of depends on what you want to do though
<Company>
nah, I'm working on the GTK testsuite, I'd rather use GTK
<karolherbst>
ahh
<Company>
I just want to make CI faster
<Company>
save the planet!
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
ds` has quit [Quit: ...]
ds` has joined #dri-devel
Daanct12 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
Daanct12 is now known as Danct12
heat has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<robclark>
Company: is egl+surfaceless an option?
<Company>
robclark: EGL kinda requires an EGLDisplay though
<Company>
I could try having code for GBM I guess, but not sure that's worth it
aravind has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<ajax>
Company: surfaceless means you can have an EGLDisplay without it connected to a wayland or x11 or... display server
sneil has quit [Ping timeout: 480 seconds]
<Company>
that might indeed be worth having in GTK for testing
shashank1202 has quit [Quit: Connection closed for inactivity]
<Company>
need to check if that works on Windows and MacOS first though
<karolherbst>
ajax: that resource event endpoint doesn't help at all :/ So it seems like the Notes is all we got
<jenatali>
Company: Surfaceless works with my new Windows EGL implementation in Mesa. Dunno if it'd work on AMD or Intel's proprietary EGL, and NV doesn't ship EGL on Windows
<Company>
I was thinking about WGL
<ajax>
if you're looking for something portable at that level just learn to render to a pbuffer instead of a window
<ajax>
windows and macos never lack for a display so "surfaceless" is sort of a no-op concept
<ajax>
but out here in the wild west, if you don't want to even need a running display server, surfaceless + egl (where you'd need to use a pbuffer anyway if you wanted to render to an EGL surface)
<ajax>
karolherbst: yeah, i suspect the documentation may show it running against a paid version of gitlab
<karolherbst>
ajax: I think that's not it
<karolherbst>
I think it only shows _state_ changes
<karolherbst>
so "merged" or "closed" or...
<ajax>
right but. "opened" not being there in our output, but being there in the docs, suggests the state changes may be more numerous than we think
<karolherbst>
I think you see those for reopened ones
<ajax>
regardless: useless
<ajax>
for our purposes anyway
<karolherbst>
yep
<karolherbst>
I just use the notes and maybe we can convince gitlab to change stuff.. dunno
<ajax>
can we get the list of approvers or up-thumbers?
<karolherbst>
yes
<ajax>
marge could look at those and refuse to merge something that a Maintainer hadn't acked that way
<karolherbst>
sooo
<ajax>
and could add s-o-b for if they had
<karolherbst>
the problem is.. once you repush, those get removed
<karolherbst>
soo marge needs admin rights to reset the approves
<karolherbst>
it's used for Acked-by tags added via marge
<karolherbst>
The issue is though, we still have this formal s-o-b tag requierement and what do you do if multiple maintainers ack
<karolherbst>
just add all and use acked-by for everybody else?
<ajax>
what removes them i wonder, and can we throw marge a message before that happens
<ajax>
can multiple people not s-o-b?
<karolherbst>
I actually think it's a setting
<ajax>
i was thinking (for nouveau tree at least) that marge would turn maintainer Approve into s-o-b and developer into r-b and anyone else into ack
<ajax>
something like that anyway
<ajax>
unless developer was also patch author, i suppose
<karolherbst>
yeah.. maybe
<karolherbst>
but I suspect maintainers also want to add r-by tags if there is nobody else reviewing those
<karolherbst>
s-o-b doesn't imply reviewing patches, does it?
<ajax>
i think strictly it means "i assert that this is legally contributed" but if it didn't also socially mean "i think this is good and worth doing" it'd be a little weird
<ajax>
*shrug*
<karolherbst>
well maintainer can't review all patches
<karolherbst>
I don't think airlied or danvet are doing that :P
<ajax>
mozilla called this super-review i think
<karolherbst>
yeah.. but I still don't think it qualifies as a proper review
<ajax>
sure
<ajax>
just thinking out loud here
<sravn>
karolherbst: I for one review most of what I apply, but never put a r-b tag on the patches. For trivial stuff I just do dim apply in mutt and done. Adding r-b would be an extra step
<karolherbst>
the issue is also.. how much is upstream willing to trust that system if we can get s-o-b tags of people on commits they approved 6 months ago, but the patches went through 20 iterations
<sravn>
But then there is no way to tell what is applied with what I consider a proper review and what is just applied
<karolherbst>
after they approved it
<sravn>
All this is in kernel land obviously
<ajax>
karolherbst: upstream hides that trust behind the noise of mailing lists tbf
<karolherbst>
that's not my point
<karolherbst>
you still download the patches and apply them
<karolherbst>
and then you add your s-o-b tag
<karolherbst>
so you kind of know what you s-o-b
<sravn>
Yeah, thats correct.
Ahuj has joined #dri-devel
<karolherbst>
hence my idea was to figure out who assigned to marge and add a tag for that account, because that kind of expresses intention and we are sure the person looked/accepted the last version
<karolherbst>
*at
<danvet>
karolherbst, it's kinda messy
<danvet>
in most kernel subsystems where you have the traditional "maintainer applies everything" the sob implies review
<karolherbst>
yeah sure
<karolherbst>
but that wouldn't work for us
<danvet>
but also, when you do have some real other review going, then maybe the sob only implies the legal part
<danvet>
but we also try to not do that by just giving all the regulars commit rights
<karolherbst>
well for nouveau it might be fine this way
<karolherbst>
but drm in general?
<danvet>
the other part is the maintainer oversight review as part of pull requests
pekkari has joined #dri-devel
<karolherbst>
yes
<danvet>
which really is "I'm happy to take the blame for this if someone throws a fit and rages for no good reasons"
<karolherbst>
I see this s-o-b tag more as a "I certify that everything is in order here"
<danvet>
which unfortunately is still a thing
<danvet>
yeah pretty much
<karolherbst>
and you have a trust chain of such people
<karolherbst>
so..
<karolherbst>
if the maintainer also reviews, that good and I think it's also important to point that out
<karolherbst>
but adding review tags in gitlab is already this kind of painful thing
<karolherbst>
If we are fine with repinging people to push "approve" after force pushing I think this could work automatically... just marge removes those tags when added manually
<karolherbst>
and it totally doens't work for changes across drivers
<karolherbst>
I mean.. I can come up with something which works for nouveau easily, but I am also trying to keep drm as a whole in mind
<karolherbst>
maybe we need two marge bots
<karolherbst>
one for simple cases, where we just pick it from the approval lists
<karolherbst>
and the other one not touching those tags
cafuffu has quit [Remote host closed the connection]
carbonfiber has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<carbonfiber>
If I use a backported kernel in order to get hardware support for some newer gpu, then will graphics work even if mesa (or xorg drivers) are not backported aswell? or do they also need to be backported as well?
<karolherbst>
depends on what you mena by graphics
<karolherbst>
*mean
<karolherbst>
OpenGL/Vulkan? No
<karolherbst>
general displaying support? yes
<carbonfiber>
I mean just a standard desktop like gnome or kde.
iive has joined #dri-devel
<carbonfiber>
don't know which of the options you listed that fits into.
<karolherbst>
well.. it should work, but you won't get 2D acceleration
<karolherbst>
so everything might just be a bit slow
<karolherbst>
for 2D acceleration it depends a little on the dirver used though. So if you use the modesetting DDX you need to backport changes to mesa as well. _sometimes_ mesa can also provide acceleration without needing changes, but generally it needs to
<karolherbst>
if you use some native DDX then you have to backport changes to that DDX in order to get acceleration
<karolherbst>
but then it's just for X and you are still left without GL/VK
<carbonfiber>
hmm. I don't know much about this stuff, so some of what you have written is a bit over my head. The reason I am asking is that I am trying to figure out the viability of using debian on new hardware (therefore using a backported kernel) with everything working normally using a normal desktop environment. Or whether the only actually viable distro is a distro with more frequent release cycle such as fedora or ubuntu, if i
<carbonfiber>
want to use new hardware with graphics working normally.
<karolherbst>
carbonfiber: I'll give you a well meant advice: don't use debian
<karolherbst>
it's not worth the pain
pekkari has quit [Quit: Konversation terminated!]
<karolherbst>
if you want to have a normal desktop experience you will end up having to install newes mesa/kernel anyway
anarsoul|2 has quit []
<karolherbst>
and backporting to older branches might be not worth it due to many conflicts
<carbonfiber>
anything in particular with regards to graphics or desktop usage that makes it a pain?
anarsoul has joined #dri-devel
<karolherbst>
old software
<karolherbst>
we use debian for CI though, but we also compile most of the stuff ourselves then anyway
<karolherbst>
and the kernel side is also out of scope as it's just containers
pekkari has joined #dri-devel
<karolherbst>
I think the main reason we use debian is, that multi arch isn't a complete pain there
lalalulu has joined #dri-devel
<karolherbst>
in the end it's up to you to decide if you want to deal with this or not
<carbonfiber>
if I don't care about old software. Do you know if backported mesa in general works well? And is it widely used? Or would I find myself running into crashes and stuff because no one else uses it?
<karolherbst>
at least for ubuntu there are PPAs installing mesa compiled from main
<karolherbst>
carbonfiber: I don't know of anybody who actually maintains their own mesa downstream
<karolherbst>
so I couldn't say
<karolherbst>
mesa main is quite stable though
<karolherbst>
so I don't see the point of backports really
<karolherbst>
somebody has to invest in testing one way or the other anyway
<carbonfiber>
I wouldn't try to compile and backport it myself.
<karolherbst>
carbonfiber: that's just using a mesa version from a newer debian release in an older one
<karolherbst>
right?
<carbonfiber>
I think so.
<karolherbst>
yeah well.. that's fine I guess
<karolherbst>
just need to have updated deps as well
eric_engestrom_ has quit []
<karolherbst>
like libdrm
<karolherbst>
or the vulkan loader
<karolherbst>
etc...
<carbonfiber>
hmm ok.
eric_engestrom has joined #dri-devel
<karolherbst>
if somebody does the work for you, then I think it's feasible
<karolherbst>
as I said.. for ubuntu there are PPAs for that
<carbonfiber>
ok
<karolherbst>
I just don't see the point of going into all those troubles yourself, if you can just use the latest debian or debian sid instead
<karolherbst>
I am mainly saying that because those PPAs have double digit amount of packages
Bhawan has joined #dri-devel
<karolherbst>
carbonfiber: ahh.. and llvm
<karolherbst>
you need newer llvm with newer AMD devices because compiler support
<karolherbst>
so this can be super painful
<carbonfiber>
Yeah, the reason I am asking is because I am trying to decide what distro to stick to. And the viability of being able to run that distro on newer hardware (when the time come where I need to replace my current hardware) influences that decision. For example, what if I need to replace my computer 2 years into the latest debian release.
boistordu has joined #dri-devel
<karolherbst>
so from my experience dealing with bugs is, that debian users coming into IRC and complaining about bugs fixed already is a thing
<karolherbst>
and then they fix it by using a newer kernel
<karolherbst>
or mesa
<karolherbst>
but we also make it quite annoying for debian, because we are moving super fast
mbrost has joined #dri-devel
<karolherbst>
and we often forget to care about backporting to our stable branches, just because of that throughput
<carbonfiber>
ok. Thanks a lot for the help :)
lalalulu has quit [Ping timeout: 480 seconds]
gpuman_ has joined #dri-devel
gpuman has quit [Read error: Connection reset by peer]
dviola has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
lemonzest has quit [Quit: WeeChat 3.2]
gpuman has joined #dri-devel
gpuman_ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: Quitting]
pekkari has quit [Quit: Konversation terminated!]
gawin has joined #dri-devel
soreau has joined #dri-devel
Bhawan has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Quit: Quit]
Bhawan has joined #dri-devel
gpuman_ has joined #dri-devel
gpuman has quit [Read error: Connection reset by peer]
<anholt>
I also saw a failure on one of them today that looked similar to the tftpboot issue I ran into with hitting dnsmasq's bad max-connections limit handling.
gpuman_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<emersion>
hm is there a way to turn off implicit sync in EGL?
gpuman has quit [Ping timeout: 480 seconds]
<daniels>
anholt: yeah, tomeu was looking into why that was going on - one of the dispatchers fell into a hole - it's descended into someone who actually knows databases yelling sadly at postgres
<anholt>
sounds like a bad time
Bhawan has quit []
gouchi has quit [Remote host closed the connection]
heat has quit [Ping timeout: 480 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]
danvet has quit [Ping timeout: 480 seconds]
<zmike>
eric_engestrom: it looks like !13429 didn't make it into rc2...did I just not put it up in time or did I mess up the MR
<zmike>
tomeu: ping re: #5440, this is breaking lavapipe
<robclark>
karolherbst: any idea why vload_global ends up using load/store_scratch? (asking for andrey-konovalov who is trying to get clover going on a5xx, where scratch memory isn't implemented yet)
<karolherbst>
robclark: I think it's the code in the test
<karolherbst>
some of those tests are using CL local memory
andrey-konovalov has joined #dri-devel
<karolherbst>
it might be other tests, but I think I saw something similar at some point as well and this was my conclusion
<jenatali>
robclark: there's a pass to convert function_temp to scratch, which is (mostly) necessary because you can take the address of function_temp and do all kinds of pointer fun with it
<robclark>
*ahh*
<karolherbst>
I think we mess up here though
<karolherbst>
the kernel shouldn't lead to scratch space being used
<jenatali>
Why not? There's a private var that you load into
<robclark>
ideally we wouldn't be doing that if no fun pointer math required.. since scratch just turns out to be system memory (ie. slow)
<karolherbst>
doesn't matter
<karolherbst>
those just end up as register accesses
<karolherbst>
or should at least
<robclark>
right
<jenatali>
You can try to be smart and optimize the loads/stores from that private mem I guess
<jenatali>
But you need to have scratch as a fallback I think for complex accesses
<karolherbst>
you don't have private memory in this case afaik unless the spirv translator is doing crazy stuff
<jenatali>
karolherbst: vload is in vtn, not the translator
<karolherbst>
vload would store in a normal spir-v ssa value
<karolherbst>
ehh
<karolherbst>
mhh
<karolherbst>
right...
<karolherbst>
ohh wait
<jenatali>
Er, I guess I meant not libclc
<karolherbst>
there was something stupid about it I think
<karolherbst>
robclark: anyway.. you need to support scratch memory sooner or later
<karolherbst>
but I guess nothing of what we do is optimized yet
<eric_engestrom>
zmike: if you want backports to be automatically suggested to maintainers, you'll want to add `cc: mesa-stable` (or `fixes: $sha1` if you're fixing a specific commit) to the commit messages (see https://docs.mesa3d.org/submittingpatches#the-stable-tag)
<zmike>
eric_engestrom: yeah, I missed them on that series though
<eric_engestrom>
I'll cherry-pick them (I assume you want the entire MR?) so you don't need to do anything else for this time :)
<zmike>
yeah, I want the whole MR
<zmike>
wasn't sure if I could just cc you on the original or whatever so I made that one
<zmike>
thanks!
sneil has joined #dri-devel
<eric_engestrom>
oh I missed that this was a backport MR; yeah you did it right, although I'll probably cherry-pick them so that the information that the commit was backported is automatically handled (easier for us that way)
<eric_engestrom>
but yeah, cc'ing me is never a bad idea, I sometimes forget to look somewhere and miss things :)
<robclark>
karolherbst: yeah, we need scratch for spilling.. and I suppose "fun pointer math"
<zmike>
okay, good to know
ybogdano has quit [Ping timeout: 480 seconds]
gpuman_ has quit [Remote host closed the connection]
gpuman has joined #dri-devel
<karolherbst>
robclark: can you access registers indirectly?
<robclark>
yup
<karolherbst>
ahh.. lucky you
ybogdano has joined #dri-devel
camus1 has joined #dri-devel
alyssa has joined #dri-devel
<anholt>
anyone know why vulkan specified YUV conversions to take Y from the g channel?
<alyssa>
cmarcelo: aside from less link time, what are the benefits of gtest'ifying?
<alyssa>
to be clear - I'm not at all opposed. Just want to know if it's worth learning gtest and converting the panfrost tests.
<alyssa>
(right now the unit tests are stupid-simple home rolled asserts.)
anholt has quit [Quit: Leaving]
anholt has joined #dri-devel
<karolherbst>
alyssa: test frameworks usually help by providng nice helper functions for literaly everything you need
<alyssa>
what.. would I need..?
<karolherbst>
like assert that certain lists/arrays/whatever are equal
<karolherbst>
and then they pretty print stuff
<anholt>
the fact that it prints the two sides of an EXPECT_EQ is a little nice.
<anholt>
also being able to define test functions without having to remember to call them from main and aggregate results
<karolherbst>
nothing of that is really like.. super important, but it makes it way nicier to write tests
<karolherbst>
ahh yeah
<anholt>
but that's about all the nice I have to say about gtest.
<alyssa>
though i'm not sure how much of that would get removed if moved to gtest? certainly the main assert but most of that is pretty bifrost specific
<karolherbst>
yeah.. I was more talking about it in a general sense
camus has quit [Ping timeout: 480 seconds]
<karolherbst>
like test frameworks in general add all those kind of features
<anholt>
airlied: ah, ok.
<anholt>
I suppose if you give them better names then it makes sense
<alyssa>
I suppose I'm mostly scared of touching .cpp files :-p
<alyssa>
it's bad enough that i have to write java code for school.
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
<cmarcelo>
alyssa: the folks already replied most of the reasons. going gtest also helps a little bit the "one binary per module" front because it already has the magic necessary so that you don't need to list your all your tests somewhere.
<cmarcelo>
alyssa: most of the time you can avoid the C++-isms when using gtests
<mattst88>
I consider some of the required C++ magic in gtests to be just that... magic. don't try to understand it
<cmarcelo>
mattst88: yeah :-/ was following the docs on this one, we can try to take the template out, but not sure if would work.
<cmarcelo>
mattst88: I wanted to make a single TEST() be replicated to the multiple gens, in a way that we can filter them per gen, etc. this is well-documented but a bit heavy on boilerplate.
<cmarcelo>
mattst88: that line you linked is eassentialy "this is the code you use to name those variants"
<mattst88>
bnieuwenhuizen: yeah, I guess, but you pass an object to some macro that instantiates a bunch of tests, parameterized on some other struct
<mattst88>
I mean, it's templatized C++ *and* crazy C preprocessor
<mattst88>
cmarcelo: yeah, I mean, I know /what/ it does -- I copied it from somewhere in order to make those tests run on each gen
<mattst88>
I just don't think I could explain how it works
<mattst88>
(and you definitely want to run the validator test for each gen)
<mattst88>
sorry, for each "gfx" :P
<cmarcelo>
we could definetly NOT use that mechanism of parameters and simply for-loop inside the test, but we lose a few things, like being able to individually filter yada yada.
<cmarcelo>
mattst88: just realized I've mixed eu_compact and eu_validate :-)