<lina>
The firmware interface side is starting to come together, I just need to implement the tile buffer management stuff, some misc structures for event delivery/etc, and then just write the code to fill in the big vert/frag job structures and plug it into a DRM ioctl.
<HdkR>
I'll need to take a peek at that DRM interface since I'll need to wrap it for FEX-Emu
<HdkR>
For the 32-bit emulation primarily
sdutt has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
<lina>
HdkR: The UAPI isn't anywhere near done yet, the driver doesn't have any right now and the old demo one in mesa is likely to be completely redone.
<lina>
Also the driver doesn't support 4K pages yet so...
<lina>
I don't know how to get the drm_shmem_helper to allocate 16K aligned pages on 4K systems, that's something I'm leaving for later...
<HdkR>
That's fine, I can at least keep it on my radar and run it through the FEX-Emu packing verifier
<lina>
Are there any particular requirements you have for the UAPI? I guess for 32-bit compat the pointer sizes would change, anything else?
<lina>
Most of it is going to be generic DRM stuff, and GPU VAs are always 64 bits, so there's probably not a lot that would change for 32-bit builds
<HdkR>
Since I push 32-bit users over to 64-bit if the pointers use a fixed size it's actually better since I don't need to do as much struct repacking
<lina>
The GPU pointers use a fixed size, the CPU pointers would change I think (unless there's some kind of standard for them not to? I don't know how 32-bit compat works)
<lina>
Though nobody will have tested the mesa code as a 32-bit build (we can't, really, unless we use my weird python driver on x86-32?) so I suspect you're going to have a fun time debugging 32-bit issues there...
<HdkR>
I've been building the 32-bit userspace for a while now, just haven't run it of course
<lina>
Yeah, but nobody has tested the AGX driver on 32-bit and we can't on ARM
<HdkR>
I'm mostly thinking that since you won't have any 32-bit user other than FEX, if the DRM uAPI just uses 64-bit for pointers it'll probably be fine. Eats a bit of previous 32-bit memory space, but eh
<HdkR>
s/previous/precious
<HdkR>
Which is what most DRM users do, just use u64 for pointers
<lina>
I don't know if forcing CPU pointers to 64 bits is a thing... if there are other uAPIs that do that I'm all for it, but I don't know if there's precedent for that
<lina>
(note: CPU pointers, which there really aren't that many of in the uAPI)
<HdkR>
Right, I'm saying that if there is a CPU pointer in the uapi, just fix to 64-bit. :)
<lina>
Right, but then it can't actually be a pointer type!
<HdkR>
You're right, would need to do some type punning there
<lina>
I'm saying if there's existing kernel typedefs/machinery/whatever to do this then I have no issue with it, but I'm not going to be the first uAPI designer to use this trick unless someone else approves ^^
<lina>
For reference though, I think my demo uAPI has zero userspace pointers...
<HdkR>
No machinary for the type punning, but as an example, V3D uses u64 for pointers
<lina>
It's all just straight ioctls and mapping memory goes through mmap
<lina>
V3D uses u64 for userspace pointers?
<lina>
Not GPU pointers?
<HdkR>
I believe this "Pointer to an array of ioctl extensions" is pure CPU
<lina>
Interesting, it does
<lina>
u64_to_user_ptr()
<HdkR>
Fancy
<lina>
Ah, I found the docs for this, okay. Looks like it's a thing and encouraged!
<lina>
I'll take it into account then, thanks for letting me know ^^
<HdkR>
Nice. I didn't know if it was encouraged
<lina>
It makes sense, since otherwise you need 32-bit compat wrappers in the kernel
<lina>
I never knew how those worked, looks like the answer is "by not needing them if you can help it"
<HdkR>
32-bit linked list repacking is the bain of our existance after all
<HdkR>
Looking at Vulkan over here...
<lina>
You probably won't have to worry about this then, other than trying it on 32-bit once the rest of the story is there (either 4K emulation in FEX or 4K support in my driver...) to make sure I didn't miss anything silly.
<lina>
We have plenty of time to fix the uAPI before it's upstreamed anyway. Ideally FEX would get *some* 4K support before then so you can at least smoke test it ^^ (easier than all the pain with 4K kernels right now...)
<lina>
*4K emu
<HdkR>
Will cross that bridge when it comes up. No need to rush it after all
<lina>
I'm going to be talking about uAPI design with jekstrand next week, so hopefully I can start coming up with a production design after that
<vsyrjala>
apparently we all need to switch to u256_to_userptr() soon
mszyprow has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
danvet has joined #dri-devel
Daanct12 has joined #dri-devel
Haaninjo has joined #dri-devel
rasterman has joined #dri-devel
Surkow|laptop has joined #dri-devel
lemonzest has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
Daaanct12 has joined #dri-devel
Daanct12 has quit [Read error: No route to host]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
nchery has quit [Remote host closed the connection]
<karolherbst>
guess I'll ignore llvmpipe fails for now on llvm-15 :)
<RSpliet>
karolherbst: pseudo-random question perhaps: have you threading fixes already made it into Fedora 36 updates?
<karolherbst>
no
<karolherbst>
also not sure if we really want to backport those as they could break random things.. but maybe we should. Fedora people are aware of that so I'd like them to do the decision there
<RSpliet>
Boo ;-P Nah fair, I noticed it also didn't make it for the 22.2 cut-off? (Deliberately?)
Lucretia has quit []
<karolherbst>
they are not even cc stable
<RSpliet>
I don't know the next time I have time, but I wouldn't mind giving them a spin on my machine if there's RPMs for them. Think I should save that experiment for after my holidays though, which I think is after f37 is released :-)
<RSpliet>
What does cc-stable mean? Is this a compiler determinism thing?
Lucretia has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<karolherbst>
RSpliet: you put it on patches so they get backported automatically :P
<karolherbst>
ehh.. seems like I messed up creating the CSO upfront and now I hit a user after free inside iris :(
<karolherbst>
looks like an iris bug though :)
kts has joined #dri-devel
<jenatali>
karolherbst: not yet
<karolherbst>
ehh looks like iris doesn't support shareable shaders even though it's advertized.. or I use it wrongly
<karolherbst>
yeah... seems like if I create and delete the CSO from thread a, but only ever bind it on thread b, then iris crashes sooner or later
<karolherbst>
s/thread/context/
eloy_ has quit [Ping timeout: 480 seconds]
eloy_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
eloy_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
luc4 has joined #dri-devel
eloy_ has joined #dri-devel
luc4 has quit [Read error: Connection reset by peer]
luc4 has joined #dri-devel
alanc-away has quit []
alanc has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
pcercuei has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
heat has joined #dri-devel
Danct12 has joined #dri-devel
gouchi has joined #dri-devel
mszyprow has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
kem has joined #dri-devel
<javierm>
airlied: thanks, I'll take a look
mbrost has joined #dri-devel
<karolherbst>
okay.. found a real bug in iris :) if between launch_grid only work_dim changes it doesn't update the dimension
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
fxkamd has quit []
lemonzest has quit [Quit: WeeChat 3.5]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
pa has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
pa- has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
jewins has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
jewins1 has joined #dri-devel
jewins has quit [Quit: jewins]
mszyprow has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
<javierm>
daniels: I tried starting weston with --shell=kiosk-shell.so as you suggested but I only get a black screen on my VM, foot starts but I don't see it either