ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<bluestang2006>
driver is built correctly, but vainfo doesn't work, nor does ffmpeg decode
<jenatali>
bluestang2006: I think you want to talk to Sil - probably best to follow up over email as I don't think he's on IRC
<bluestang2006>
ok, that works...thanks
<bluestang2006>
out of curiosity, any chance that Dozen gets WSL support soon?
<jenatali>
Working on it :)
<zmike>
dcbaker: in that case ping me again in 2 weeks :P
<bluestang2006>
awesome!
mhenning has joined #dri-devel
crabbedhaloablut has joined #dri-devel
loki_val has quit [Ping timeout: 480 seconds]
everfree_ has left #dri-devel [#dri-devel]
everfree has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
mclasen has joined #dri-devel
Thymo has joined #dri-devel
columbarius has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Thymo_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
icecream95 has joined #dri-devel
Daanct12 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
porter35 has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
maxzor_ has joined #dri-devel
maxzor has quit [Remote host closed the connection]
technopoirot has quit [Ping timeout: 480 seconds]
technopoirot has joined #dri-devel
Duke`` has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
<tango_>
my nerdbrain is still so stuck in D&D (even though I haven't played in ages) that it tries parsing d3d12 as a dice roll specificiation
mhenning has quit [Quit: mhenning]
srslypascal has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
srslypascal has joined #dri-devel
srslypascal has quit [Quit: Leaving]
lemonzest has joined #dri-devel
mszyprow has joined #dri-devel
technopoirot has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
srslypascal has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
loki_val has joined #dri-devel
mbrost has joined #dri-devel
Danct12 has joined #dri-devel
loki_val_ has joined #dri-devel
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit [Ping timeout: 480 seconds]
loki_val has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
jewins1 has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
Daanct12 has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
oneforall2 has joined #dri-devel
dos11 has quit []
dos1 has joined #dri-devel
thellstrom has joined #dri-devel
MajorBiscuit has joined #dri-devel
tzimmermann has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Danct12 has quit [Quit: Leaving]
ahajda has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
pixelcluster has joined #dri-devel
frieder has joined #dri-devel
danvet has joined #dri-devel
shankaru has joined #dri-devel
mvlad has joined #dri-devel
jewins1 has quit [Remote host closed the connection]
wvanhauwaert has joined #dri-devel
wv has joined #dri-devel
wv has quit []
wv has joined #dri-devel
<tzimmermann>
danvet, airlied, what's the official position on removing legacy DRM drivers?
kts has quit [Ping timeout: 480 seconds]
wv has quit []
mbrost has quit [Ping timeout: 480 seconds]
wvanhauwaert has quit [Ping timeout: 480 seconds]
sergi has joined #dri-devel
sergi has quit []
kts has joined #dri-devel
sergi has joined #dri-devel
<tzimmermann>
i'm asking because the openchrome PR intends to remove the legacy UMS driver entirely. i think we should either not do that, or remove all the legacy drivers entirely.
rasterman has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: is there a reason to not keep the legacy one under a different Kconfig symbol? I wonder if could be possible to add a drivers/staging/gpu/drm and move them there
<javierm>
tintou: similar to what the media subsystem do with drivers/staging/media. Although that would be tricky if are using DRM helpers...
<javierm>
tintou: sorry, I meant tzimmermann ^
<tzimmermann>
javierm, drm is not allowed in staging, but there's no technical reason no to keep the legacy drivers around.
<tzimmermann>
in the openchrome PR, everyone seems to agree to remove the old code even though the code doesn't have feature parity.
<tzimmermann>
i thought, i'd open a discussion about our position on these drivers
<tzimmermann>
OTOH, if we want to remove this code, we might want remove *all* leagcy drivers and clean up our source code
<tzimmermann>
it's all old PC hardware AFAICT. generic DRM drivers will work there
mceier is now known as Guest3804
mceier has joined #dri-devel
Guest3804 has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: absolutely agree with you on this fwiw
<javierm>
tzimmermann: why DRM is not allowed in driver/staging btw ?
<tzimmermann>
javierm, i don't know for sure, but i think it's because DRM moves so quickly. staging drivers would likely be perma-broken because DRM has changed
<javierm>
tzimmermann: I see. Makes sense
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
<airlied>
tzimmermann: yes I'd rather not burn down the current via stuff, I also don't really like the patch submission being one file per patch
<airlied>
but not sure how much I'm willing to push him to make it not insane
<tzimmermann>
airlied, me neither. i hope he adopts that patch i gave him.
<javierm>
tzimmermann: I'll propose an alternative in the ML
<tzimmermann>
javierm, please not a separate driver
porter35 has quit [Remote host closed the connection]
<tzimmermann>
because that's what we have with mga/mgag200 and it sucks as well
<pq>
zmike, a script? You mean 'git rebase -i --exec build-and-test-stuff.sh', right? :-)
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I was going to suggest a separate driver indeed :)
<javierm>
tzimmermann: but a drivers/gpu/drm/legacy directory
<javierm>
tzimmermann: and a Kconfig symbol to disable all legacy drivers, if distros disable it for a couple of releases and nobody cares, then could be dropped
<tzimmermann>
javierm, we already have CONFIG_DRM_LEGACY. per-driver configs can hook into that
<airlied>
I think a brand new driver is fine, gives distros the chance to make sure they have userspcae
<javierm>
tzimmermann: yes, I just noticed that
<airlied>
though I hope generic modesetting userspace works on it
<tzimmermann>
in mga/mga200 there's confusion about which driver supports wich HW and why some of the naming in mgag200 is awkwards. and there's lot's of duplicated register constants in several files AFAICT. i'd like to avoid that with via
<airlied>
well mgag200 and mga are very different things for different uses
<airlied>
this looks more like an either/or situations
<airlied>
you pick openchrome is you have the userspace bits to support it
<tzimmermann>
airlied, but the X11 mga driver has support for all those server chips. it's totally confusing TBH
<javierm>
tzimmermann, airlied: sent my proposal to the ML
<tzimmermann>
if the via KMS code ever reaches feature parity with legacy via, we want to remove the legacy code. it seems easier to do if everything is in the same place
<javierm>
tzimmermann: I think we can rename the Kconfig symbols for all legacy drivers to DRM_LEGACY_FOOBAR
<tzimmermann>
javierm, thanks
<javierm>
and have DRM_LEGACY default n
<tzimmermann>
isn't it?
<javierm>
tzimmermann: it is not currently, at least in current master. Let me checkout drm-misc-next
<javierm>
tzimmermann: no as well. I can post a patch
<tzimmermann>
ok
<javierm>
tzimmermann: going back to the topic, I think that having a drivers/gpu/drm/legacy with all drivers there make more sense. It would be kind of a staging directory
rasterman has joined #dri-devel
<airlied>
yeah esp to get dri1 ones in a corner
<javierm>
tzimmermann: ah, not having a default makes it n, I wonder why some symbols have 'default n' then
toolchains has joined #dri-devel
pcercuei has joined #dri-devel
<javierm>
tzimmermann: I actually thought about drivers/gpu/dri1 too but then thought that we would like consistency with DRIVER_LEGACY .driver_features flag
<javierm>
again no strong opinion on this though
<tzimmermann>
javierm, that's an internal flag. we can rename that too
toolchains has quit [Ping timeout: 480 seconds]
<tzimmermann>
there are other uses of legacy as well
<tzimmermann>
symbol names, etc
<tzimmermann>
and nouveau has 'legacy' code as well IIRC
toolchains has joined #dri-devel
<javierm>
tzimmermann: ah, I somewhat thought the caps were exposed to user-space. Great, we can change it then
<tzimmermann>
javierm, maybe it is. but the name itself is not in uapi/
<javierm>
tzimmermann: cool. I'll wait for others to comment then and can prepare RFC patches to continue the discussion
<javierm>
danvet, tzimmermann: another user-space that assumes DRI devices always start at card0
devilhorns has quit []
<emersion>
:/
<emersion>
libdrm exists for a reason…
devilhorns has joined #dri-devel
<tzimmermann>
oh
<javierm>
emersion: yeah...
<javierm>
tzimmermann: wonder if SDL is important enough to be considered a regression...
<karolherbst>
javierm: with all the games shipping SDL2?
<emersion>
SDL != SDL KMS backend
<javierm>
karolherbst: I believe they use the X11 backend and not KMS directly ?
<karolherbst>
mhhh
<karolherbst>
true....
<javierm>
karolherbst: or wayland but no KMS
<javierm>
probably this is more for embedded devices that don't want to have a compositor ?
<tzimmermann>
javierm, this is apparently the raw kms driver
<javierm>
tzimmermann: correct
<karolherbst>
but yeah.. in theory I'd count SDL to those projects you get all versions of in the wild
<karolherbst>
javierm: some weird kiosk embedded device might use it for... stuff...
<tzimmermann>
i'd wait for them to come to us...
<karolherbst>
yeah.. probably the right decision
<javierm>
tzimmermann: that's how I find it :)
<tzimmermann>
really?
<karolherbst>
:D
<tzimmermann>
if libdrm does handle this correctly, why don't they use it?
<javierm>
tzimmermann: that's exactly what I'm asking now. This wasn't reported by a fedora user but a colleague at RH
<karolherbst>
ahhh.. I might know from where this is comming from then :)
<javierm>
karolherbst :)
<tzimmermann>
ah, ok
<tzimmermann>
SDL also uses xlib and wayland with other backends. there's no reason to do drm by themselves
<karolherbst>
probably nobody ever thought of this or something
<javierm>
tzimmermann: yup, but as karolherbst mentioned there are some kiosk-ish / embedded devices use cases where you don't want to have an X11 server or Wayland compositor
<karolherbst>
javierm: ohh I think it wasn't arguing for removing that, but rather using libdrm than handrolling the code
<tzimmermann>
javierm, i meant that three's no excuse for not using the official libdrm
<javierm>
it seems Eric does have also a libdrm backend but it seems SDL works in places where libdrm doesn't?
<karolherbst>
I also used SDL2 once for displaying stuff without having X/wayland, so yeah..
<tzimmermann>
there are DRM-based systems where libdrm does not work? :/
<karolherbst>
maybe something broken with nvidia? Idk
<javierm>
tzimmermann: no sorry, I misunderstood his explanation. It does work but SDL handles format conversion already why for libdrm would need to pull another dep
<javierm>
*while
<javierm>
tzimmermann: anyways, I'll take this conversation internally since you seem to be right that depending on SDL kmsdrm seems more fragile
<javierm>
tzimmermann: but my point wasn't if this should be considered a bug in user-space or a regression in the kernel? SDL is much more popular that some random programs like it was reported last time
<javierm>
*my point was
shankaru has joined #dri-devel
<karolherbst>
I'd consider anything breaking SDL a regression though, because it's so widespread used for random stuff
<tzimmermann>
but the backend is fairly obscure
<karolherbst>
sure
<karolherbst>
but that's irrelevant for kernel regressions
<tzimmermann>
and should be patchable easily
<karolherbst>
and even more irrelevant if it comes to SDL
<karolherbst>
not everything will get updated SDL
<javierm>
karolherbst, tzimmermann: yeah, I'm torn on this tbh
<javierm>
karolherbst: but on the other hand, it's a bug to assume the device names to be deterministic
<karolherbst>
specifically games which shipped SDL binaries, even though in this case it doesn't matter, but regression SDL is a red flag on its own already
<javierm>
that's never the case really, unless you have some udev rules
<tzimmermann>
but we've had this discussion before. they open the wrong file you cannot expect this to work
<karolherbst>
javierm: sure, but still irrelevant for kernel regressions
<karolherbst>
if it breaks userspace, it's a kernel bug
<karolherbst>
end of story
<karolherbst>
userspace relies on "bugs", so that's how we need to handle it then
<javierm>
karolherbst: unsure that I agree. If a user-space assumes your first partition is sda1 and then due some driver probing or whatever becomes sdb1
<javierm>
would that be a regression ?
<karolherbst>
javierm: there is nothing to disagree on because that's the rule of kernel devel
<tzimmermann>
and we have more and more drivers which move towards hotunplugging. this just magnified the problem
<karolherbst>
if a kernel change breaks userspace, it's a kernel bug
<karolherbst>
never userspace
<javierm>
karolherbst: the rule is to not break the contract with user-space. A deterministic device naming was never part of it IMO
<karolherbst>
nope
<karolherbst>
that's just not true
<karolherbst>
it's irrelevant what the contract was
<tzimmermann>
karolherbst, i disagree with your assesment
<tzimmermann>
device names are not predictable
<karolherbst>
I am not arguing about this point
<karolherbst>
but if it was for years and everybody could rely on it, even though nobody wrote it down as a rule
<karolherbst>
it's a de facto rule
<tzimmermann>
as i said, we have drivers moving towards hotplugging and following your argument would break all this
<karolherbst>
and if it changes and breaks random stuff, it's a kernel regression
<karolherbst>
what's documented and what not is simply irrelevant
<karolherbst>
tzimmermann: yeah... it's an annoying situation as we don't really support hotplugging GPUs atm
<javierm>
karolherbst: by taking your logic to the extreme, we couldn't change a kernel log printout or the kernel version
<tzimmermann>
usb drivers tend to disagree
<javierm>
since there may be user-space out there relying on it
<karolherbst>
javierm: if nobody complains there is no bug
<tzimmermann>
devices come and go. neither kernel nor userspace have any influence on that
<javierm>
karolherbst: but if someone complains then we stop exposing the kernel version in /proc/version ?
<javierm>
tzimmermann: exactly, the kernel just reports uevents and user-space does whatever they please
<javierm>
karolherbst: they can write a udev rule to always create a card0, or rename it
<karolherbst>
javierm: yeah, stopping to expose /proc/version would be a regression
<karolherbst>
or exposing the kernel version there
<karolherbst>
uhm.. stop exposing
<karolherbst>
well.. if it does break stuff
Akari has joined #dri-devel
<javierm>
karolherbst: that's not what I say. I meant user-space assuming that doesn't change
<karolherbst>
well
<karolherbst>
that's the deal with userspace and the kernel
<karolherbst>
we try our best not to break anything, and unless there is a very very very strong reason to break it, we don't
<karolherbst>
no matter what it is
<tzimmermann>
/proc/version is a different story entirely
<javierm>
tzimmermann: yes, I was just taking the logic to the extreme. My point was that we can't control if user-space make assumptions that are not true
<javierm>
like expecting a deterministic device naming
<karolherbst>
yeah, and because we can't control it, we don't regress it
<karolherbst>
but yeah.. device naming is annoying
<karolherbst>
I'd say if it's already broken and not caused by a kernel change, then it's not a kernel bug
<karolherbst>
I suspect if you remove the card0 device on any kernel version and are left with just card1, then it's not a regression, because the bug was always there
<emersion>
you can already break it by unloading/reloading drivers
<javierm>
karolherbst: well... it would break already if you do modprobe foodrm; modprobe bardrm; rmmod foodrm
fxkamd has joined #dri-devel
<javierm>
emersion: exactly
<karolherbst>
javierm: yeah, and then it's not a regression
<javierm>
karolherbst: fair
<karolherbst>
or kind of in the grey area, as there is an existing userspace bug affected by the same code
<tzimmermann>
karolherbst, the code in question only counts the number of dev files. if you plugin 3 cards, and then unplug the middle one, it would already fail
<javierm>
tzimmermann: yes, and it's even more buggy because it caches the device count so if you even add a 4th one, it will not find it anymore
<karolherbst>
yep
<karolherbst>
in this case it's something userspace needs to fix anyway
itoral has quit [Remote host closed the connection]
<javierm>
karolherbst: yeah. I just shared Eric the `modprobe foodrm && modprobe bardrm && rmmod foodrm` example and claimed that's not a regression :)
<karolherbst>
:) good idea
<javierm>
thanks folks for the help
pnowack has joined #dri-devel
pnowack has quit [Quit: pnowack]
mszyprow has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
thellstrom has quit [Quit: thellstrom]
FireBurn has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
mszyprow has joined #dri-devel
<zmike>
pq: yeah that
mszyprow_ has joined #dri-devel
zehortigoza has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
Akari has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
mriesch has joined #dri-devel
Akari has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mszyprow_ has joined #dri-devel
JoniSt has joined #dri-devel
ppascher has joined #dri-devel
<JoniSt>
robclark: Hi! I'm not quite sure what I should do about Mesa MR 16993... Marek has reviewed it too but I don't have the necessary permissions to actually merge it. Does it need another review or does it just need someone to assign it to marge-bot?
mszyprow has quit [Ping timeout: 480 seconds]
<zmike>
JoniSt: I'll merge it soon
<JoniSt>
Ah, thanks a lot! :)
<zmike>
thanks for contributing
<JoniSt>
Oh and thank you too for the awesome blog :P
<zmike>
gasp
<zmike>
a reader?!
<JoniSt>
A reader indeed! Came for the technical content, stayed for the memery
<zmike>
that reminds me I've been meaning to blog again
JohnnyonFlame has joined #dri-devel
Danct12 has joined #dri-devel
mclasen has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
sergi has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt_: How would you feel if someone voulenteered to convert the FF program stuff to NIR now that we don't have any TGSI drivers?
yogesh_m1 has quit [Ping timeout: 480 seconds]
rsripada_ has quit []
rsripada_ has joined #dri-devel
kts has joined #dri-devel
guru_ has joined #dri-devel
fxkamd has quit []
oneforall2 has quit [Ping timeout: 480 seconds]
<ajax>
just don't regress i915 and i'm happy
kts has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: Are you thinking nir_builder? Or some other way of describing it like a text form or GLSL source?
<jekstrand>
nir_builder
Putti has joined #dri-devel
Putti[l]_ has joined #dri-devel
Putti[l]_ has quit []
JohnnyonF has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<anholt_>
jekstrand: sounds lovely
technopoirot has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt_: italove and and I were digging into a virgil issue this morning that involved FF shaders and I was reminded that fragment is GLSL and vertex is still mesa IR. :-/
<anholt_>
yeah, both of those would be lovely to get fixed.
<anholt_>
would be excellent evoc projects if someone wanted to mentor.,
<jenatali>
Is it really so bad to have the fragment as GLSL?
<anholt_>
unnecessary translation layer, harder to reason about, probably more code than nir_builder would be.
<jekstrand>
&&
<jekstrand>
^^, rather
<jenatali>
I find it hard to believe that it'd be more code than nir_builder honestly. That's pretty verbose
<jekstrand>
Getting VS converted would get us one step closer to deleting an IR.
<jenatali>
Yeah that totally makes sense to me
<jekstrand>
jenatali: To me, switching FS is more about consistency than code cleanup. Having them in different IRs makes it really hard to reason about that code.
<jenatali>
I was actually reading the FF fragment shader the other day (debugging a different GLES1 FF shader which got stuff wrong...) and didn't mind that it was GLSL
<jekstrand>
It's also more maintainable. Basically everyone has nir_builder experience. The number of people who can reliably write GLSL IR builder code is getting vanishingly small.
shankaru has quit [Quit: Leaving.]
<jenatali>
Fair
<jekstrand>
I doubt it'd be a LOC reduction by much
<jekstrand>
Scanning through it now.
shankaru has joined #dri-devel
ybogdano has joined #dri-devel
mbrost has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.5]
nchery has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
Putti has quit []
Putti has joined #dri-devel
nchery is now known as Guest3843
nchery has joined #dri-devel
nchery is now known as Guest3844
nchery has joined #dri-devel
Guest3843 has quit [Ping timeout: 480 seconds]
Guest3844 has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
rasterman has quit [Quit: Gettin' stinky!]
moony has joined #dri-devel
<JoniSt>
zmike: Do you know what's going on with that glx-multithread-buffer crash in zink that prevented the merge?
frieder has quit [Ping timeout: 480 seconds]
<linkmauve>
Hi, sunxi people, after trying SDL’s DRM backend (which I had completely forgotten about), I get some spam in dmesg and the screen went fully black: https://linkmauve.fr/files/sun4i-drm.txt
<linkmauve>
Where would you prefer me to report this kind of bug?
<linkmauve>
I can still use the GPU block (for instance through waypipe), just not the display block.
<linkmauve>
This is a A10 SoC, in case this is relevant.
<linkmauve>
What is the current preferred way to start a compositor from ssh, still writing a systemd unit?
<linkmauve>
Did seatd change anything in that direction?
<zmike>
JoniSt: there were two pipeline flakes so I assigned it again
<JoniSt>
Hmm... Well, the failed / flaky Zink test fired an assert so that's probably an actual bug but unrelated to this MR I guess
<JoniSt>
Though, not sure, the MR might've exposed it
<zmike>
no, it's unrelated
<zmike>
the glx tests are all flaky and I haven't added enough flakes in the ci list
<JoniSt>
Ah, alright!
mszyprow_ has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
<kennylevinsen>
linkmauve: with seatd you just launch the compositor. It takes the current VT regardless how you start it, assuming it's free.
<kennylevinsen>
Requires seatd to be running, or seatd-launch to be used, but no fidgeting with session IDs or systemd units with special PAM stacks
<karolherbst>
dcbaker: mhh.. I think we might need a llvm-config option for meson configure. Main issue is, that if you put llvm-config in PATH it can mess up rust tooling
<karolherbst>
guess I could use cross files for that...
<linkmauve>
kennylevinsen, do you remember if it was present in weston 10, or if I have to build master?
gouchi has joined #dri-devel
<dcbaker>
you can use a native file for that. It's pretty annoying that rust gets screwed up by :/
<karolherbst>
well.. I don't think that rustc itself gets screwed up, but bindgen totally does
<karolherbst>
uses my custom llvms header files and all that
guru_ has quit []
<karolherbst>
getting nice errors like "/home/kherbst/local/lib64/clang/15.0.0/include/emmintrin.h:2108:10: error: invalid conversion between vector type '__m128i' (vector of 2 'long long' values) and integer type 'int' of different size"
<karolherbst>
...
oneforall2 has joined #dri-devel
<dcbaker>
sigh, bindgen. Yeah, of course
<karolherbst>
guess there is no easy solution :(
<karolherbst>
well.. after the llvm-15 release I won't need my local llvm anymore (tm)
<karolherbst>
anyway.. the native file works
<linkmauve>
kennylevinsen, after building weston main, it indeed works as you said, thanks!
<linkmauve>
Woah, there is a super weird bug which makes the whole screen “scale” in the vertical direction all the time when a GLES program is using the GPU. :/
heat has joined #dri-devel
iive has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
<karolherbst>
noooo.. why do I have 12 crashes out of the sudden
<linkmauve>
Not always the entire screen, I limited my program to 1 fps and it feels like the window stretches towards the bottom every second.
<linkmauve>
So weird.
<karolherbst>
"fun"
<linkmauve>
Ah, the client doesn’t need to do GLES, even weston-simple-shm triggers the bug.
<linkmauve>
Slightly less though.
devilhorns has quit []
<linkmauve>
Oh, even the change of minute in the bar triggers the bug.
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
<jenatali>
Hm... looking at the Vulkan ICD loader, looks like they added a version 6 to the loader-ICD interface, but it's only defined for Windows ICDs...
<jenatali>
What happens when they want to add a v7 that applies to Linux too? Or what happens if a Linux driver claims v6?
<jenatali>
jekstrand: ^^ you might know or have thoughts
Haaninjo has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: We can bump to v6 with zero work, probably.
<jekstrand>
jenatali: If it's only defined for Windows then it's probably identical to v5 for Linux.
<jenatali>
Ok that makes sense. I was just surprised to not see that called out anywhere in the docs
<karolherbst>
without any additional driver fixes it's "Pass 2319 Fails 10 Crashes 23 Timeouts 0: 100%" on gen12 iris
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
ngcortes has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
zehortigoza has quit [Remote host closed the connection]
frankbinns1 has quit []
gouchi has quit [Quit: Quitte]
toolchains has joined #dri-devel
stuart has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
LexSfX has quit []
toolchains has joined #dri-devel
LexSfX has joined #dri-devel
aswar002_ has quit []
<JoniSt>
zmike: With the patch in MR 16993, TC stops mapping/updating buffers in Buffer(Sub)Data and instead always reallocates them since the buffers might be busy in another context, so zink's buffer allocation code is hit a lot more (at every upload, in fact). Dunno if that helps.
aswar002 has joined #dri-devel
<JoniSt>
Random thought... Is zink happy when one zink context reallocates a buffer belonging to another zink context, or does zink have to do additional setup for the reallocated buffer which might get missed? Because TC will do that when it thinks a buffer is still busy
technopoirot has joined #dri-devel
rasterman has joined #dri-devel
<columbarius>
gbm question: what's the state of GBM_BO_USE_RENDERING wrt. gbm_bo_create_with_modifiers2? Afaih mesa ignores it. Is it considered invalid and should not be used?
<JoniSt>
As far as I can tell from the glx-multithreaded-buffer test's source, it has always synchronized the pipeline with glReadPixels so the buffer was never busy before, meaning that TC never reallocated it so far. With MR 16993 it now always reallocates it instead, and apparently that screws things up
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
<zmike>
yeah I'll get to it tomorrow
pcercuei has quit [Quit: dodo]
Putti[l]_ has joined #dri-devel
bluestang2006 has quit [Remote host closed the connection]