gnuiyl has quit [Remote host closed the connection]
gnuiyl has joined #dri-devel
Daanct12 has joined #dri-devel
himal has quit [Ping timeout: 480 seconds]
Guest8488 has quit [Read error: No route to host]
fab_ has joined #dri-devel
fab_ is now known as Guest8491
Guest8491 has quit []
kzd has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frankbinns has joined #dri-devel
himal has joined #dri-devel
llyyrr has left #dri-devel [#dri-devel]
llyyr has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
<Lynne>
I'm just about sure that mesa is miscompiling my shader
<Lynne>
could someone look into it?
<Lynne>
affects all mesa drivers, anv, radv, and lavapipe, so I think the issue is with NIR
kts has joined #dri-devel
<airlied>
does it work on nvidia?
rasterman has joined #dri-devel
glennk has joined #dri-devel
<mareko>
what is VUE on Intel?
tzimmermann has joined #dri-devel
warpme has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest8498
lemonzest has quit [Quit: WeeChat 4.4.2]
kts has quit [Quit: Leaving]
coldfeet has joined #dri-devel
apinheiro has joined #dri-devel
vliaskov_ has joined #dri-devel
lemonzest has joined #dri-devel
heat has joined #dri-devel
rgallaispou has joined #dri-devel
MrCooper_ has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
frankbinns has joined #dri-devel
Thymo has joined #dri-devel
Thymo_ has quit [Ping timeout: 480 seconds]
<frankbinns>
DemiMarie: the conformance submission I linked is for the open source driver (the proprietary driver passes 1.3 conformance across a large range of GPUs)
<frankbinns>
we're currently in the process of upstreaming everything for Vulkan 1.0 & GLES 3.1 (via Zink)
<frankbinns>
with all the extensions, etc we had to implement for Zink the driver can almost expose Vulkan 1.1
<Lynne>
airlied: yes
<Lynne>
also I found out that I've fixed llvm in one of my latest rebases
<jani>
airlied: sima: if *you* say we should look into the process again, we will
LeviYun has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
warpme has joined #dri-devel
<sima>
jani, airlied yeah I think we'll just keep silently shrugging
<sima>
with amd and intel doing this regularly and also misc sometimes there's really no point trying to change it, the people (on dri-devel) have spoken
<sima>
agd5f, ^^ fyi
<sima>
also my irc fails at rejoining somehow since a few weeks :-/
<jani>
sima: there just isn't a good answer to having a fix to backport a fix from a non-rebasing -next branch
LeviYun has joined #dri-devel
<jani>
-"a fix"
<jani>
the 2nd one
<sima>
jani, imo it's more fundamental
<sima>
for gregkh linus' tree is the center of the world
<sima>
for a driver developer, it's the driver tree, which often is just $driver-next
<jani>
agreed
<sima>
and gregkh doesn't understand the different perspective somehow, and not for lack of us trying to explain it
Haaninjo has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
<airlied>
jani, sima : yeah I think there's almost a deliberate not getting it going on, maybe I should write a blog post to just point at
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<jani>
drm-misc is trying to apply fixes to -fixes and -next-fixes directly instead of cherry-picking, but a) I think it's hard for the large pool of developers to consistently get right, and you end up with cherry-picks anyway, and b) if you have a series with fixes first, you won't be able to merge the entire thing but have to wait for fixes to get applied to -fixes and backmerged to -next, slowing people down
<jani>
iiuc the only way to make git really understand what's going on is via merges, but I'm also under the impression that Linus doesn't want a ton of backmerges and crossmerges either
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
<sima>
jani, yeah we'd need topic branches for every fix that is needed for a feature patch set in -next
<sima>
I think that's even harder to get committers to consistently do than the current approach
<sima>
I'm wondering whether we should lean more towards "push to -next and cherry-pick if you need some as fixes" even for drm-misc
<sima>
to avoid some of the confusion
<sima>
because it's really the simplest model for committers
<sima>
airlied, blog sounds good
<jani>
yes, that's the thing. do what's easiest for developers/committers, don't add more hurdles
<sima>
yeah
<jani>
"develop on top of drm-tip or -next, preferrably put fixes first in the series, push to -next"
<jani>
instead of, "well, you see, apply patches depending on what they do to a branch that depends on where we are in the development of the current linus' upstream, and maybe sometimes you'll get it right"
<sima>
yeah the 2nd one I screw up too since I don't do it daily anymore like way back in the committer-less model
<jani>
"yes it's a fix, but it's not small enough or important enough to be applied to -fixes at this stage"
<sima>
yeah or people just dumping their fixes in at -rc6 because "oops forgot there's a kernel release"
<sima>
into -fixes I mean, not -next
<sima>
airlied, yeah a blog that just explains how everyone has a different kernel branch that's they're center of the world is probably all that's needed ...
<frankbinns>
DemiMarie: we'll be adding the missing bits for Vulkan 1.1 & 1.2 next year
<frankbinns>
no specific plans for Vulkan 1.3 or OpenGL 4.6 as of yet
<DemiMarie>
frankbinns: does the HW support it?
<frankbinns>
DemiMarie: Rogue support VK 1.3 but not GL 4.6 afaik
adjtm is now known as Guest8530
adjtm has joined #dri-devel
halves has quit [Quit: o/]
Guest8530 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<sima>
airlied, I kinda started drafting, will ping you when I have something
<sima>
jani, you too and maybe agd5f
<DemiMarie>
frankbinns: Could one use SW emulation? Asahi is able to get VK 1.3 and GL 4.6 on HW that doesn't even support geometry shaders or tessellation.
<agd5f>
sima, sounds good
<frankbinns>
DemiMarie: yeah, I expect that should work
<DemiMarie>
frankbinns: Does Rogue have enough compute power for ”do everything missing in compute shaders” to work, and are the driver devs willing to go as far as alyssa?
<DemiMarie>
frankbinns: do you want VK 1.3 with enough extensions for Proton & gaming?
davispuh has joined #dri-devel
cmichael has quit [Quit: Leaving]
hansg has joined #dri-devel
<frankbinns>
DemiMarie: lets just say, there's a lot of different things we can focus on and we don't want to plan too far ahead
<DemiMarie>
frankbinns: Fair!
<DemiMarie>
Does Mesa have specific functions it uses to access GPU VRAM from the CPU?
adjtm is now known as Guest8534
adjtm has joined #dri-devel
<pixelcluster>
DemiMarie: in general? no, drivers usually have some (more-or-less) internal way of mapping buffers and reading/writing that mapped memory
<pixelcluster>
e.g. RADV has buffer_map in radv_radeon_winsys for that
Guest8534 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Duke`` has joined #dri-devel
fab is now known as Guest8536
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
vliaskov_ has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
diego has joined #dri-devel
Mangix has joined #dri-devel
mbrost has joined #dri-devel
Guest8536 has quit [Read error: Connection reset by peer]
heat has quit [Read error: Connection reset by peer]
FaRiD1986 has quit [Remote host closed the connection]
heat has joined #dri-devel
FaRiD1986 has joined #dri-devel
guludo has quit [Quit: WeeChat 4.4.2]
guludo has joined #dri-devel
<DemiMarie>
pixelcluster: The reason I ask is that if all VRAM access had to go through specific Mesa functions, it would unlock dGPU support on many Arm platforms.
<DemiMarie>
Right now, those require unaligned access emulation in the kernel, which is slow and out of tree.
<pixelcluster>
DemiMarie: what about applications calling vkMapMemory though? maybe the drivers can be reworked (big maybe btw), but you can't just change all apps, can you?
<DemiMarie>
pixelcluster: had not thought of that
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
frankbinns has quit [Ping timeout: 480 seconds]
FaRiD1986 has quit []
FaRiD1986 has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
<Company>
jenatali: I have another question from my d3d12 adventures - dzn treats D3D11 textures and D3D12 resources interchangably - is that allowed? I was wondering why VkImportMemoryWin32HandleInfoKHR needs a handle_type and there's one for D3D11 and D3D12 and OPAQUE_HANDLE and whatnot, but ID3D12Device::OpenSharedHandle() doesn't care about handle types at all
diego has left #dri-devel [#dri-devel]
<jenatali>
D3D11 -> D3D12 sharing is a special case of something that we tried to make work transparently
<Company>
I also found ID3D11Device5::CreateFence()
dviola has joined #dri-devel
<Company>
so now I'm wondering if I can assume that D3D11 and D3D12 can work interchangably
<Company>
always? usually? sometimes? rarely? almost never?
<jenatali>
Usually
<Company>
so "write code that can deal with it not working, but assume it works"
<jenatali>
Like, the Windows compositor is D3D11 still, except for cases where it uses D3D12 like for beam-chasing ink rendering or VR late-stage reprojection. So a D3D12 app using ink would do 12 -> 11 -> 12 on the path to the screen
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<Company>
yeah, I wondered about that, too - I can use a lot more APIs in the compositor if I can just turn my D3D12 objects into D3D11 objects
<jenatali>
You'll also want to ensure you've got SIMULTANEOUS_ACCESS, since 11 doesn't have any kind of barriers, so no way to express layout transitions on input/output
epoch101 has joined #dri-devel
<Company>
yeah, we need that anyway
<Company>
it's all for external apps (read: mainly video players) feeding GTK buffers to display
<Company>
so I have a limited ability to decide what kind of buffer I get, but I can probably assume people will do what's necessary
<jenatali>
FYI to avoid taking this channel too off-topic, we do have a dedicated DX Discord server if you want
<jenatali>
I don't mind either way, I just know it's not what this channel's supposed to be for :)
rpavlik has joined #dri-devel
* Company
doesn't even use discord
ElementW has joined #dri-devel
<Company>
but if people mind, I'll stop asking
<bl4ckb0ne>
i was looking into that earlier today, i didnt understand why there's so many different D3D handle type
tyzef has joined #dri-devel
<rpavlik>
it's bl4ckb0ne's fault I showed in here, I have extensive d3d handle type trauma
<jenatali>
Yeah I don't really understand why either tbh
DodoGTA has quit [Quit: DodoGTA]
<bl4ckb0ne>
is there any doc about which one should be prefered?
<Company>
the one you have probably
<bl4ckb0ne>
we're using the OPAQUE WIN32 atm for d3d12 but i feel like the D3D12 resource one should be prefered
<rpavlik>
from the d3d side, in practice, prefer the global dxgi handles because there are weird limitations from the NT handles, despite the global dxgi handles being allegedly deprecated.
DodoGTA has joined #dri-devel
<Company>
bl4ckb0ne: dzn opens OPAQUE first as a heap and then as a resource I think
<rpavlik>
I do not remember how I picked which type to specify when importing
<jenatali>
I don't know that it really matters. At the end of the day, an allocation is an allocation, and the driver should be able to interpret its associated metadata to figure out what it is without being told at the API
<Company>
and for resource type it only tries resource
sukuna has joined #dri-devel
coldfeet has joined #dri-devel
<jenatali>
The problem with the KMT handles compared to NT is lifetime and security. With KMT handles, if the original resource goes away before the handle gets opened, the handle becomes invalidated. With NT, the handle has its own lifetime which can outlive the source resource
<jenatali>
And KMT is session-wide where NT is process-local
<rpavlik>
yes, but some types (especially depth textures) can't be exported as nt handles
<jenatali>
Yeah, D3D11 has a bunch of restrictions there because it was never tested. D3D12 throws away all the restrictions
<rpavlik>
(speaking as a Monado dev, so I'm sharing graphics handles between processes, sometimes, and definitely between apis)
<rpavlik>
I have joked that my primary Vulkan expertise is in importing and exporting :D
<bl4ckb0ne>
i feel like we need another handle type to unify all of that :D
<jenatali>
:P
<Company>
if you make it a file descriptor, you win
<jenatali>
The other fun part is that you can actually tell if a handle is an NT handle or not just by looking at the values. NT handles have the low 2 bits set to 0 where the GDI-style handles have a tag stored there
<jenatali>
So having two handle types for them isn't even necessary
<rpavlik>
wait there is already a tag there?
<rpavlik>
🤦♀️
<jenatali>
In the DDK headers I see #define D3DKMT_GDI_STYLE_HANDLE_DECORATION 0x2
<rpavlik>
well that's fancy
<rpavlik>
ok now I'm gonna have to fire things up here and test stuff
rasterman has joined #dri-devel
fomys_ has quit []
tyzef has quit []
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
redisaigner has joined #dri-devel
redisaigner has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
madgender has joined #dri-devel
madgender has quit [Remote host closed the connection]
guludo has quit [Quit: WeeChat 4.4.2]
guludo has joined #dri-devel
<alyssa>
..now im not sure if my own patch is sound *cry*
madgender has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
madgender has quit [Remote host closed the connection]
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
bluetailoff has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
kaiwenjo1 has joined #dri-devel
kaiwenjo1 has quit []
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
<bluetailoff>
last occasions, i did bang the calculator for 2-3months i think to find a way to avoid division by two on access of indexed compress encoded data, and i did not think it was possible (started to think so and give up) but i succeeded on this finally, and it looks pretty elegent, this really ends all my research on among those lines, i think i got maximum out, cleaning up linux based
<bluetailoff>
systems i can not participate , cause i am not interested in fighting you. I can not really find another human who would work on last module for 2months every day just to remove the bitshift by one out of the way in the formula. I am really bad maximalist, idealist and so tired too cause of that, it bites back i can see :)
<bluetailoff>
but i promised to leave, just let you know that i quit, and there is no need to go crazy on the issues over me anymore .
epoch101 has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Ping timeout: 480 seconds]
FaRiD1986 has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
FaRiD1986 has joined #dri-devel
<bluetailoff>
You have my permission to use anything i developed cause i am getting older and older every day and i am a tired man, just to let you know that those models on linux for deep learning can be on linux built by far more superior than others have with licenses currently, and technically that is the way it should go too, but ...whatever.
FaRiD1986 has quit [Remote host closed the connection]
epoch101 has joined #dri-devel
halves has joined #dri-devel
FaRiD1986 has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
bluetailoff has quit [Remote host closed the connection]
bluetailoff has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
hansg has quit [Remote host closed the connection]
halves has quit [Remote host closed the connection]
halves has joined #dri-devel
bluetailoff has quit [Remote host closed the connection]
epoch101 has quit []
adjtm has joined #dri-devel
epoch101 has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
<pendingchaos>
so b5 has only one "actual" predecessor
<dj-death>
this appears to be fixed on main
<jenatali>
Ooh, yeah that loop is important
<dj-death>
I'll bisect tomorrow
frankbinns has joined #dri-devel
mbrost_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<alyssa>
......I am even less convinced then before this code is correct for sufficiently torturous deref chains
mbrost has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
<alyssa>
this isn't going to work is it.
vliaskov_ has joined #dri-devel
Haaninjo has joined #dri-devel
vliaskov__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
<alyssa>
ok, new idea
coldfeet has quit [Remote host closed the connection]
<alyssa>
if I cap storage buffers at 2GB, I can use i2i64 instead
<alyssa>
and then the important thing is nsw instead of nuw
<alyssa>
which I think will actually work even in crazy cases
<alyssa>
or... do something at a higher level.... actually...
<alyssa>
wwwwwwwait
warpme has joined #dri-devel
warpme has quit []
kaiwenjon has joined #dri-devel
iive has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
iive has joined #dri-devel
riteo has quit [Remote host closed the connection]
riteo has joined #dri-devel
<alyssa>
or maybe it is fine because derefs
* alyssa
rubs head
<alyssa>
the 'case' that breaks it would be, like, x[-1][1] and expecting to get x[0][0]
<alyssa>
although if you've gone out-of-bounds.. you've gone out of bounds and IDK that it's my job to save you
<alyssa>
but I don't.. feel good about this
yogesh_m1 has quit [Ping timeout: 480 seconds]
vedranm has joined #dri-devel
<dj-death>
pendingchaos: I found that 60776f87c38f69507d60591b46b3ea2efba8e188 fixed the issue, but sounds more like a workaround :/
ellyq_ has quit []
ellyq has joined #dri-devel
lensesonthere has joined #dri-devel
<dj-death>
pendingchaos: do you think that endless loop can be removed?
<dj-death>
pendingchaos: because opt_dead_cf is doing that later
<dj-death>
pendingchaos: and that sets all hell loose
<dj-death>
starting to generate phis to go into extract_u16 src1
<glehmann>
yeah extract_u* is kind of a hack
<dj-death>
what's the proper thing?
<glehmann>
it shouldn't use a ssa def for the source that's required to be constant, but alu instructions can't have something like the intrinisic indices
mbrost has joined #dri-devel
<dj-death>
glehmann: I see, I agree
<glehmann>
I guess as long as extract works the way it does rn, nir_repair_ssa needs to rematerialize constants instead of creating phi(const, undef)
<dj-death>
I think the root of my issue is really dropping the empty loop
<glehmann>
dropping an empty loop should be valid
<dj-death>
shouldn't just hang?
<dj-death>
an empty loop with a break, sure
<dj-death>
but without...
<glehmann>
infinity loops are undefined behavior
<glehmann>
so we should be able to remove them
<glehmann>
*execution of an infinity loop is undefined behavior, the shader is still valid if that else is always skipped afaiu
<lensesonthere>
So AMD/ARM/Intel never used bus entropy encodings , because... (you can see how immediates get encoded) PCIe has some encoding however. 8b10b I did not have time to look what means pci emulation path, but it is very likely that there should be hardware encoder for pci buses, and emul does encode the stuff on cpu. But it's safe bet that Cornell pdf has never materialized to commercial
<lensesonthere>
commodity hw. So what say is that i know how to do it with quite little time from sw side quite surely now. And did you want to ask was that tough work what i did!! Very very is answer, you are not superiror to me, such patches as you do i could do every day, but there is no point in that.
Duke`` has quit [Ping timeout: 480 seconds]
karenw has joined #dri-devel
<DemiMarie>
glehmann: there needs to be a way for WebGL/WebGPU/etc to ensure that there is no undefined behavior in the code generated, and preventing detection of infinite loops seems very hard.
<glehmann>
well then webgpu needs to solve the halting problem
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<agd5f>
has anyone else run into issues with cross compiles with 6.12-rc6? Something seems to have changed between -rc5 and -rc6. Seems to be something related to libssl
<agd5f>
used to work with a 64 bit libssl, but now it seems to require a 32 bit one?
<dj-death>
glehmann: was 60776f87c38f69507d60591b46b3ea2efba8e188 a way to deal with those invalid cases?
<DemiMarie>
glehmann: the point is that web APIs are never allowed to have undefined behavior, end of story.
<DemiMarie>
otherwise it is a security vulnerability
<DemiMarie>
I believe that an asm block is inserted when generating Metal.
<DemiMarie>
the solution is to have a way to ensure that infinite loops are well-defined
<DemiMarie>
where “well-defined” explicitly includes VK_ERROR_DEVICE_LOST but not e.g. out-of-bounds accesses
<DemiMarie>
If this is not possible then WebGL and WebGPU would be impossible to correctly implement on top of Vulkan.
<glehmann>
dj-death: that commit was intended to be an optimization, but it will remove all phis that are problematic for extract_. Definitely doesn't feel right to rely on it for correctness tho
<DemiMarie>
The web platform has a lot of black and white security invariants.
<DemiMarie>
glehmann: what should webgpu do instead?
<glehmann>
I have no idea, I try to avoid it at all cost
<dj-death>
glehmann: yeah... guessing ACO would be sensitive to that too
<glehmann>
yes, this isn't intel specific in any way
<glehmann>
requiring ssa def source to be constant is fundamentally broken imo, but it's also hard to fix the existing cases in NIR
<dj-death>
yeah
<dj-death>
a nightmare
<dj-death>
I guess modifications should ensure we can fallback to direct const sources
<dj-death>
well no
<dj-death>
because reverting 60776f87c38f69507d60591b46b3ea2efba8e188 brings back the issue
<dj-death>
I thought maybe copy-prop would be enough :(
davispuh has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
lensesonthere has quit [Ping timeout: 480 seconds]