<airlied>
JoshuaAshton: ^ just not integrated with the radv encode yet
mbrost has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
Leopold_ has joined #dri-devel
itoral has joined #dri-devel
Company has quit [Quit: Leaving]
yyds has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
flynnjiang1 has joined #dri-devel
yyds has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
yyds has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
tzimmermann has joined #dri-devel
flynnjiang1 has quit [Read error: Connection reset by peer]
yyds has joined #dri-devel
kts has joined #dri-devel
mszyprow has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
mszyprow_ has joined #dri-devel
shoragan has quit [Quit: quit]
sima has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Leopold has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
glennk has joined #dri-devel
pH5 has quit [Remote host closed the connection]
Leopold has quit [Remote host closed the connection]
crabbedhaloablut has joined #dri-devel
Leopold has joined #dri-devel
fab has quit [Quit: fab]
Leopold has quit [Remote host closed the connection]
<ity>
Re: "most graphics people are employed by some company so not much happens on weekends" hmm, fair. I guess I should wait today, then if nothing happens who should I nag?
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<karolherbst>
ity: we should probably ask them to enable merge requests on that repo tho...
YuGiOhJCJ has joined #dri-devel
<ity>
Ahaha yea, that sounds like a good idea. I took this mostly as a an opportunity to learn how to contribute by mail, and thought that a minor patch for an off-by-one would be good.
<karolherbst>
my opinion is that nobody should go through that pain ever again, but some disagree... :D
<ity>
By the way, since I am already here, can I ask questions about the graphics stack? I have been attempting to figure it out by using strace, gdb & the mesa source tree, but there are quite a few things that I am having trouble figuring out. I am attempting to try to learn how the DRM API exposed by the i915 driver works
<karolherbst>
well.. depends if you are more interested in the displaying/wsi bits (kms) or rendering
<ity>
Both actually :D Though for now I guess the render engine is fine
<ity>
I was stracing a simple VK app I wrote
<karolherbst>
yeah.. though if you are interested more in rendering than strace won't really catch those bits as it all happens within command buffers and jobs submitted to the GPU, rather than ioctls (besides the one to submit jobs)
jfalempe has joined #dri-devel
<karolherbst>
(and memory allocation)
<ity>
Yea, I guess so. I have been trying to at least catch the API that creates & submits the buffers
<ity>
I think it's the GEM?
<ity>
But what is the Aperture? I have been unable to find that out
<ity>
There is also a magic QUERY that seems to only be executed once? With null null no less, how does the mesa driver get info from it?
<karolherbst>
yeah, no idea about specifics to intel (including the terms)
<ity>
Ah, I see, which system are you familiar with?
<ity>
I have been mostly studying intel as they have PRMs and an iGPU seemed like it'd be easier than a dGPU
<ity>
Though I did take a generic look around the mesa tree (I even have it on my phone so I can read it on the go :D) and took a small peek at radv
frieder has joined #dri-devel
fab has joined #dri-devel
<karolherbst>
yeah.. not sure if we have a central place where we could point to proper docs, but there are some blog posts around which might explain a bit
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<ity>
Yea the docs are pretty sparse. I also have no idea which part of the tree ends up in what library... Eg where does the generic libdrm come from? Why does libdrm_intel exist but is never loaded? Why is libdrm_amdgpu loaded when the kernel amdgpu driver is not loaded? What is the diff between libvulkan_intel and libvulkan_intel_hasvk? - If you have any blog posts or anything, I
<ity>
would gladly give them a read!
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
<karolherbst>
maybe we should have a list of blogs or something 🙃
<karolherbst>
I wonder if anybody did a series like that in the past
<karolherbst>
uhm..
<karolherbst>
more recent past
xroumegue has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
mvlad has joined #dri-devel
xroumegue has joined #dri-devel
Leopold has joined #dri-devel
pcercuei has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
<mareko>
ity: AMD dGPUs and APUs use exactly the same hw programming
<mareko>
in Mesa
<mareko>
ity: they work like Vulkan, one difference is that command buffers are built inside buffer objects using a hw-specific format of commands, and then the GPU is given a GPU pointer to that buffer object and executes it
<mareko>
ity: shaders are also written into buffer objects; the goal of Mesa is to prepare the buffer objects with GPU commands, states, and shaders, and tell the GPU to execute them
<ity>
Ah, iirc the SPV gets tranlated to NIH which then gets translated to the arch-specific ISA right? That's just the high-level overview though, I am not sure what format the buffers have, which DRM ioctl needs to be sent to make & upload a buffer, what to send to execute a buffer, retrieve the data... I will def give a read to the blog & references page though!
<karolherbst>
ohh, cool, didn't know
<sima>
ity, it's a bit more gerenal gpu stack, but might have some of the things you want to learn about too
yyds has quit [Remote host closed the connection]
<sima>
karolherbst, maybe similar list more focused on mesa in mesa docs might be good?
<sima>
airlied, should we have your new nouveau talk in there for an overview of modern render drm driver maybe?
<ity>
Seems like a cool list! I'll def check it out aahah, though I have a few specific questions for anv (I think) that are bugging me for a while now
<sima>
ity, #intel-3d for anv questions might be better than here
<ity>
OOH, oki!
<javierm>
sima: I think that the excellent recent articles from tzimmermann in lwn.net (intro to gfx part 1 and 2) would be good to have reference there too
<karolherbst>
sima: might also makes sense to just list all blogs of all drm/mesa devs :D
<ity>
That sounds good actually ahah, I'd love to give it a read!
<ity>
The blog post seems a bit dated, it references X & OpenGL
<tzimmermann>
javierm, ah yeah. i wanted to send a PR to add them to the docs. thanks for reminding me
<javierm>
tzimmermann: you are welcome, and thanks to you for writing those :)
<sima>
tzimmermann, javierm yeah definitely want to add those for sure
<sima>
I was more wondering about render stuff since we have a bit a lack of good overviews there, and airlied's recent nouveau revival talk is probably the closest
<sima>
least also because ttm and drm/sched are the two clearly still underdocumented areas at the kernel-doc level too :-/
<sima>
tzimmermann, if you type the patch rn pls also pastebin here for ity
<sima>
ity, opengl es is still very much the standard on smaller/embedded systems
<sima>
ity, if your apps allocate more memory than you have
<sima>
gpu memory swapout (well nowadays in-place compression with zswap really) works much better with the gl userspace than vk
<ity>
Ah, why does it work better with GL?
<sima>
I've heard some people working on it, but until that's sorted gl tends to be better on really constrained systems still
<sima>
yeah
<sima>
otoh X driving drm directly is firmly outdated everywhere, more so on embedded :-P
<ity>
Interesting. I am mostly focusing on VK as it seemed like an easier path towards the inner details of the drivers, OpenGL is somewhat complex
yyds has joined #dri-devel
<ity>
X doesn't modeset? Or do you mean it got replaced by WL?
<karolherbst>
sima: I guess the reason for that is, that in vulkan we don't want to know what buffers are used in a job, so the kenrel doesn't really know what is safe to page out or not?
<sima>
yeah X directly doing the modesetting is legacy, wayland compositor (or android's surfaceflinger) took this over
<sima>
with maybe Xwayland for backwards compat
<sima>
karolherbst, yeah so you need to swap the entire job essentially
<sima>
which means disastrous amounts of stalling
<karolherbst>
yeah..
<karolherbst>
it's not great
<sima>
so need to add some notion of working set to vk, but how
<karolherbst>
even with VM_BIND and all the fancy new submission ioctls, we still might need a "I know these bos are used for sure" list of bos somewhere...
<karolherbst>
dunno
<ity>
Is that internal driver state? Or smth inherent to the spec
<sima>
and how exactly do you need to sync on this
<sima>
karolherbst, yeah exactly
<sima>
or well inverse, "I know these big bos here are not used, you might want to swap them out"
<karolherbst>
the legacy ioctls (used by GL) generally have this...
<karolherbst>
sima: maybe both
<karolherbst>
but like
<ity>
Bos? Is that another 3 letter acronym
<sima>
but needs the full set of in/out fences on a binding queue
<karolherbst>
if you have a shader and use bda all bets are off anyway
<karolherbst>
well.. kinda
<sima>
karolherbst, yours sounds more like bo priorities as in "try to put these into vram"
<pq>
BO = buffer object
<sima>
which imo is orthogonal (but another gap compared to gl)
<karolherbst>
I think we'll end up with a priority system here anyway
<karolherbst>
like
<sima>
karolherbst, yeah
<ity>
OOH so just a plural of buffer object
<karolherbst>
like
<sima>
ity, yup
<karolherbst>
NV gpu can have some type of memory in VRAM or system RAM for rendering
<karolherbst>
but some things have to stay in VRAM
<ity>
I am feeling really out of place ahaha, as a beginner in the low level graphics stuff
<karolherbst>
and if your job needs more memory than you have VRAM you kinda have to figure out how to make it all work
<sima>
karolherbst, yeah atm for vk we only have the "must stay in vram" info
<sima>
with gl the userspace driver can sus out "probably good idea if it's in vram too"
<karolherbst>
yeah
<karolherbst>
but who is gonna make those changes to the gl driver anyway :P
<sima>
so vk gets you a lot more random bo selection if you overcommit vram
<sima>
karolherbst, amdgpu is pretty fancy on this iirc
<karolherbst>
right
<karolherbst>
yeah.. fair
<sima>
but imo the "do I even need this mapped or ok for kernel to swap/zswap out" is orthogonal
<sima>
since vram or not is just performance, not correctness
<karolherbst>
well...
<karolherbst>
there are two parts
<karolherbst>
swapping and compressing
<karolherbst>
those are not the same things
<sima>
so I'm leaning towards making this orthogonal
<karolherbst>
like, you can swap out some bo to system memory, but what if hte GPU accesses it while it's compressed?
<sima>
yeah in the kernel it's all swapout conceptually, just different targets
<sima>
karolherbst, hence why I think this needs separate, userspace promises to not access it while it's marked as "swapout-able"
<karolherbst>
right
<sima>
and userspace probably needs to supply in/out fences to the kernel so the kernel knows how to sync it all up
<karolherbst>
and then I come around the corner with my weirdo SVM use cases :P
<sima>
yeah those are big lolz anyway
<karolherbst>
I still have to get back to it and come up with a good solution
<sima>
whereas placement priority is kinda different, no disaster if it's not in vram, but it still has to be _always_ mapped
<karolherbst>
I have solutions, none are great
<karolherbst>
right
<sima>
imo svm only really works if you have actually competent hw page faults
<sima>
before that it's tech demo at best
<karolherbst>
not necessarily
<sima>
waaaaaaayyyyyy too many funny corners it all falls apart
<karolherbst>
ehhh
<karolherbst>
not too bad
<karolherbst>
without hw page faults you have to do explicit svm allocs
<karolherbst>
and then you just map it all properly
<karolherbst>
it's all doable
<karolherbst>
I have a prototype on iris which works, it just blows up your VM
<sima>
yeah I know, I've watched people try for years by now
<sima>
"we just userptr all the things"
<karolherbst>
:P
<sima>
for an extremely load bearing value of "just"
<karolherbst>
yeah..
<karolherbst>
that's basically my current approach, there are problems with it tho
<sima>
yeah so that's the one that works great for tech demo and then hits all kinds of funny in reality
<karolherbst>
right.. kinda depends on what you use it all for
<sima>
like the oddball userptr while most everything else is just normal bo is fine
<karolherbst>
at least on iGPUs using userptr isn't all that terrible, on dGPU it all sucks
<sima>
but if everything is userptr you really need reliable page faults to paper over all the corners
<sima>
and reliable = can preempt ctx while fault is pending
<karolherbst>
like you allocate on your host VM, and then place the bo you back with that userptr at the same location, and you are basically done
<karolherbst>
problem is.. on dGPUs you have that pcie bus in the way
<sima>
even on igpu you're not done, because userptr is so much worse on anything actually dynamic or overcommit than the current vk overcommit fun
<karolherbst>
what I really need is a way to reserve host VM and map things into it when I want it to be mapped
<karolherbst>
or use actual RAM
<karolherbst>
but all dynamically
<sima>
and if you don't do actual dynamic memory and overcommit, what's the point of svm
<karolherbst>
so I can back a certain GPU/CPU VM address with either system RAM or VRAM
<sima>
because you still can't just seamlessly reuse cpu libraries who all have this as very basic assumptions
<sima>
karolherbst, mmap(NULL)
<karolherbst>
I meant dynamic for the same allocation
<karolherbst>
so I can move the content around
<sima>
yeah that needs page faults
<karolherbst>
not really
<sima>
or you just stall disastrously
<karolherbst>
you can move it ahead of dispatch
<karolherbst>
there are CL APIs which gives you hint on where the memory should be
<karolherbst>
and then you just move it
<karolherbst>
and once you dispatch, you just don't move it
<sima>
that's still a few levels less sophisticated than what I've seen people actually try to ship
<karolherbst>
intels usm ext also has very very explicit placement of memory
<karolherbst>
ohh sure, system SVM is all transparent and needs real hw pagefaults
<karolherbst>
just talked about non system SVM stuff
yyds has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]