mehdi-djait3397165695212282475 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
Guest6636 has quit []
u-amarsh04 has quit []
fab__ has joined #dri-devel
fab__ is now known as Guest6637
mvlad has joined #dri-devel
rgallaispou has joined #dri-devel
<tzimmermann>
jfalempe, thanks for reviewing the ast series
<tzimmermann>
jfalempe, i have ~10 more patches for ast. they clean up the selection+validation of the display modes. do you prefer a long series or shall i split it into two smaller ones?
<karolherbst>
jenatali: any plans for program scope global variables? My current plan is to simply specify the address of the variable at compile time as we need it for spec constant ops. I wonder if that solution also works for you? Can you do allocation where you can rely on the address or even assign the address yourself? Then me adding a
<karolherbst>
".global_var_base_addr" field to spirv_to_nir_options would be all that's needed to properly suppot this feature. I'm interested in it, because the CTS relies on it while testing for the generic address space, and I don't want to bother to fix the tests, because I need this feature for other things 🙃
<jfalempe>
tzimmermann: you're welcome, I'm fine with a long series.
rgallaispou has quit [Read error: Connection reset by peer]
<tzimmermann>
jfalempe, great, thanks a lot! it needs some more testing before i send it out
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
sgruszka has joined #dri-devel
hansg has joined #dri-devel
u-amarsh04 has joined #dri-devel
guludo has joined #dri-devel
apinheiro has joined #dri-devel
epoch101 has joined #dri-devel
lemonesque has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has joined #dri-devel
lemonesque has joined #dri-devel
<sima>
tzimmermann, I guess you'll push the build fix from arnd to make sure it's in this week's pr train?
vliaskov__ has quit [Remote host closed the connection]
vliaskov__ has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<tzimmermann>
sima, done now
<sima>
thx
kts has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
NiGaR has quit []
cascardo has joined #dri-devel
cascardo_ has quit [Ping timeout: 480 seconds]
calebccff_ is now known as calebccff
epoch101 has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Karyon has joined #dri-devel
<jenatali>
karolherbst: sure sounds like that should work
vliaskov__ has quit [Remote host closed the connection]
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
<zmike>
mareko: I'm trying to trace your glapi thing through libGL/waffle
<zmike>
any tips?
JRepin has quit []
JRepin has joined #dri-devel
<jenatali>
zmike: maybe start with seeing which commit breaks it?
<zmike>
well that's the easy part since it's the first commit
<jenatali>
Huh. Interesting
<zmike>
yeah
<zmike>
somehow I just get noop functions once that's applied
<mareko>
zmike: seergdb?
<zmike>
hm _glapi_tls_Dispatch is pointing to table_noop_array
<mareko>
or gdbgui
<zmike>
how does that help me over regular gdb?
<mareko>
stepping through asm instructions instead of C code is nicer
<mareko>
and breakpoints
<mareko>
though printf probably beats most debuggers
<mareko>
there are at least 2 reasons why the dispatch would be noop: either there is no current context or _glapi_set_dispatch is called from a wrong thread
youareillpeople has joined #dri-devel
<mareko>
or there is more than one _glapi_tls_Dispatch
<zmike>
seems like it's all being called from the same thread
<zmike>
and as near as I can tell there is a current context
Guest6637 has quit []
youareillpeople has quit [Remote host closed the connection]
youareillpeople has joined #dri-devel
youareillpeople has left #dri-devel [#dri-devel]
youareillpeople has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
heat has joined #dri-devel
pcercuei has joined #dri-devel
<zmike>
hm there's a glGetError call before glGetString and that hits noopGetError too
<youareillpeople>
<youareillpeople> it’s that the formula is in the most capable conditionless format for your old gpus, its the smallest military grade linear algebra cause conditionals will bust the gpu instruction limits on r300. you can do that on 8bit controller too, by using intrinsics to execute arbitrary precision adds its cheaper than the conditionals on of single delta based method. its cause
pcercuei has quit [Read error: Connection reset by peer]
<youareillpeople>
hashmaps would <youareillpeople> require calling much of the conditional sets which is itself the only way to do it using one delta per value.
itoral has quit [Remote host closed the connection]
<youareillpeople>
so good luck in doing detonation of bombs and super cañculations with pocket calculator
<youareillpeople>
you are entirely toxic and idiotic people
youareillpeople has quit [Remote host closed the connection]
tlwoerner has joined #dri-devel
<zmike>
mareko: it looks like the dispatch table is being set correctly? or at least with/without the first commit I'm seeing ctx->GLApi=ctx->MarshalExec in glthread and then that pointer is set in _glapi_set_dispatch
pcercuei has joined #dri-devel
MrCooper has quit [Read error: Connection reset by peer]
MrCooper has joined #dri-devel
tlwoerner_ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
youareillpeople has joined #dri-devel
youareillpeople has quit [Remote host closed the connection]
fab_ has joined #dri-devel
NiGaR has quit [Read error: Connection reset by peer]
fab_ is now known as Guest6661
NiGaR has joined #dri-devel
youareillpeople has joined #dri-devel
youareillpeople has quit [Remote host closed the connection]
nerdopolis has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
<mareko>
zmike: yes, the only change is that libglapi is moved to libgallium
<zmike>
mareko: okay, I think I've got it: it looks like my distro waffle is dynamically linked to the distro mesa's libglapi
<zmike>
which explains why my git waffle build doesn't have this issue: it doesn't link to glapi
<mareko>
that's worrisome
<mareko>
I wonder how that happened
<zmike>
dunno
<zmike>
this is on fedora 41
<zmike>
yeah so it's a waffle bug
<zmike>
not dynamically linked, sorry
<zmike>
waffle dlopens glapi
<mareko>
yes
<zmike>
in 1.7.0
<zmike>
but this is fixed in waffle c83212649b656bd66f57afe27d9ddf5a60a1405d from 2021
<zmike>
I don't know how it's possible that a fedora release from last year is using such an ancient waffle version but that's definitely the problem
<mareko>
zmike: assuming this is a symbol name conflict, what happens if you rename the exported libglapi symbols (identifiers) in Mesa?
<zmike>
uhh can you give me a patch to test for that?
<zmike>
or suggest changes
<mareko>
yes
sgruszka has joined #dri-devel
<MrCooper>
is there a point in working around waffle like that? Just use fixed waffle?
<zmike>
unfortunately that would break mesa for anyone using an affected version of waffle, though I'm not sure how many people/apps that is in practice
<zmike>
fwiw it looks like the fix for this wasn't shipped in any of the 1.7.x releases
dolphin has quit [Quit: Leaving]
<zmike>
only 1.8.x
tlwoerner has quit [Quit: Leaving]
<MrCooper>
FWIW, the only reverse dependencies of libwaffle-1-0 in Debian are apitrace & piglit
tlwoerner has joined #dri-devel
<zmike>
that's consistent with my knowledge
<zmike>
so maybe it's fine after all?
<zmike>
though CI will have to update
<zmike>
cc daniels mupuf
<mupuf>
Should be an easyfix
<mareko>
that explains why there is even a conflict - the problem isn't dlopen(libglapi), but RTLD_GLOBAL
hansg has quit [Read error: No route to host]
<MrCooper>
it's a bit surprising this only affects one CI job though
<zmike>
I think most ci jobs use debian, so maybe this is the only one using fedora
<DemiMarie>
jenatali: Windows GPU virtualization question: Would it be possible to create a WDDM 2.0 driver that wraps Vulkan?
<mareko>
zmike: I've added a commit into the MR that renames glapi symbols exported from libgallium
<zmike>
testing
<zmike>
works \o/
<jenatali>
Demi: what does that mean?
<zmike>
symbols no longer clobbered
<mareko>
zmike: amazing, thanks a lot
<daniels>
hrm, old glapi really shouldn't be present anywhere in CI
<DemiMarie>
jenatali: I want to support virtio-GPU native contexts with Windows guests, which means two things: the shader compiler runs in the guest, and the GPU is a paravirtualized one.
<zmike>
mareko: teamwork 🤝
<MrCooper>
zmike: Debian stable has waffle 1.7.0
<zmike>
cool so that's broken too
<MrCooper>
daniels has a point, system libglapi isn't supposed to be there in CI
<jenatali>
Demi: so you're asking, can you write a Windows WDDM2 kernel driver + Vulkan (and probably D3D) usermode drivers that translate to DRM virtio-GPU native contexts? Technically that's probably doable but sounds really hard
<DemiMarie>
jenatali: the goal is to use Mesa for the usermode part
<DemiMarie>
Mesa already implements Vulkan.
<mareko>
DemiMarie: the difficulty of supporting anything that is not Linux host on top of Linux guess is 100x at least
<mareko>
*guest
<jenatali>
You'll need to replace a lot of things. Mesa talks DRM, not WDDM (generally). If you want to use virtio-Gpu you either need a WDDM-to-DRM converter in a WDDM KMD which might be impossible, or you need to change the user mode stack of Windows to not require a WDDM driver, e.g. the Vulkan loader
bolson has joined #dri-devel
kzd has joined #dri-devel
<jenatali>
If you want things like the desktop compositor to be accelerated in that scheme, you need to replace D3D with something that can work with non-WDDM driver too, like vkd3d/dxvk. But then it's not out-of-the-box Windows anymore
<jenatali>
So you need a custom ISO or something for your VM
<jenatali>
So, good luck
<jenatali>
Or you would need to replace DxgKrnl so that can translate *all* of WDDM instead of just the KMD portions of it, which again makes it a custom ISO situation
<DemiMarie>
jenatali: There’s no way to avoid the custom installer in my case.
<jenatali>
That's not just a custom installer in the guest, you need to replace core OS components
Omax has quit [Ping timeout: 480 seconds]
<DemiMarie>
jenatali: Is a WDDM-to-DRM converter possible?
<jenatali>
Maybe?
<DemiMarie>
mareko: BSD guests should be fairly straightforward.
vsagar has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
u-amarsh04 has joined #dri-devel
youareillpeople has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
<youareillpeople>
<youareillpeople> we capture all the terrorists from finland,estonia,sweden tell me trash Lynne do you want to get death penalty? cause thats what they all get who conspired with terror against me, theres all the info what they arranged with court orders in the net, we execute them all by force.
youareillpeople has quit [Remote host closed the connection]
<mareko>
DemiMarie: not at all, the linux kernel GPU subsystem with virtio is required
frieder has quit [Remote host closed the connection]
youareillpeople has joined #dri-devel
youareillpeople has quit [Remote host closed the connection]
cascardo has joined #dri-devel
oneforall2 has joined #dri-devel
<DemiMarie>
mareko: All of the BSDs include a part of that subsystem.
<DemiMarie>
jenatali: How bad would replacing all of D3D be?
<DemiMarie>
Given that VKD3D and DXVK do work.
haaninjo has joined #dri-devel
davispuh has joined #dri-devel
<jenatali>
Good luck
youareillpeople has joined #dri-devel
youareillpeople has left #dri-devel [#dri-devel]
<DemiMarie>
jenatali: If a WDDM to DRM translator could be written, would the rest be doable?
guludo has joined #dri-devel
* DemiMarie
realizes why there is so much focus on SR-IOV and/or mediated pass-through in the enterprise world
mareko has quit [Read error: Connection reset by peer]
dri-logger has quit [Read error: Connection reset by peer]
<jenatali>
Idk
<jenatali>
You're looking at a ton of work by people who know all of these pieces intimately
<pac85>
I actually wonder whether it would be possible to make native context work with the existing userspace drivers
<pac85>
since UAPI is a relatively small surface
<DemiMarie>
pac85: It is definitely possible, if you can get the vendors of those drivers to cooperate.
dri-logger has joined #dri-devel
<DemiMarie>
The problem is that they are closed-source and proprietary.
mareko has joined #dri-devel
<DemiMarie>
jenatali: Is the protocol used by GPU-PV on Hyper-V documented?
<pac85>
DemiMarie: but maybe that wouldn't be strictly necessary? I'm talking about reimplemeting the kenel side so as to make it indistinguishable from userspace
<DemiMarie>
pac85: That is not possible without reverse engineering. See gfxstrand’s talk for details on why (tl;dr: the Windows interface is neither fully documented nor guaranteed stable).
<jenatali>
Demi: I thought so but I'm not sure
<jenatali>
The Windows interface is absolutely stable
<DemiMarie>
jenatali: `pPrivateData`
<jenatali>
Oh, yeah fair
<DemiMarie>
If you could deprecate non-NULL pPrivateData that would be awesome :)
<pac85>
DemiMarie: I'm familiar with the uapi for AMD to some extent and tbh I don't think it would be a problem to RE, nor that it is that unstable
<pac85>
like, sounds much to me like much less work thatn rewriting the whole userspace stack
<DemiMarie>
pac85: so one problem is that it might change in a security fix
<pac85>
and in fact I think the RE would be the least of your problems
<DemiMarie>
Where security fix = fix for remote code execution via WebGPU.
<pac85>
I don't think so?
<pac85>
I mean it can change in theory
<pac85>
but it kinda tends to just be stable in practice
* DemiMarie
wishes that Vulkan was not only the standard but also its implementation in Mesa, thus requiring everyone who wanted to implement Vulkan to do so in upstream Mesa
kts has joined #dri-devel
<pac85>
Windows actually has a way more uniform uapi than drm. Like buffer management is fully standard and docoumented afaik?
<DemiMarie>
pac85: The problem is the `pPrivateData` fields.
<pac85>
I think that's mainly for command subission though
<DemiMarie>
That said, gfxstrand was able to make Mesa use the AMD KMD.
<DemiMarie>
So it should be possible to reimplement a KMD that AMD can use, and rely on conformance to make sure it is correct.
<DemiMarie>
Then Red Hat could get some sort of contractual agreement with AMD to not break it.
phasta has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
dri-logger has quit [Read error: Connection reset by peer]
mareko has quit [Read error: Connection reset by peer]
dri-logger has joined #dri-devel
jannau has quit [Quit: WeeChat 4.3.3]
mareko has joined #dri-devel
rasterman has joined #dri-devel
janneg has joined #dri-devel
vliaskov_ has joined #dri-devel
janneg has left #dri-devel [#dri-devel]
jannau has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
jannau has quit []
tzimmermann has quit [Quit: Leaving]
ryanneph has joined #dri-devel
LeviYun has joined #dri-devel
oneforall2 has joined #dri-devel
LeviYun has quit [Read error: Connection reset by peer]
sgruszka has quit [Quit: Leaving]
oneforall2 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
<eric_engestrom>
dcbaker: sure, I'll make a release with the current state of the 24.3 branch :)
heat has joined #dri-devel
iive has joined #dri-devel
<eric_engestrom>
(and sorry for the delay, I'm not online often these days; I'll be fully back Feb 24, and before that pretty much only when dealing with 25.0 releases)
LeviYun has joined #dri-devel
<dcbaker>
eric_engestrom: no worries, and that would be great on 24.3. I appreciate the help, the flu that’s going around here this year is brutal
JRepin has quit []
JRepin has joined #dri-devel
<eric_engestrom>
(release.sh running right now)
<eric_engestrom>
I'm not quite sure what's different in your flow compared to mine, I see that you use MRs to sync staging/X.Y with X.Y, so maybe I'll mess up something and you'll have rebase conflicts or something 🙃
<eric_engestrom>
btw I'm not sure what to think of that MR flow, it removes the information of which MR the commit actually comes from, which can be useful eg. if there are regressions in a stable release... but also, I guess the real information is one "cherry-picked from $sha" indirection away, so it's not a big deal
<dcbaker>
I just use those when I have manually back ported patches to ensure that the full ci gets run
<dcbaker>
I’m sure I could trigger the full ci another way, but the Mesa ci is really complex
coldfeet has joined #dri-devel
<eric_engestrom>
dcbaker: release done, doing the docs update on main; do you want to post the release email or do you want me to do it?
<dcbaker>
Could you do the email? My client got broke by python 3.13 removing mailcap…
<eric_engestrom>
sure
vsagar has quit [Remote host closed the connection]
<eric_engestrom>
dcbaker: all done; for the calendar, I'll push back the next release one week so that it's 2 weeks from now, ok?
<zmike>
I want to find out when zink-anv-tgl-traces-restricted started failing
<zmike>
I guess I'll file a ticket
coldfeet has quit [Quit: Lost terminal]
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
blaztinn has quit [Remote host closed the connection]
<daniels>
eric_engestrom: do you mean pushing the 25.0 branchpoint back another week to Feb 4th, or a 24.3.x?
jannau has joined #dri-devel
<eric_engestrom>
daniels: see the commit I linked (I don't understand the second part of your question ^^)
<eric_engestrom>
zmike: that's not a thing, unfortunately; we (ci people) have been discussing developing a database for gitlab ci results so that we can do that sort of query, but it doesn't exist yet
<zmike>
I think it is a thing
<zmike>
and you are mistaken
<eric_engestrom>
I mean, you can manually look at any job you want
<eric_engestrom>
but I don't know how you would ask "when did this job flip from pass to fail"
<eric_engestrom>
but I would be very happy to be wrong :D
<eric_engestrom>
ah right, I keep forgetting grafana has some info like that
blaztinn has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<zmike>
I knew there was something but I couldn't remember where/how
<eric_engestrom>
thanks daniels :)
egbert has joined #dri-devel
<eric_engestrom>
I have to go now; dcbaker let me know on the MR if the calendar change (last commit) is not ok, and unassign Marge so it doesn't get published
lynxeye has quit [Quit: Leaving.]
nerdopolis has joined #dri-devel
<Venemo>
does anyone have any idea why vkcube disrespects DRI_PRIME?
blaztinn has quit [Remote host closed the connection]