ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<DemiMarie>
Looks like a P core has maybe 50% more ALU area than the XVEs in the Xe<sup>2</sup>-LPG core, but there are half as many of them and probably a latency vs throughput tradeoff (higher throughput on the GPU). The GPU almost certainly is much more power efficient at math, and that is before fixed function is considered.
<DemiMarie>
HdkR: does anyone actually have a use for those NPUs?
<HdkR>
They certainly have ideas of using them
<HdkR>
Like the Microsoft Copilot thing
<HdkR>
My eyes glaze over whenever AI is mentioned so I don't know what these tiny things can even do. LLMs or something?
Haaninjo has quit [Quit: Ex-Chat]
<DemiMarie>
Text to speech, speech to text, and object recognition are the obvious ones to me.
<DemiMarie>
All done on device, which is good for privacy.
marc2377 has joined #dri-devel
<karolherbst>
alt text generation could be a cool feature as well
<karolherbst>
I think if it's pre generated and users just need to fix a few bits would be able to nudge people enough to write more alt-text for posted images
<karolherbst>
there are quite some interesting use case for accessibility in general
<karolherbst>
I wonder if AI/ML could also help with some sort of hearing disabilities, where audio is adjusted enough to account for those. Not every hearing disability is about hearing loss
u-amarsh04 has quit []
<airlied>
the problem for Linux is even if we could access the hw devices (which is a mess), we don't really have the models to deploy
<karolherbst>
noise suppression apparently is also a great use case as non AI solution kinda sucked
<karolherbst>
yeah....
<karolherbst>
the ecosystem isn't great atm 🙃
amarsh04 has joined #dri-devel
<DemiMarie>
airlied: isn't Intel upstreaming drivers? Or did they leave out the userspace?
<karolherbst>
it's more about the AI modles
<karolherbst>
*models
<karolherbst>
mostly ethical and licensing concerns
<DemiMarie>
Which the proprietary vendors just ignore?
<karolherbst>
would a linux distro be allowed to ship those?
<karolherbst>
would they want to take the legal risk?
<DemiMarie>
Depends on the model, obviously
<karolherbst>
not really, because there aren't models free of copyright violations as far as I know
<DemiMarie>
Even small recognition models.
<DemiMarie>
?
<karolherbst>
mhh.. they _might_ be okay
<karolherbst>
it kinda depends
<karolherbst>
there is also always fair use
<karolherbst>
but the original point still stands: it's a legal risk
<alyssa>
nothing fair about cat i farted
<DemiMarie>
Will it ever be resolved in any way?
<karolherbst>
so if linux distros use those models for accessibility features, it might be considered fair use even if there are copyright violations
<karolherbst>
mhh going to court?
<karolherbst>
kinda need either legislation or court rulings
<airlied>
depends on of the owners of the models, provide licenses properly
<airlied>
or indemnity
<karolherbst>
yeah...
<karolherbst>
I think some fair use rulings could help out a lot as well
<karolherbst>
but yeah...
<karolherbst>
but then it also differs from country to country
<DemiMarie>
Fair use is very dependent on both the exact use and on jurisdiction. Lots of places don't have it at all.
<DemiMarie>
Also distros want stuff that is free for any purpose.
<DemiMarie>
That means stuff that is properly licensed.
<karolherbst>
yeah...
<DemiMarie>
The problem is that training data isn't just something one can produce oneself.
<DemiMarie>
Public domain works aren't useful either (too old).
<DemiMarie>
Somebody like Mozilla could do it, though, by being very careful at every step and ensuring they had licenses from everyone involved.
<DemiMarie>
I think recognition models are going to be much less risky than generative models.
<DemiMarie>
Generative models don't do well on clients anyway because of the enormous model sizes.
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
<iive>
surveillance camera footage of public spaces (roads) is Public Domain. That's why a lot of captcha uses them.
<iive>
this is about training AI models.
<iive>
but yeh, open source will have to make their own models from scratch, to be sure they are proper.
iive has quit [Quit: They came for me...]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
<DemiMarie>
Purely a curiosity question: can pvr ever become conformant to Vulkan 1.0 or is it too broken?
<DemiMarie>
(it = the hardware)
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
<Shibe>
soreau: tried in a gentoo chroot with your patches applied to mesa, same issue unfortunately, can't get pipewire streams working on iGPU
<Shibe>
still not sure if this is a mesa issue
<Shibe>
because if I run a compositor using DRI_PRIME=1! then an application inside using DRI_PRIME=0, then there's no graphical issues displaying that application
<Shibe>
but otoh that means every compositor (or application)'s portal implementation is broken
alane has quit []
alane has joined #dri-devel
vedranm_ has joined #dri-devel
vedranm has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
nopjmp has joined #dri-devel
ellyq_ has joined #dri-devel
The_Company has joined #dri-devel
ellyq has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
<alyssa>
karolherbst: so.. AGX needs some int64-bit lowering, but it needs to happen late for address mode fusing to work properly
<alyssa>
my backend calls nir_lower_int64 itself
<alyssa>
if I comment out the int64 call in rusticl, things work
<alyssa>
but I don't see any way around this, since lower_int64 takes its options from the options struct which is const
nopjmp has quit []
edolnx has joined #dri-devel
<alyssa>
I've added a nir option in my branch, but that seems pretty icky
edolnx_ has quit [Ping timeout: 480 seconds]
nopjmp has joined #dri-devel
nopjmp has quit []
nopjmp has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
pcercuei has quit [Quit: dodo]
melonai has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
himal has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
mbrost has joined #dri-devel
oneforall2 has joined #dri-devel
The_Company has quit []
bmodem has joined #dri-devel
sukuna has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
fab has joined #dri-devel
marc2377 has quit [Quit: Leaving]
sima has joined #dri-devel
sima has quit [Remote host closed the connection]
sima has joined #dri-devel
jsa1 has joined #dri-devel
coldfeet has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
kts has quit []
cascardo_ has joined #dri-devel
mbrost has joined #dri-devel
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
sassefa has quit [Remote host closed the connection]
vliaskov__ has joined #dri-devel
vliaskov_ has joined #dri-devel
<airlied>
sima: fyi just pushing out a backmerge, I'll merge the trees that needed it tomorrow
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
warpme has joined #dri-devel
vedranm_ is now known as vedranm
mbrost_ has quit []
karenw has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
apinheiro has joined #dri-devel
gnarchie has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
tzimmermann has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
fomys_ has joined #dri-devel
lynxeye has joined #dri-devel
<sima>
airlied, aye
gouchi has joined #dri-devel
<pq>
Shibe, importing dmabuf allocated on one device to another device that does not support modifiers is very likely to break for mismatching modifiers indeed. One could argue that even attempting that might be a bug in the compositor or display server, assuming this is what happens.
<pq>
Shibe, another possibility is the screenshooting somehow missing the modifier. A modifier problem seems likely to me. I'd report it to the compositor or display server first.
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
jkrzyszt has joined #dri-devel
rasterman has joined #dri-devel
heat has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Shibe>
pq: but couldn't it equally likely be a bug in the application using the portal since those would have to import the dmabuff too?
<Shibe>
but i will report it in kwin regardless
<pq>
it could indeed
gouchi has quit [Quit: Quitte]
<pq>
If you know the app is getting a dmabuf to import, then reporting to them could be worthwhile. Especially if some debug tool can tell you that the dmabuf has a pixel format with a not linear modifier.
<pq>
A dmabuf with any valid modifier should only be imported to a device/API that supports explicit modifiers.
<pq>
A dmabuf with the invalid modifier (no modifier) can only be imported to the same device where it was allocated, but one cannot tell the device by looking at the dmabuf AFAIK, so that's possible only if the device is explicitly mentioned along with the dmabuf.