davidlt has quit [Remote host closed the connection]
vstehle has joined #panfrost
marcodiego has quit [Quit: Leaving]
NeuroScr_ has quit [Quit: NeuroScr_]
jernej has joined #panfrost
somy has joined #panfrost
megi has joined #panfrost
pH5 has joined #panfrost
vstehle has quit [Remote host closed the connection]
TheCycoTWO has quit [*.net *.split]
_whitelogger has joined #panfrost
raster has joined #panfrost
adjtm_ has quit [Ping timeout: 245 seconds]
chewitt has quit [Quit: Adios!]
_whitelogger has joined #panfrost
adjtm_ has joined #panfrost
Kwiboo has quit [Quit: .]
Kwiboo has joined #panfrost
narmstrong has quit [Remote host closed the connection]
narmstrong has joined #panfrost
<bbrezillon>
robher, alyssa: tomeu suggested that I start looking at the SAME_VA feature (CPU/GPU address space sharing), is this something you already looked at?
<bbrezillon>
also, do you have examples of use cases for that? (I see it's useful for OpenCL SVM stuff but was wondering if there was any other potential users)
Elpaulo1 has joined #panfrost
Elpaulo has quit [Ping timeout: 245 seconds]
Elpaulo1 is now known as Elpaulo
<tomeu>
bbrezillon: not sure if SAME_VA is related, but what we need for vulkan is that userspace is able to allocate virtual addresses
<tomeu>
regarding what is needed from the kernel, I guess you can look at how v3d and fdo do it
<bbrezillon>
tomeu: hm, I'm not sure yet, but IIUC mali_kbase is more restrictive => the GPU and CPU VA are the same
<bbrezillon>
pH5: thanks for the link
<tomeu>
yeah, I think that Arm's OpenCL supports SVM on some GPUs
<bbrezillon>
this being said, it doesn't seem to be a HW restriction
afaerber has quit [Quit: Leaving]
<robher>
bbrezillon: there's been some discussion about it on the list between Steven and me.
<robher>
bbrezillon: the h/w restriction is how to support it on GPUs with less VA size than the CPU.
<robher>
Neither fdo nor v3d support this.
<tomeu>
robher: don't support SAME_VA on armhf?
<robher>
tomeu: armhf is an easy case. It's 64-bit userspace with a 32-bit GPU VA that's the problem. T720 IIRC is one.
<tomeu>
ah, of course
<bbrezillon>
robher: I guess there's no way to restrict the mmap() address space
<robher>
Implementation wise, I tend to think we should copy kbase and set the GPU VA when a BO is mmapped. If we set the GPU VA up front, we should use the kernel's address range as that won't overlap with userspace addresses.
<robher>
bbrezillon: I don't know. That was something to investigate. I would think you can in mmap calls.
<bbrezillon>
robher: ok, the other question is, is there a strong reason to keep this GPU_VA = CPU_VA limitation in our uAPI ?
<bbrezillon>
I mean, userspace can pass the CPU VA if it needs those VA to match, and we can reject the operation if the passed VA is outside the supported VA range
<bbrezillon>
that still leaves the problem of restricting the CPU VA address space when mmap() is called on BO that's expected to have matching GPU and CPU VA
* bbrezillon
needs to look at the fdo and v3d implems
chewitt has joined #panfrost
<robher>
bbrezillon: those don't have an implementation...
<bbrezillon>
robher: I wonder what tomeu was referring to when he suggested to look at how fdo and v3d do it
<bbrezillon>
?
<bbrezillon>
and indeed, I see nothing like that in v3d
<tomeu>
I thought they did
<robher>
must have been assuming they do already...
<bbrezillon>
so it looks like the only driver that's (soon) implementing something close to what we want is etnaviv
<tomeu>
I remember seeing some code in mesa related to this
<tomeu>
maybe only iris?
<robher>
bbrezillon: lima does I think.
<robher>
and amd
<robher>
both of those just have an ioctl to set the GPU VA and do all the address space management in userspace (i.e. implement drm_mm there).
megi has quit [Quit: WeeChat 2.5]
<bbrezillon>
robher: I see
<bbrezillon>
robher: actually, I can't find the lima ioctl doing that in drm-misc-next
<bbrezillon>
there's DRM_IOCTL_LIMA_GEM_INFO which returns the GPU VA
<bbrezillon>
but nothing to set it AFAICT
<robher>
bbrezillon: must have gotten removed in review. I remember discussing that...
warpme_ has joined #panfrost
warpme_ has quit [Quit: warpme_]
warpme_ has joined #panfrost
<alyssa>
Okay what actually am I missing
* alyssa
has been trying to debug MRT for an hour now
<alyssa>
cyrozap: Nice :)
warpme_ has quit [Quit: warpme_]
<alyssa>
robher: Wait a minute. There's such a thing as a 32-bit GPU VA?
<alyssa>
That.... changes things....
<robher>
alyssa: I believe the address size is still 64-bits, but only 31 or 32 address bits are present.
<alyssa>
Ook.
<tomeu>
hehe
<alyssa>
tomeu: What was the result of your OpenCL experiment? :P
<tomeu>
alyssa: my main finding is that it will be all great when ML people agree to stop reinventing build systems and distros
<alyssa>
:p
<tomeu>
I was able to run a simple sanity check test from plaidml on clover after I hacked up support for lowering shared variables with explicit io
<alyssa>
Ah?
<alyssa>
tomeu: (Was this with the SSBO branch?)
<EmilKarlson>
Master Lizard people?
<alyssa>
EmilKarlson: sssss
<tomeu>
I wanted to try to do some inference next, but realized that half of the python files are out of sync with the other half, because of finding #1
<tomeu>
alyssa: ah no, this is on tegra with novueau
<alyssa>
Oh :-(
<tomeu>
so I'm now waiting for pip to rebuild all the python modules that debian had already installed...
<tomeu>
alyssa: should I try with panfrost? should be quite easy
<alyssa>
tomeu: Probably won't work
<alyssa>
But once I land SSBOs, might be fun
<alyssa>
dEQP-GLES31 compute shader tests are starting to pass on that branch
<alyssa>
tomeu: Oh this is interesting
<alyssa>
I accidentally stumbled upon a mode where the hw does wallpapering itself.
<alyssa>
Which is dramatically faster than us doing it
<alyssa>
Except it's slightly broken
<tomeu>
hehe
<alyssa>
tomeu: Chicken bit?
<alyssa>
tomeu: Thing is, it's just -so- close to being functional
<alyssa>
shadeslayer: Could you figure out which BO is being unreferenced?
<alyssa>
That way we can figure out where we messed up the refcnt.
<alyssa>
reference count
<shadeslayer>
alyssa: I think I'd have to rebuild without optimization to get that
<alyssa>
shadeslayer: Hm, maybe try sprinkling in some prints to bo_reference/unreference and create_resource?
<alyssa>
Try to match the addresses of the BO with what they do, etc
<shadeslayer>
I'm re compiling without optimization :)
afaerber has joined #panfrost
<shadeslayer>
oh lovely, now I get asserts for safe_iterator ../src/panfrost/midgard/midgard_schedule.c:578:schedule_block: Assertion `ins == __next && "use _safe iterator"' failed.