Calandracas has quit [Remote host closed the connection]
krushia has quit [Ping timeout: 480 seconds]
bolson has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
bolson has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
heat has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
u-amarsh04 has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
warpme has joined #dri-devel
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
coldfeet has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
itoral has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
coldfeet has joined #dri-devel
jsa has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
tzimmermann has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
tristianc6704 has quit []
tristianc6704 has joined #dri-devel
co1umbarius has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Read error: Connection reset by peer]
co1umbarius has joined #dri-devel
yyds has quit []
sima has joined #dri-devel
yyds has joined #dri-devel
bolson has quit [Remote host closed the connection]
bolson has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
kxkamil2 has quit []
kts has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
kxkamil has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
kts has joined #dri-devel
blabberstone has joined #dri-devel
blabberstone has quit [Remote host closed the connection]
jsa has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
jsa has joined #dri-devel
fab has joined #dri-devel
ungeskriptet is now known as Guest4853
ungeskriptet has joined #dri-devel
<pq>
sima, I saw your F_ISDUP callout, but I don't think I have any recollection right now about where and why its used. daniels might recall something where we need to check if two fds are dups of each other?
<daniels>
not inside the compositor, no
ungeskriptet is now known as Guest4855
ungeskriptet has joined #dri-devel
<emersion>
we need for vulkan import
<emersion>
but i use a DRM FD, and compare GEM handlers
<emersion>
handles
<daniels>
yeah, nice
bolson has quit [Ping timeout: 480 seconds]
<daniels>
we don't need to dedup GEM handles because we hide behind GBM/EGL to do that for us and give the uniqueness guarantee
frankbinns1 is now known as frankbinns
<daniels>
if we were doing it directly, indeed we'd just use a hash table of GEM handles which is iirc what Mesa does
Guest4853 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
ungeskriptet is now known as Guest4858
<pq>
daniels, wasn't there some GBM thing where I complained that something should check for something... thing?
ungeskriptet has joined #dri-devel
<pq>
maybe you just fixed that already
<MrCooper>
pq: Mesa needs to know if two DRM fds passed in by the app reference the same file description, for correct tracking of GEM handles
<daniels>
depends on what 'that' was ...
<sima>
I thought there was a case where we needed to compare dma-buf fd for sameness and there was no drmfd around to do the import trick
<MrCooper>
doesn't ring a bell offhand
<emersion>
i think we always have a DRM FD…
<emersion>
would need to check mesa usage…
samuelig has quit [Quit: Bye!]
ungeskriptet is now known as Guest4859
ungeskriptet has joined #dri-devel
samuelig has joined #dri-devel
Guest4855 has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
<MrCooper>
emersion: incidentally, I just thought of the GEM handle comparison trick while taking a shower this morning :) out of curiosity, does wlroots also handle the case where the DRM file descriptions are separate, but the imported GEM handle matches the original one by coincidence?
<emersion>
hm, what do you mean?
Guest4858 has quit [Ping timeout: 480 seconds]
Guest4859 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest4863
<MrCooper>
even if the DRM file descriptions are separate, the GEM handle of the imported BO may have the same value as the original exported one by coincidence
ungeskriptet has joined #dri-devel
mvlad has joined #dri-devel
u-amarsh04 has quit []
amarsh04 has joined #dri-devel
<emersion>
for vulkan we want to know if DISJOINT imports are required or not
<emersion>
if two DMA-BUFs represent the same underlying memory, we don't need DSJOINT
<emersion>
importing the FDs as GEM handles and comparing these handles is enough for this use-case
<emersion>
you're saying that maybe the fiile descriptions are different, but the GEM handles are the same? can this really happen?
<emersion>
hm, i suppose mesa might be using kcmp for a different use-case then?
<emersion>
trying to figure out whether two DRM FDs are the same file description?
<emersion>
i haven't looked at mesa usage
amarsh04 has quit []
Guest4863 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
<pq>
emersion, I think the question is whether you always import on the same DRM device fd, or sometimes on different DRM open files?
<emersion>
I have multiple DRM FDs
u-amarsh04 has joined #dri-devel
<pq>
GEM handles are specific to an opened DRM device file, aren't they?
vliaskov has joined #dri-devel
<pq>
import buffer A on device 1, and buffer B on device 2, you might accidentally get the same number as a GEM handle I think
<emersion>
sure
<emersion>
for the equalty test, i use the same DRM FD of course
<MrCooper>
I was thinking Mesa could export a dma-buf from the reference DRM fd, import it into the comparison DRM fd, and compare the GEM handles; if they're different, it's definitely no the same DRM file description, otherwise would need to make sure they don't just have the same value by coincidence though
<sima>
emersion, isn't there an older kernel where this kinda fails because it's all the same anon inode underneath all the dma_buf files?
<emersion>
i think this would have bad side effects
<pq>
if a coincidence could happen, then it can lie both ways: false-match and false-different.
<sima>
yeah gem dma-buf fd2handle isn't guaranteed to be cheap
<emersion>
MrCooper: importing a DMA-BUF will keep a ref to the memory
kts has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
<emersion>
there's no atomic way to know if the import created a new GEM handle or not
<emersion>
so you can't close it either
<MrCooper>
I know, this would use a BO created for this purpose
<MrCooper>
pq: false-different can't happen, importing a dma-buf back into the exporting DRM file description results in the same GEM handle
<pq>
I guess I didn't understand what kind of algorithm you're describing. No worries.
<pq>
I didn't even understand if you wanted to compare buffers or devices.
<emersion>
why does mesa need to compare DRM FDs?
<MrCooper>
DRM file descriptions
<pq>
I assumed you wanted to compare buffers, because that's what has been talked about.
gio has joined #dri-devel
<MrCooper>
emersion: it can get multiple DRM fds from separate API calls, and needs to know if they reference the same DRM file description, for correct tracking of GEM handles
<sima>
emersion, just looked, before ed63bb1d1f846 your inode comparison trick doesn't work because all dma-buf share a singleton inode
<emersion>
if it's about GEM handle ref'counting, it would be much cleaner to have proper ref'counting in the kernel…
<sima>
that was v5.3
<emersion>
sima, is there a way to check?
<MrCooper>
pq: well the whole thing about comparing file descriptions started with the use case I'm talking about, some 4 years ago
<sima>
emersion, create two different buffers, export them, if they have matching inode number then it's the singleton
<emersion>
yeah not going to do that
<sima>
or just assume that you won't get bug reports from this old kernels
* emersion
shrugs
<MrCooper>
emersion: maybe, I hope your time machine is working ;)
<emersion>
i had no bug report about this yet
<pq>
MrCooper, my memory goes back about an hour or two. :-)
<emersion>
MrCooper: could be done with import flags or such
fab has quit [Ping timeout: 480 seconds]
<MrCooper>
you mean a flag which always creates a new GEM handle on import? I guess that could work
sukuna1 has quit [Ping timeout: 480 seconds]
<emersion>
or a flag that increments a counter
<MrCooper>
I see
<emersion>
always creating a new handle would be simpler, if it covers the use-cases
apinheiro has joined #dri-devel
<MrCooper>
I do suspect there might be use cases which need to know if it's the same underlying BO
<tomba>
Is it fine to push fixes to drm-misc-next-fixes, if the fixes are already on drm-misc-next?
f_ has joined #dri-devel
<sima>
tomba, needs a "cherry picked from $git_citation" line and a ping to drm-misc maintainers so they're aware because cherry picks tend to cause strange conflicts
<sima>
but otherwise fine
<sima>
mlankhorst, tzimmermann ^^
<tzimmermann>
tomba, please use 'dim cherry-pick'
<tzimmermann>
it's usually better to merge fixes into drm-misc-next-fixes or drm-misc-fixes first.
<tzimmermann>
we can than backmerge into drm-mics-next
<tzimmermann>
tomba, which commit needs to be cherry-picked?
<sima>
yeah cherry-picks should be only for misplaced patches, not the default approach
jkrzyszt has joined #dri-devel
<tomba>
tzimmermann: 87f36e03c0f1 and c72211751870. I pushed them to drm-misc-next before rc6, but I guess I was still late for the feature freeze.
terrifying31 has joined #dri-devel
terrifying31 has quit [Remote host closed the connection]
heat has joined #dri-devel
<tomba>
tzimmermann: do you mean that it's better to merge fixes to drm-misc-next-fixes even outside the feature freeze? or only when in feature freeze, or close to it?
<tzimmermann>
tomba, only when in feature freeze
<tzimmermann>
tomba, these commits would have deserved to Fixes tag
<tzimmermann>
tomba, shall i cherry-pick them into drm-misc-next-fixes. i'd add the Fixes tag then
<tzimmermann>
?
<tomba>
tzimmermann: uh that is true. I'm not sure how I missed the fixes tag...
<tzimmermann>
tomba, -rc6 is the last tag that still receives new features from drm
<tzimmermann>
any change must be drm-misc-next (or a similar per-driver tree) in the week before -rc6
<tzimmermann>
maybe wednesday at the latest
<tzimmermann>
PRs usually go out on thursdays and fridays. -rc6 happens on sunday
<tzimmermann>
it's much harder to pick the correct branch during the merge window. i still haven't fully figured that out
<tzimmermann>
i think drm-misc-next-fixes closes when the linux release happens
<tomba>
tzimmermann: ok. so me pushing fixes on Saturday, and rc6 tagged on Sunday, didn't quite fit in =). but is there a way for me to know, between -rc5 and -rc6, when should I push a fix drm-misc-next and when to drm-misc-next-fixes?
<tzimmermann>
before wednesdays, -misc-next is safe
<tzimmermann>
mondays after -rc6, it should be drm-misc-next-fixes
<tzimmermann>
for the time in between, it's probably best to not push fixes
jnoorman has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<tzimmermann>
dmr-misc-next might be done already, but drm-misc-next-fixes hasn't yet catched up
jnoorman has joined #dri-devel
<tomba>
would it be possible to communicate the phase with tags? say, "if branch X has tag Y, but Linus hasn't tagged the final release, it's feature freeze".
<tzimmermann>
no idea
<tzimmermann>
maybe dim could warn about that
<tzimmermann>
tomba, i've cherry-picked the commits
<DragoonAethis>
pq: No idea, but AFAIK fork spawns a single new child thread, and fork explicitly requires you to use async-signal-safe calls only in child processes from that point on: https://www.man7.org/linux/man-pages/man7/signal-safety.7.html
<pq>
exactly, so can they pull that off? :-)
<pq>
*so how can they
<pq>
things like malloc() and fwrite() are no-go there
<DragoonAethis>
Hmm, I can't say how web servers etc do it, but I worked on a project once that forked off into worker processes to handle incoming clients
<DragoonAethis>
And tbh things just worked, I didn't care much about signal safety and what not, but there was effectively no shared state between the controller/worker processes
<DragoonAethis>
It was a C++ project too
<pq>
libc probably has some mutexes inside, so if you manage to fork just at the time when any of those mutexes are locked...
<DragoonAethis>
It was doing the polling in the controller process and worker processes just got an exclusive handle to work with from that point on
<pq>
the thread that locked the mutex won't exist in the child, so nothing will release the mutex
<DragoonAethis>
Unless they do some cleanup in the fork wrapper as well
<DragoonAethis>
So that the child process automatically does some internal libc cleanup
<DragoonAethis>
Yeah it does that, for a few of these at least
<DragoonAethis>
Not all though
<pq>
if the clean-up was trust-worthy, then why the requirement for async-signal-safe...
<DragoonAethis>
Because libc is a bag of evil no-good APIs that can't be reasonably cleaned up, and somebody just needed to have a Exit Jail Free card in the docs so that proper cleanup did not have to be implemented?
<sima>
tomba, tzimmermann I wouldn't worry too much, since if something is misplaced we can fix it with a cherry-pick
<sima>
it's a few days out of 2.5 months after all
<pq>
or because different libc work differently here
<sima>
picking the right branch after freeze seems to be more tricky anyway
<robert_mader>
Company: writing again in IRC, not Matrix...: no, unfortunately not - but I got a RPi5 and soon a RK3588 which should allow me to test it in a while.
<robert_mader>
Or once the Gst vulkan decoders support dmabuf export
<robert_mader>
P.S.: love the image you choose in the issue :)
i-garrison has joined #dri-devel
<Company>
I just wanted to know how confident I should be in my code being correct
<Company>
so that I know how authoritative I want to come across when arguing with dj-death ;)
<robert_mader>
I mean - the fact that Intel is currently broken is evident by the big warning, no?
<Company>
yeah, that's not in question
sukuna has quit [Ping timeout: 480 seconds]
<Company>
the question is more if GTK is doing the right thing - say if a fix comes up that doesn't work with GTK - is that likely a bug in anv or in GTK
<Company>
and if GTK is only tested against radv, it might very well be a GTK bug
<Company>
that was the way I was thinking
kts has joined #dri-devel
<robert_mader>
Meh, unfortunately it won't be particularly easy to test on other platforms for now. I guess we can't count on panvk to support it, v3dv probably should but the HW decoder on the RPi5 is weird - Qualcomm might be the best bet for now. Assuming that lavapipe is out of question.
<Company>
lavapipe can't do dmabufs afaik
<Company>
software rendering not doing dmabufs was always one of my big complaints
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
<DemiMarie>
Is there a way to validate a dmabuf from a potentially malicious client, such that if it passes, it won't cause undefined behavior to use it?
<DemiMarie>
The use-case is virtualization without copying buffers back to the CPU.
<Company>
I would hope so, because that's how flatpak apps render.
<pq>
DemiMarie, I believe there should never be undefined or explosive behavior, it is up to the import API to ensure that.
<pq>
DemiMarie, if the dmabuf is a restricted buffer where a wrong access would cause a machine check fault and reboot or whatever, it is the kernel drivers' responsibility to make sure any attempt of such access is prevented before it can happen. IOW, fail the import.
<pq>
reality can be lacking and buggy, of course
<pq>
DemiMarie, I guess you'd want to have explicit fences, either straight from the client or extracted from dmabuf, so your own rendering won't be stalled.
<DemiMarie>
pq: what about shadow compressed state on Intel?
<pq>
I dunno, what about it?
<pq>
why would it be an exception?
<DemiMarie>
I recall some Vulkan API not doing proper validation and potentially causing GPU hangs.
<pq>
and you want to work around driver bugs in your userspace program?
<pq>
I feel like it should be easier to fix the driver and distribute that instead of coming up with a reliable out-of-driver check.
<Company>
you could also just not advertise the critical modifiers (or formats) across process boundaries
<Company>
that assumes you know which ones those are ofc
<Company>
but flatpak/compositor has that problem, kernel/anything has it, and browser web process/ui process does, too - so it's not just vms
<cwabbott>
but I have no idea if that's "proper" or not... is there a reason it hasn't been done already?
<ManMower>
my guess is that it was just forgotten :)
<ManMower>
though maybe it's problematic for multi-backend situations.
<cwabbott>
fwiw, on the hw I'm working on there's no GL except through zink
<ManMower>
the future is now
<cwabbott>
:)
<cwabbott>
so no graphics support at all except through dma-buf
<ManMower>
most of my rdp testing lately has been multi-backend, so the drm backend would've initted that for me and I'd not have seen that problem.
<cwabbott>
we've been using weston-rdp a lot recently because you really don't want to actually use a device like this as your daily driver, and display is often broken
<ManMower>
cwabbott: I think that new bit should just be in the switch statement later in that function undeer the WESTON_RENDERER_GL case
<cwabbott>
ManMower: is there a reason it's not that way in the drm backend?
<cwabbott>
it has a similar switch-case but calls linux_dmabuf_setup() later
<ManMower>
drm backend is a "primary backend" exclusively, so it should always be first to init and doesn't have to check
<ManMower>
is weston's multi-backend stuff useful to you at all? you can light up the drm output and have the rdp output show the same thing...
<cwabbott>
right now my only drm output is a phone display
<ManMower>
that is not my preferred way to look at the matrix.
<cwabbott>
I don't really want my desktop to have those dimensions...
<ManMower>
gotcha
<cwabbott>
in general weston-rdp headless is really useful for bringing up stuff when you don't have display working yet, or don't want to dedicate a monitor to the device
<cwabbott>
and of course for newer devices it's going to be more and more zink-only, at least at first
illwieckz_ has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
krushia has joined #dri-devel
illwieckz_ has quit []
illwieckz has joined #dri-devel
<vsyrjala>
agd5f: thanks. ok if i push that into drm-misc-next?
<mlankhorst>
Obviously appears to be a need for it
Haaninjo has joined #dri-devel
<agd5f>
mlankhorst, sure. Will take a look. Seems like every time we try and do this through, it gets shot down by the cgroups maintainers
kts has joined #dri-devel
kzd has joined #dri-devel
<MrCooper>
JoshuaAshton: in wsi_explicit_sync_free_levels[], what's the reason for preferring (WSI_ES_STATE_RELEASE_MATERIALIZED | WSI_ES_STATE_ACQUIRE_SIGNALLED) over (WSI_ES_STATE_RELEASE_MATERIALIZED | WSI_ES_STATE_RELEASE_SIGNALLED) ?
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
rz_ has quit [Remote host closed the connection]
rz has joined #dri-devel
davispuh has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
robert_mader has quit [Quit: Leaving.]
zackr has joined #dri-devel
kts has joined #dri-devel
f_ has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<penguin42>
is the fdo gitlab having a bad day ? I'm getting a 'Permission denied (publickey)' when it was working earlier
<penguin42>
oh yeh, I see someone saying it on list
simon-perretta-img has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
lemonzest has joined #dri-devel
bolson has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<zackr>
does anyone know if that's actual dma-buf/kms expected behavior? meaning grabbing a prime fd for the active framebuffer and writting to it is expected to update the screen without any explicit flips in there
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
heat is now known as Guest5003
Guest5003 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
imre has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<MrCooper>
DemiMarie: not realistically, we can't break backward compatibility with user space which depends on implicit sync
<DemiMarie>
MrCooper: will it ever be possible for userspace that _does_ support explicit sync to be able to use features like userspace fences that don’t have completion guarantees?
<emersion>
zackr: that's called front-buffer rendering
<emersion>
i'm not sure KMS drivers are required to support it
<emersion>
in particular, some KMS drivers might not realize that the buffer changed
<emersion>
(especially things like GUD)
<zackr>
emersion: yea, i'm not sure if that's the expected behavior. i can do dirty tracking for this stuff for vmwgfx but it's a pain so if that behavior is not expected i'd prefer to avoid it
<emersion>
by "dirty tracking", do you mean FB_DAMAGE_CLIPS and/or the dirtyfb ioctls?
<emersion>
or something else?
jeeeun84135190815 has joined #dri-devel
<emersion>
i would expect user-space doing front-buffer rendering to flip with the same FB after the buffer has be written to, personally
Kayden has quit [Quit: -> meeting]
simon-perretta-img has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
<zackr>
emersion: for vmwgfx "dirty tracking" is a combination of all that plus implicit magic to cover up for the fact that the gem buffer/dma-buf isn't really a gpu buffer but a shadowed copy that will have to be updated (readback if written to on the gpu, upload when changed on the cpu)
simon-perretta-img has joined #dri-devel
<zackr>
which is why front-buffer updates are a pain. we need to track the updates, then notice that the given buffer is actually a front-buffer then upload that immediately to be able to present it
<emersion>
do you somehow detect that someone did a SYNC_END IOCTL?
<emersion>
maybe sima knows what's expected here
<zackr>
well, tbh currently we're broken wrt to this (meaning prime and fb updates). for a similar behavior on coherent surfaces we just page-fault on maps, explicitly mark whatever was accessed as dirty internally and then we scan command buffers and if we see that something has been used and is dirty we update it
<zackr>
if we had more igt tests for dma-buf/kms/sync's that'd make it obvious. although not sure if we'd want igt to be the reference for expected behavior
<penguin42>
(the gitlab ssh seems to have woken up)
<daniels>
the prime user for frontbuffer rendering is xserver, though it's not (unless it's got weirder whilst I haven't been looking) mmaping a dmabuf to do that
simon-perretta-img has quit [Ping timeout: 480 seconds]
<zackr>
tbh, i'm fishing a little bit. i know the new kde/kwin is broken on vmwgfx and it's definitely dma-buf/prime related. i know that the DRIVER_ANY tests in kms pass on vmwgfx, so i'm just looking at driver specific tests to see if i can dig up something to test that doesn't involve debugging a whole desktop
<emersion>
daniels, dumb buffer mmap?
<emersion>
wth or without a flip after dirtying the mmap?
<emersion>
daniels, do drivers have a way to know when user-space has mutated the dumb buffer?
smpl has joined #dri-devel
f_ is now known as f_|afk
alanc has quit [Remote host closed the connection]
f_|afk is now known as f_
alanc has joined #dri-devel
ity has quit [Remote host closed the connection]
ity has joined #dri-devel
<daniels>
emersion: I can't remember if flipping is mandatoary or not tbh
<Company>
dj-death: you got the reproducing working for !11125 ?
kaiwenjon has joined #dri-devel
<Company>
DavidHeidelberg: your PASS => FAIL thing in !9989 is not related to F39=>F40 which had the change to qsort() behavior in libc?
jsa has joined #dri-devel
<jannau>
flipping is not mandatory and it doesn't happen with the modesetting driver. This breaks X applications on apple silicon since the display driver has not vsync interrupt. That results fast animations since everything relies on vsync sequences for timing
<emersion>
maybe we should have a CAP for this
<emersion>
or… just make user-space flip
<emersion>
jannau: does modesetting use dirtyfb oictls?
<emersion>
ioctls*
fab has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<DavidHeidelberg>
Company: wow. this. Could be the difference....
<Company>
yay?
<DavidHeidelberg>
now to find, when Debian did it
<DavidHeidelberg>
because it worked for me before, but then it stopped (and I'm using testing/unstable)
<DavidHeidelberg>
MesaCI is on Debian stable
<DavidHeidelberg>
and there it works
<Company>
what's Intel CI on?
<DavidHeidelberg>
Company: they use apt, but question is which ver
<jenatali>
Ugh, qsort has been a nightmare for Windows/MSVC too, causing all kinds of app compat bugs
<Company>
jenatali: you get partial credit for that anyway, because you told me about that change back when
<DavidHeidelberg>
SOMETHING has to be undefined or random enough, when it gets compiled in one set, it validate correctly, but fails when compiled with different options/libs/arch/whatever
<DavidHeidelberg>
From my examination, the "Expected" state seems to ignore this patch 100%. While the "Got:" part seems to be correct (at least regarding to EGL_CONFIG_SELECT_GROUP_EXT behaviour