<tzimmermann>
that patch has a fixes tag. you can do 'git branch --contains d391c5827107' to see what tags contain the broken commit
<javierm>
tzimmermann: yes, I have and did: dim setup && dim update-branches && cat v3-fbdev-Prevent-probing-generic-drivers-if-a-FB-is-already-registered.patch | dim apply-branch drm-misc-fixes
slattann has joined #dri-devel
camus1 has joined #dri-devel
<javierm>
tzimmermann: that's why I asked. Because the offending commit landed in v5.15-rc1 and we are in v5.16-rc1 now
<javierm>
some subsystems only want during the -rc cycle fixes for regressions introduced during the merge window, but didn't know what's the policy for drm
<tzimmermann>
commit d391c5827107 is already in the upstream tree, so the fix should go into drm-misc-fixes
<tzimmermann>
you're right
<tzimmermann>
you can always merge into drm-misc-next. we, the maintainers, sort out the details when patches get forwarded
camus has quit [Ping timeout: 480 seconds]
<tzimmermann>
anything in drm-misc-next before -rc6 will go into the next release
<tzimmermann>
anything after will have to wait one release longer
<tzimmermann>
for important patches after -rc6, there's also drm-misc-next-fixes
<pq>
No wonder I never find DMA_BUF_IOCTL_SYNC, there is nothing about it in libdrm where my mind semantically groups it. :-p
<tzimmermann>
javierm, don't forget to add missing tags to your patch before pushing. there's a tested-by AFAICS
<javierm>
tzimmermann: thanks for the explanation. If the policy is to target the current -rc then I'll push to drm-misc-fixes
<javierm>
tzimmermann: yes, that's why I took the mbox instead of pushing what I already had in a local branch in my tree
sdutt has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, sounds good
<javierm>
tzimmermann: so just 'dim push-branch drm-misc-fixes' should do it right ?
<javierm>
sorry for asking so many questions but I prefer to ask than do it wrong the first time :)
<tzimmermann>
yes. you have to be on your local drm-misc-fixes branch
<tzimmermann>
maybe double check if there's only that one patch queued up.
<tzimmermann>
and then you're good to go
<tzimmermann>
javierm, don't worry. it can be intimidating first time. no one wants to mess up on their first merged patch
<tzimmermann>
if you ever mess up, ping danvet or airlied. i think they can reset the drm trees for you. it's accepted if it's only been a few minutes IIRC
pcercuei has joined #dri-devel
<javierm>
tzimmermann: Ok, thanks for all the info
nroberts has joined #dri-devel
calebccff_ has quit []
linearcannon has joined #dri-devel
rasterman has joined #dri-devel
Hi-Angel has joined #dri-devel
tursulin has joined #dri-devel
camus has joined #dri-devel
<MrCooper>
doras: AFAICT libgbm.so.1 is part of the base org.freedesktop.Platform flatpak extension, so all that really seems needed is to make sure that's new enough to support external GBM backends? Let nvidia deal with supporting multiple GBM backend ABIs
camus1 has quit [Ping timeout: 480 seconds]
lplc has left #dri-devel [#dri-devel]
lplc has joined #dri-devel
<dj-death>
we would like to enable our intel_clc (!13171) tool on CI and that requires llvm
<dj-death>
what's the policy about that in the CI scripts?
<dj-death>
looks like the debian-release pipeline explicitly disables llvm
<MrCooper>
many other jobs enable it
<MrCooper>
e.g. fedora-release
<dj-death>
MrCooper: thanks, so I guess it shouldn't be a problem to add it for debian
<MrCooper>
not quite what I meant :)
<MrCooper>
does it have to be this particular job?
<dj-death>
ah
<dj-death>
so because that intel_clc tool will be used for by anv, we'll need llvm as a dependency (only at build time though, the tool is an offline compiler)
<dj-death>
but yeah, I just noticed that debian-release doesn't enable anv
<dj-death>
so I'm not quite sure what the logic is there...
<MrCooper>
maybe it could be enabled now, see 373e25e6b53338c6fa6c5757a878e10398241c47 commit log
<dj-death>
it's even more confusing :)
gawin has joined #dri-devel
<dj-death>
fedora doesn't care about -Werror but debian does?
<MrCooper>
all build jobs enable -Werror now
<MrCooper>
some of them still need to ignore some warnings though
<dj-death>
okay
<dj-death>
I'll limit that tool to builds with anv for now
<MrCooper>
there's a chance enabling ANV in debian-release just works now
ppascher has quit [Quit: Gateway shutdown]
Hi-Angel has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
camus1 has joined #dri-devel
<bnieuwenhuizen>
dj-death: FWIW not all anv builds can have LLVM without a bunch of effort. Notably the Android build
camus has quit [Ping timeout: 480 seconds]
<dj-death>
bnieuwenhuizen: thanks, indeed it looks like :(
pnowack has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
rib_ has quit [Read error: Connection reset by peer]
rib_ has joined #dri-devel
lileo__ has quit [Ping timeout: 480 seconds]
tchar has quit [Ping timeout: 480 seconds]
dianders has quit [Ping timeout: 480 seconds]
lileo__ has joined #dri-devel
zmike has quit [Ping timeout: 480 seconds]
tchar has joined #dri-devel
dianders has joined #dri-devel
zmike has joined #dri-devel
tchar has quit [Read error: Connection reset by peer]
tchar has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
jkrzyszt has joined #dri-devel
mclasen has joined #dri-devel
<dj-death>
other question, if I change the package installed in the ci container script
<dj-death>
is there something to do so that the PR pipeline actually runs that script?
<dj-death>
it seems it fetched a cached version of the container image
<daniels>
dj-death: bump the IMAGE_TAG variable
<dj-death>
daniels: thanks
<daniels>
np :)
mclasen has quit []
mclasen has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<dj-death>
daniels: like for debian-i386, that would be bumping "MESA_IMAGE_TAG: *debian-i386_build" ?
<dj-death>
or maybe MESA_IMAGE_TAG: &debian-i386_build "2021-07-02-bump-libdrm"
<daniels>
right
<daniels>
so you make the latter "2021-11-17-add-llvm" or whatever
<dj-death>
is that yaml file using a pointer kind of concept? with & * ?
<daniels>
correct :)
<dj-death>
that is mad. :)
<daniels>
& declares a ref to its block, * inlines it
<MrCooper>
they're called anchors in YAML
X-Scale has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
[X-Scale] has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
X-Scale has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<dj-death>
dammit
camus has joined #dri-devel
<dj-death>
spirv-tool:i386 is not installable with spirv-tool:amd64
mclasen has quit []
mclasen has joined #dri-devel
<dj-death>
and removing the amd64 version also removes glslang which we probably need for another thing
nchery has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
mclasen has left #dri-devel [#dri-devel]
mclasen has joined #dri-devel
itoral_ has quit []
vivijim has joined #dri-devel
iive has joined #dri-devel
<dj-death>
ah another interesting issue
<dj-death>
debian stable doesn't have the libclc package we need
aravind has joined #dri-devel
<daniels>
it's just the two spv bits we need, so we could pull those from elsewhere
<dj-death>
I actually need the real lib
<dj-death>
coming with llvm-12+ only it seems
<dj-death>
I think I'll try to build my own libclc
<dj-death>
jenatali: you're building the whole llvm with it?
khfeng has quit [Ping timeout: 480 seconds]
<jenatali>
It's Windows. Where else are you going to get .lib files to link against for LLVM?
<dj-death>
I'm pretty unfamiliar
<dj-death>
thing is, debian stable ships with llvm-11
<jenatali>
Getting prebuilt DLLs and EXEs on Windows is pretty easy, but static libraries are not portable between compiler toolchains and there's no good package manager story for Windows
<jenatali>
And LLVM doesn't build as DLLs on Windows :(
rgallaispou has left #dri-devel [#dri-devel]
<daniels>
dj-death: uh, what do you mean by 'the real lib'? libclc doesn't produce executables
[X-Scale] has quit [Ping timeout: 480 seconds]
<jenatali>
At least not ones that you'd use anyway
<dj-death>
ah damn, looks like I'm confusing clang & libclc
CME_ is now known as CME
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<dj-death>
hehe actually I can compile it on the host, copy the files
shashanks has joined #dri-devel
gouchi has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
karolherbst has quit [Remote host closed the connection]
<mareko>
ajax: any update on the xcb glx issue? can I just push the previous xlib version of the workaround?
sdutt has quit []
sdutt has joined #dri-devel
karolherbst has joined #dri-devel
gouchi has quit [Quit: Quitte]
tzimmermann has quit [Quit: Leaving]
gawin has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
mbrost has joined #dri-devel
ddevault has quit [Remote host closed the connection]
ddevault has joined #dri-devel
jani_ has joined #dri-devel
illwieckz has joined #dri-devel
jani has quit [Read error: Connection reset by peer]
mclasen has quit []
mclasen has joined #dri-devel
gawin has joined #dri-devel
calebccff has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
illwieckz has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
nroberts has quit [Ping timeout: 480 seconds]
illwieckz has quit [Read error: No route to host]
illwieckz has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
gouchi has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
imre has quit [Quit: leaving]
imre has joined #dri-devel
Walter has joined #dri-devel
Walter is now known as Guest6130
Guest6130 has quit [Remote host closed the connection]
Walter_ has joined #dri-devel
Walter_ has quit [Remote host closed the connection]
camus1 has joined #dri-devel
nchery has quit [Quit: Leaving]
camus has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
imirkin_ has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Company has quit [Read error: No route to host]
Company has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
fxkamd has quit []
mclasen has quit []
mclasen has joined #dri-devel
Walter_ has joined #dri-devel
ybogdano has joined #dri-devel
Company has quit [Quit: Leaving]
Company has joined #dri-devel
<Walter_>
Is there any header in /src/util that relates to the graphics devices that are connected? Similar to vkDevices or MTLDevice.h in the vulkan and Metal API respectively.
angular_mike_____ has joined #dri-devel
<ajax>
mareko: go ahead, i'm not going to have the bandwidth to care for a while. but if you could open an issue and assign it to me i'd appreciate it.
gawin has joined #dri-devel
Walter_ has quit [Remote host closed the connection]
mbrost has joined #dri-devel
Walter has joined #dri-devel
Walter has quit [Remote host closed the connection]
Walter_ has joined #dri-devel
mbrost has quit []
mbrost has joined #dri-devel
<Walter_>
Is there any header in the mesa src that relates to connected gpus(like vkDevicesFoo in vulkan) that can be used in a vulkan frontend?
<Walter_>
gallium frontend*
<airlied>
pipe_loader_ deals with enumerating devices
<apteryx>
it also wouldn't magically make nvidia driver users on foreign distribution work with Guix provided software (c.f.: https://github.com/NixOS/nixpkgs/issues/9415), so it seems like it'd provide little value to Guix users in exchange of new pain points.
<apteryx>
dcbaker: nix uses libglvnd; they have other problems ;-)
<apteryx>
but supporting 'nvidia' makes more sense there, since they probably offer 'nvidia' as a package (they carry proprietary software in their package collection)
<apteryx>
in guix every opengl application links to mesa's libGL.so, IIUC, which while breaking spectacularly with non-mesa driver users, doesn't suffer from ABI breakages between guix upgrades
<dcbaker>
apteryx: I use nixos and haven't run into any issues :)
<apteryx>
do you use nvidia or another non-mesa driver?
<dcbaker>
I use iris from mesa
<dcbaker>
the bigger concern for you is that I think the plan is eventually to drop the non-glvnd paths, since we're basically duplicating what they do and creating two layers of indirection
<apteryx>
OK. Perhaps that explains why.
<apteryx>
Oh! Good to know. I guess we'll see; probably workable by directly referring to things (via custom patching).
jkrzyszt has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
ppascher has quit [Ping timeout: 480 seconds]
illwieckz has quit [Remote host closed the connection]
camus has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
Wanderer has joined #dri-devel
Erandir has quit [Read error: Connection reset by peer]
camus1 has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
illwieckz has quit [Read error: No route to host]
illwieckz has joined #dri-devel
pcercuei has quit [Quit: dodo]
<jenatali>
Is there any difference between pipe_resource::nr_samples set to 0 vs 1?