youmukonpaku1337 has quit [Ping timeout: 480 seconds]
<kisak>
dcbaker: fwiw, I'm of the opinion that you don't need to fully clear your backlog before cutting -rc3. You can mark that off anywhere you feel comfortable, and it'll let the few people who do rc testing a chance to jump forward while you have more time for -rc4
<LaserEyess>
so to clarify should I put up a backport for MR for 23.1 and 23.2?
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
youmukonpaku1337 has joined #dri-devel
<dcbaker>
LaserEyess: you should open a backport for each branch you want to have a patch applied to. There are usually two maintainers, one doing the current release and one doing the previous release. So you did the right thing
<dcbaker>
kisak: that’s my plan. I kinda forgot that Monday is a holiday in the us (for me), so I guess we’ll have a release on Tuesday and another near the end of the week
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
junaid has joined #dri-devel
Duke`` has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
fab has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
junaid has quit [Remote host closed the connection]
smiles has joined #dri-devel
junaid has joined #dri-devel
sima has joined #dri-devel
itsmeluigi has joined #dri-devel
Company has joined #dri-devel
Haaninjo has joined #dri-devel
camus has quit []
i509vcb has quit [Quit: Connection closed for inactivity]
<karolherbst>
alyssa: we can't
<karolherbst>
it's still lacking important features
<karolherbst>
but anyway, I think for now clang uses the translator under the hood
<karolherbst>
for the spirv targets
<karolherbst>
and we can't really use it, because we have to be explicit about the extensions we support and other things
<karolherbst>
`But there is one caveat - currently clang requires an external tool ‘llvm-spirv’ from the SPIRV-LLVM-Translator repo to be installed separately` ah yes
<karolherbst>
but yeah.. you _can_ manually compile via clang + llvm-spirv directly and just ship that spir-v
kts has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
Guest1602 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
pcercuei has joined #dri-devel
smiles has quit [Read error: Connection reset by peer]
<DavidHeidelberg[m]>
alyssa: thanks for disabling the WHL
smiles has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
smiles has joined #dri-devel
JohnnyonFlame has joined #dri-devel
youmukonpaku1337 has joined #dri-devel
sravn has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
smiles has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
gouchi has quit [Quit: Quitte]
kts has joined #dri-devel
<alyssa>
karolherbst: ack
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
macromorgan is now known as Guest1636
Guest1636 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
lemonzest1 has joined #dri-devel
lemonzest has quit [Ping timeout: 480 seconds]
tristan__ has joined #dri-devel
lemonzest1 is now known as lemonzest
lemonzest has quit [Quit: WeeChat 4.0.4]
lemonzest has joined #dri-devel
tristan__ has quit [Ping timeout: 480 seconds]
smiles has joined #dri-devel
Danct12 has joined #dri-devel
smiles has quit [Read error: Connection reset by peer]
smiles has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
yyds has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
<MrCooper>
zamundaaa[m]: could be that glFinish waits only for the GPU command stream to finish processing, whereas the fences signal only once all results have been written back to memory; not sure offhand whether the former would be valid or a bug though
JohnnyonFlame has joined #dri-devel
<LaserEyess>
dcbaker: thanks! I still can't assign the maintainers, but I suppose you are aware of it now. No worries if it takes a bit, just hoping it gets in so that I can finally use vaapi again
An0num0us has joined #dri-devel
youmukonpaku1337 has quit [Quit: WeeChat 4.0.4]
dviola has quit [Read error: No route to host]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
glennk has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
fab has quit [Quit: fab]
jewins has joined #dri-devel
itsmeluigi has quit [Quit: Konversation terminated!]
kts has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
junaid has quit [Remote host closed the connection]
kzd has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<karolherbst>
alyssa: btw, there is a clc to spir-v offline compilation script in my cts runner repo, so I can run the entire CTS with SPIR-Vs instead of source code in case you want to see how one would use it
<alyssa>
karolherbst: I mean, mesa_clc works fine for me
<alyssa>
I'm just thinking about whether it makes sense to avoid the `native: both` mess long-term
<alyssa>
But if the long term is actually mesa_clc generating serialized NIR so we can do a pile of lowering+opt ahead-of-time, well, ok the
<karolherbst>
ahh, fair enough. It might make sense however to port over to the interface the CTS expects and then we can also use it for CTS runs and ahead-of-time compilations more generally
<karolherbst>
there are some people interested in having a tool to precompiled OpenCL C
<karolherbst>
*precompile
<alyssa>
I don't want to be in the business of supplying a generic tool
<alyssa>
and more importantly I don't want Mesa to have that support burden
<karolherbst>
me neither, but if we decide to have such a tool, we might as well make it compatible for such use cases
<alyssa>
no, I disagree
<alyssa>
this is purely for internal use. if later we decide to change how the pipeline looks (doing some NIR in there or whatever), we should be able to do so without regard for external suers
<karolherbst>
yeah, that's fair
<alyssa>
I explicitly don't want out-of-tree users
tristianc6704 has quit [Read error: Connection reset by peer]
<alyssa>
especially when there are projetcs better suited for that (namely, clang itself)
tristianc6704 has joined #dri-devel
<karolherbst>
right, but the point of suchs tools is more like shipping the native binary blobs, which I absolutely don't want to support, but I also kinda see the point of having 0 compilation overhead at runtime... it's just that nothing we care about would want to use that. It's more in the HPC space
<karolherbst>
but yeah.. I wished the CTS itself would ship that tool.. I should pring people again or just upstream my script
<karolherbst>
I'm still wondering if stopping at the spir-v with binary blobs will be a problem as CL has an API to fetch compiled blobs and some applications make heavy use of it. I hope we won't be forced (out of performance reasons) to ship native GPU binaries ever...
<alyssa>
right. I recognize that we have differing priorities here probably
heat has quit [Remote host closed the connection]
<alyssa>
you're interested in shipping CL, i'm interested in mesa internally using a subset of CL C for graphics stuff
<karolherbst>
yeah.. I just want that mesa provides some compute API so distributions/users/devs can rely on it being there and to crazi things, not really caring about HPC or any of that "let's ship native binaries" nonsense
<alyssa>
yeah
<alyssa>
for my side, the fact that CL is involved is an implementation detail
<alyssa>
what I actually want is just "get a nir_shader for some C code"
<alyssa>
not even necessarily invoked as a compute kernel, possibly just a single function that gets inlined into a frag shader by a nir lowering pass
<karolherbst>
yeah, that's fair. I just won't be surprised if in the far future we'll end up doing more with such a tool. Or maybe we won't.
<karolherbst>
yeah..
<alyssa>
sure, and we can discuss those possibilities in the future
<karolherbst>
so... some people are working on emiting vulkan spir-v btw
<alyssa>
it just.. might involve a second tool, perhaps, and that's finetoo
<karolherbst>
from OpenCL C
<alyssa>
the spirv is also an implementation detail, that's also what I'm getting at
<karolherbst>
not sure if it's going anywhere, but the translator kinda has a bit of support for it
<alyssa>
the API i'm exposing is "files in Mesa in, nir_shader* out", and whatever's happening in the middle should be irrelevant to everyone else
<karolherbst>
oh sure, I'm just thinking out loud here mostly
<alyssa>
that's internally passing through opencl spir-v but again that's an internal impl detail even from the perspective of the GL & VK Mesa drivers that will consume the final nir_shader,
<alyssa>
sure
<alyssa>
what I'm getting at is "I like your project and I hope you like my project but they're very different projects and trying to share code other than src/compiler/ is probably not what either of us want at this stage"
<alyssa>
if that makes sense?
<alyssa>
IDK. I could be totally wrong here. It happens a lot :D
<karolherbst>
nah, that's perfectly fine. and you are not wrong. I was mostly just rambling and sharing some of my internal toughts around all this binary mess I'm ignoring for now
<alyssa>
ah, yeah
<alyssa>
TBH the VK_EXT_shader_object model is probably saner than a standalone Mesa compiler.
<karolherbst>
yeah.. probably. Depends a little on what you want to do I guess?
smiles has joined #dri-devel
<DemiMarie>
Will the Xe driver have less kernel-side attack surface once it is ready?
<airlied>
what is a kernel side attack surface and how to you have less of it?
<airlied>
like if you can't answer that sort of question, it's unlikely anyone else can, your threat model is not my threat model etc
<karolherbst>
I think there is a disconnect with those kinda discussions. I understand why one would like to esstimate "security" from a theoretical point of view, _but_ sadly that's just some academic approach and irrelevant to reality and users. What matters is, how many bugs are known and how quickly do they get fixed.
<karolherbst>
and that bugfixes (not security fixes) get backported in time
<karolherbst>
we can have academical discussion on how secury something is in theory, but that's really a pointless discussion if you want to know about actual security
<karolherbst>
and actual security you only know about finding bugs and writing exploits to get them fixed quickly
<DemiMarie>
There is also the question of “how likely is somebody to be able to find and exploit a 0day for this”.
<DemiMarie>
That happens quite a bit in browsers for example.
<karolherbst>
sure, but if you want to know that, you pay sec people to do an audit
<karolherbst>
normally
<karolherbst>
maybe intel does audits themselves, maybe they don't
<DemiMarie>
yeah
<karolherbst>
but it's really hard for random kernel developers to anwer general statements about code security, because I suspect most of the kernel devs don't actually know enough about security to actually give reliable statements here
<DemiMarie>
you are probably right, which is sad
<DemiMarie>
maybe my expectations were too high
<karolherbst>
well.. nobody gets taught about programing security :P
<DemiMarie>
I blame the schools for that.
<karolherbst>
same
<DemiMarie>
When I was in university, I was taught that one can always assume one’s inputs to be valid, which is a great way to learn to write extremely vulnerable code.
<airlied>
in the old internet, everyone was nice, I blame the new internet :-P
<karolherbst>
I thought that's the reason to valide html forms in javascript :P
<DemiMarie>
On the one side, I have users someone might be willing to burn a 0day on. On the other side, I have toolkit authors who have decided that ordinary applications being nearly unusable without GPU acceleration isn’t a bug.
<karolherbst>
yeah....
<DemiMarie>
And if I can’t figure out what the risks of GPU acceleration are, then my userbase has no hope of doing so.
<karolherbst>
though if a toolkit is unusably slow with software rendering, that's kinda... uhm.. weird
<karolherbst>
and somebody should probably optimize the toolkit instead
<DemiMarie>
For me gnome-text-editor used 80% CPU scrolling quickly on a certain text file
<DemiMarie>
That toolkit is GTK4 btw
<karolherbst>
yeah... smooth scaling might do that if software rendered...
<karolherbst>
ehh
<karolherbst>
smooth scrolling
<DemiMarie>
smooth scrolling?
<karolherbst>
like instead of scrolling row by row, it's all smothed out
<karolherbst>
dunno.. maybe they listen more if you show it's also slow on "usual" intel GPUs?
<DemiMarie>
are some of those pretty slow?
<karolherbst>
I know that intel can't keep up on a 4k display
<karolherbst>
on gnome that is. And that problem kinda isn't prioritized enough, so it's all suboptimal
<DemiMarie>
which Intel?
<karolherbst>
10th gen or something
<DemiMarie>
do they only care about fancy dGPUs?
<karolherbst>
I have no idea
<karolherbst>
they problably just don't run on 4k
<karolherbst>
anyway, I suspect people will stop caring about sw rendering, because that's kinda a maintainance burdon, what however can do is to show that it's slow on normal users machines
<karolherbst>
if it's not, then I guess that strategy won't work
<karolherbst>
but from my experience, there are a few performance issues in gnome
<DemiMarie>
airlied: to a crude approximation, “kernel side attack surface” would be the various uAPI ioctls
<DemiMarie>
I’m scared people will also stop caring about old slow iGPUs
<DemiMarie>
and then I am really in a bad spot
Leopold_ has quit [Remote host closed the connection]
<karolherbst>
maybe desktop environments should set them some goals and say "it should run smoothly on GPUs from the last 10 years" or something :D
<karolherbst>
and then it's all more transparent or something
Leopold_ has joined #dri-devel
kchibisov_ is now known as kchibisov
<kchibisov>
karolherbst: isn't smooth scrolling is usually done by allocating larger canvas/texture and just moving viewport?
<karolherbst>
maybe?
<kchibisov>
So I'd guess with 4k they just have pretty large things in memory.
<kchibisov>
but gtk stuff is really slow when there's no hwaccel, like gnome-terminal is unusable on Wayland basically.
<DemiMarie>
kchibisov: I wonder if they are tripping over a bug in llvmpipe or just doing something really really unoptimized.
<kchibisov>
They use cairo.
<kchibisov>
no llvmpipe.
<kchibisov>
¯\_(ツ)_/¯
<karolherbst>
would llvmpipe be faster though? :D
<kchibisov>
alacritty with llvmpipe is faster iirc.
<DemiMarie>
karolherbst: thanks for at least being willing to talk to me about this stuff, even when you don’t have an answer.
<kchibisov>
I mean, faster than gnome terminal.
<DemiMarie>
kchibisov: GTK3 used Cairo for everything. GTK4 uses OpenGL by default. One can switch to Cairo (`GSK_RENDERER=cairo`) but it breaks certain apps and is deprecated.
<kchibisov>
DemiMarie: maybe, we just explicitly benchmarked all of those apps recently, and they were sort of slow.
<DemiMarie>
kchibisov: those = GTK apps with no HW accel?
<kchibisov>
DemiMarie: we were benchmarking input latency though, but some benchmarks showed that frame rate was not that great.
<DemiMarie>
kchibisov: did KDE do better?
<alyssa>
llvmpipe's shiny new linear renderer probably helps :)