bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
iyes has joined #asahi-gpu
LinuxM1 has quit [Quit: Leaving]
<iyes>
Hello. :) I'd like to try to contribute. I have a decent understanding of graphics APIs (from a user POV, not an implementer POV), hardware (though more CPUs than GPUs), and I am good at Rust and C (though my C is ... rusty ;) ). Never worked on a gpu driver before.
<iyes>
I have an Asahi (the ALARM based, not Fedora based) install on a M1 Pro MBP, which I don't daily drive but occasionally dual boot into. I don't mind trashing / littering over that OS install. Any advice for how I should set up my workflow for mesa dev?
<iyes>
How does one iterate on a gpu driver? How can I easily test changes? Also, where can I find documentation?
cr1901 has quit [Quit: Leaving]
iyes has quit [Quit: This computer has gone to sleep]
Method_ has joined #asahi-gpu
Method has quit [Ping timeout: 480 seconds]
cr1901 has joined #asahi-gpu
iyes has joined #asahi-gpu
chadmed has quit [Ping timeout: 480 seconds]
<iyes>
Also, out of curiosity, has the needed RE work to support cubemap array textures been done? Or is that still blocked on unknowns about the hardware?
<jannau>
iyes: fast iterating on the rust kernel driver works with a development + test machine using m1n1's lightweight hypervisor
<jannau>
the mesa driver OpenGL and vulkan drivers (C) can be tested on the development system
<jannau>
`meson devenv` sets the environment up to test drivers from the dev tree
<jannau>
foccus is slowly shifting but I think the main missing features for opengl (es) are not good first task
<iyes>
Yea ofc, for someone unfamiliar with the codebase, need easier things to get into the flow of things. :)
<iyes>
But speaking of which, (very naive question) how much work does it generally take to implement a GL extension, assuming the needed knowledge of the hardware is available / you aren't blocked on not understanding the hardware?
<iyes>
I mean, ofc it varies, some are very complex ... but let's say it is some smaller GL extension, not something huge like geometry shaders
cylm_ has joined #asahi-gpu
<iyes>
I remember alyssa said that the Asahi project started out with GL and not Vulkan, because the existing frameworks/infra in mesa made it easy to implement GL, as it takes care of the peculiarities of the API and the hardware agnostic stuff
<iyes>
And what about general mesa developer documentation?
<jannau>
another reason for starting with opengl was that it clearly would have a driver which can be used
<iyes>
Where can I find general (non-asahi-specific) docs to help me learn and navigate around mesa's codebase, architecture, apis, dev workflows, etc?
<_jannau__>
I don't know. you could ask in #dri-devel
<iyes>
Okay thanks!
<lina>
alyssa: Good news! I figured out what the helper program is for.
<lina>
Bad news: It's actually setting up the stacks, so we get to implement all that if we want spilling ^^;;
<lina>
That suddenly makes a lot of sense though...
iyes has quit [Quit: This computer has gone to sleep]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
iyes has quit [Ping timeout: 480 seconds]
<alyssa>
lina: ughhhhh :(
<alyssa>
I thought the helper program was only for compute though, what sets up the stacks for graphics?
iyes has joined #asahi-gpu
<lina>
alyssa: The helper program. It's for all three.
<alyssa>
Oh, interesting
<alyssa>
how did we never notice it before?
<lina>
I did see it when bringing up G14X but I didn't make the connection that it was the same helper as always...
<alyssa>
ahhhhh
<lina>
Kernel update in the usual branch, agx/uapi-updates-202308 on top of your layered branch but it's just one commit you can cherry-pick
<alyssa>
:+1:
<lina>
Layered rendering is fixed, needed a kernel bugfix (missing one magic buffer) + all the strides in the UAPI for Z/S
<alyssa>
nice
<lina>
All the helper programs are exposed in the UAPI now too, you just need to implement it ^^
<alyssa>
Me?!
<alyssa>
:p
<lina>
Also threw in the bindless sampler thing
<lina>
And some mystery "no preemption" (maybe?) flag that would be nice to test
<lina>
Seemed related to the helper program for compute but unclear
<alyssa>
Wheeee
<lina>
I also looked at mesh shaders, it's what you said - no magic CDM in VDM thing, just discrete compute...
<lina>
There is indeed a magic VA range for dynamic allocation and the messages you'd expect back&forth plus some management structures I didn't look at yet
<lina>
And I also figured out stream call/return, I can push some decoder stuff for that, since they use that.
<lina>
Apparently the VDM barrier command is also return??
<alyssa>
12:28 lina | And I also figured out stream call/return, I can push some decoder stuff for that, since they use that.
<alyssa>
:+1:
<alyssa>
12:28 lina | Apparently the VDM barrier command is also return??
<alyssa>
It's a VDM catch-all command
<alyssa>
If you don't set any bits, it's a VDM nop :~)
iyes has quit [Ping timeout: 480 seconds]
Whistler_ has joined #asahi-gpu
<lina>
alyssa: MR for the decoder stuff opened, I'll let you figure out when we merge the UAPI stuff but we might want to do it soonish? If you can validate the bindless sampler stuff, layered rendering is tested and the helper program thing is pretty obvious.
<lina>
For the helper program, if you can help get the mystery instructions into the backend I can try to implement the logic (I'm leaving all the buffers up to userspace, unlike macOS, so we can use our own structures/layouts, we don't have to copy theirs)
<alyssa>
alright
<lina>
I already took a good look at how that works so at this point I think I only need the magic instructions/SRs to make it do something useful
<alyssa>
what's the big picture of how that program is supposed to work?
<lina>
My guess given what we saw now is that it maps 1-4 blocks of stack space, each of which is encoded in a particular way (size/addr compressed together). It receives a structure that is basically an array of those pointers for each threadgroup(?) for each core that can be active at the same time, and indexes into it. There's also a core mapping table, since presumably the core IDs the shaders get are "raw"
<lina>
but not all cores exist in all GPUs so you want to remap to avoid wasting table space.
<lina>
(We already have the core table in the UAPI so the driver has what it needs to do that)
<alyssa>
Interesting... ok
<alyssa>
Bizarre mechanism
<alyssa>
So many simpler ways they could've done this, lol
<lina>
TBH, the core mapping thing is overkill... The table is already a table of pointers to stack blocks, so a dummy core is just 16 bytes * max_active_threadgroups which isn't thaat much wasted space.
<alyssa>
right..
<alyssa>
I wonder how this works in vertex shaders
<alyssa>
where there's no natural "threadgroup"
<alyssa>
(unlike both compute and fragment)
iyes has joined #asahi-gpu
<lina>
alyssa: In my single test it was 61 per core for vertex, and for compute that was capped at some max based on local memory utilization etc, so it's probably just "the max occupancy" for vertex.
<alyssa>
:+1:
<iyes>
Hi alyssa ! Re: my earlier messages, do you have anything to add to what jannau said earlier? About places I could start, to get into contributing to mesa/asahi?
karolherbst has quit [Quit: Konversation terminated!]
<iyes>
Today I mostly wanted to gather a reading list for myself. For now, I'll be getting through the stuff I was linked, and doing some exploring. I don't know when I'll actually have the time to dive into code more seriously. When I am actually ready to work on something, I'll let you all know. :)
<lina>
128: e2023004 mov_imm r0h.cache, 1072
<lina>
Any chance that is disassembled wrong?
<alyssa>
almost certainly not
<alyssa>
why?
<lina>
That imm doesn't make sense to me... (looking at the helper)
<alyssa>
llvm-objcopy: error: Link field value 25 in section .rela.dyn is not a symbol table
<alyssa>
uh
<alyssa>
I said LLVM=0 :V
Whistler_ has quit []
zane has quit [Quit: WeeChat 4.0.3]
bcrumb has joined #asahi-gpu
bcrumb has quit []
jeisom has joined #asahi-gpu
karolherbst has quit [Quit: Konversation terminated!]
<i509vcb>
alyssa: I looked at other drivers and now I realize I need to lay out a case why every driver except for nvk and radv is implementing vkGetMemoryFdPropertiesKHR wrong
<alyssa>
i509vcb: Woo!
iyes has quit [Ping timeout: 480 seconds]
<alyssa>
ella-0: i509vcb: Lina has bumped the UAPI for some important new stuff.. let me know when I should do the AGXV rebase
<alyssa>
(which will require you to bump your kernel at the same time)
iyes has joined #asahi-gpu
<alyssa>
Are you running asahi distro kernels, or building your own?
<alyssa>
(If the former, I suppose I can rebase AGXV exactly when we release the new kernel)
<i509vcb>
I'm running the asahi distro kernels, my stuff is mainly in memory land so feel free to bump if ella is okay with it
<i509vcb>
well assuming memory didn't just to carpet bombed
<i509vcb>
/s/to/get
<_jannau__>
you won't be able to use the rebased agxv with the current kernel
<i509vcb>
err yeah agxv rebase with new kernel release
<i509vcb>
Sometimes I don't read enough if the last message
<alyssa>
ok, that's fine
as400 has quit [Ping timeout: 480 seconds]
<i509vcb>
Before I go over to #dri-devel to try to figure out which implementations are wrong, I'll try to explain what I think is wrong with v3dv and co in that function
<alyssa>
I'll bump asahi/main today, and if all goes well, we'll push out the new kernel to arch/fedora users tomorrow(?) and then once the new kernel is pushed out I'll rebase AGXV
iyes has quit [Ping timeout: 480 seconds]
<i509vcb>
So vkGetMemoryFdPropertiesKHR is used primarily used for determining the memory type of a dmabuf you are importing.
as400 has joined #asahi-gpu
<i509vcb>
however a lot of implementations (v3dv, tu, pvr, anv, hasvk) return VK_SUCCESS regardless of the file descriptor you pass into that function
<i509vcb>
You could pass -1 (invalid fd) and it technically is ok with that function
<i509vcb>
Also this means you can do something like
<i509vcb>
fd = open("~/Pictures/ferris.txt")
<i509vcb>
vkGetMemoryFdPropertiesKHR(device, fd)
<i509vcb>
which seems bizzare since those cannot be prime fds which are what vulkan drivers typically consume with the dma buf handle type
<i509vcb>
that little pseudocode snippet should be returning VK_ERROR_INVALID_EXTERNAL_HANDLE since a file is definitely not a prime fd
<i509vcb>
radv and nvk will return an error correctly
<i509vcb>
However here's the kicker
as400 has quit [Remote host closed the connection]
<i509vcb>
The spec doesn't actually explicitly allow or forbid this
<i509vcb>
So the question is, which is right
<i509vcb>
(radv and nvk act correctly here since a prime fd could be from one of a few memory types and the memory type bits need to be set accordingly)
as400 has joined #asahi-gpu
iyes has joined #asahi-gpu
possiblemeatball has joined #asahi-gpu
karolherbst has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
iyes has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
<i509vcb>
seems like what v3dv is doing is fine given that the spec seems to says it's undefined behavior to pass an invalid fd
iyes has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
iyes has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
iyes has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
iyes has joined #asahi-gpu
iyes has quit [Ping timeout: 480 seconds]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
possiblemeatball has quit [Quit: Quit]
possiblemeatball has joined #asahi-gpu
jeisom has quit [Quit: Leaving]
jeisom has joined #asahi-gpu
lena6 has joined #asahi-gpu
karolherbst_ has joined #asahi-gpu
karolherbst has quit [Ping timeout: 480 seconds]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-gpu
karolherbst_ has quit [Remote host closed the connection]
karolherbst has joined #asahi-gpu
<i509vcb>
the fun of dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic, have to effectively rewrite agxv_physical_device_try_create to make the solution bearable
zalyx0 has quit [Quit: later alligator]
zalyx0 has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cylm_ has quit [Ping timeout: 480 seconds]
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #asahi-gpu
ourdumbfuture has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
stipa is now known as Guest9096
stipa has joined #asahi-gpu
<alyssa>
uhoh
Guest9096 has quit [Ping timeout: 480 seconds]
<ella-0>
alyssa: I'm running my own kernels but go ahead and rebase
<alyssa>
ella-0: ack
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
possiblemeatball has quit [Quit: Quit]
<i509vcb>
agxv_physical_device_try_create really makes me yearn for Rust's Result
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]