<endrift>
I have higher priorities atm (I'm moving soon) and I don't really have the necessary expertise to do it myself without taking time to ramp up :(
BenG83 has quit [Remote host closed the connection]
stikonas has quit [Ping timeout: 252 seconds]
<HdkR>
Oh hey. I loved that the Nexus 9 did uart over the headphone port :D
maccraft123 has quit [Quit: WeeChat 2.6]
stikonas has joined #panfrost
<Lyude>
HdkR: oh wow
<Lyude>
that's clever
<Lyude>
i miss headphone ports
<HdkR>
I mean, if they gave me serial over Type-C I wouldn't complain
<HdkR>
but holy crap, getting that to emit early-kprintf sounds terrible
stikonas has quit [Remote host closed the connection]
NeuroScr has quit [Quit: NeuroScr]
<alyssa>
Is serial over type-C not a thing?
<endrift>
shoutout to that time I bricked my router and had to plug in UART to unbrick it
<endrift>
it's a good thing that uboot didn't break
BenG83 has joined #panfrost
enunes has quit [Read error: Connection reset by peer]
<HdkR>
alyssa: USB isn't really brought up early enough for significant debugging
enunes has joined #panfrost
<HdkR>
You'd probably want some USB controller that starts out in some alt-mode that is visible as serial really early
<anarsoul>
endrift: I have no experience with rk3399 either, but it's OK, I guess I'll get it working over weekend
<anarsoul>
good thing is that next weekend is long one! :)
<endrift>
I hope someone is looking at it basically
<endrift>
I think it's a known problem
<anarsoul>
well, first thing I need to get on it is u-boot with usb working to boot over NFS
<alyssa>
HdkR: Even so, 4 pins is enough for UART
<HdkR>
alyssa: Of course. The concern is making that work without breaking the USB ecosystem :P
<alyssa>
:D
nerdboy has joined #panfrost
<HdkR>
And of course bringing up the USB controller with some integrated serial mode early enough that early-kprintf actually works
<nerdboy>
is mesa-19.2.0/xorg-server-1.20.5 expected to fire up the gpu on exynos5250 chromebook with a 604 and kernel 5.4.0-rc5 ?
vstehle has quit [Ping timeout: 265 seconds]
<anarsoul>
you should probably stick to git master for mesa
<alyssa>
nerdboy: T6xx isn't being supported "oficially", but people have had success with it ... assuming it hasn't been broken since ...
<HdkR>
Midgard 1st gen loves getting broken
<anarsoul>
I guess it's like mali200
<anarsoul>
not widespread and thus abandoned
<alyssa>
Alas
<nerdboy>
um, i know quite a few developers with these chromebooks... they last forever, more or less
<nerdboy>
specifically snow, but also peach, etc
<HdkR>
Midgard 1st gen is definitely in more things than Mali-200 :P
<alyssa>
This is true.
<alyssa>
nerdboy: To be clear -- I would love for snow to be working out of the box with Panfrost, and will gladly help people who want to hack on the driver to that end
<nerdboy>
also the samsung power connector is way less wobbly than that horrible brain-fart on the tegra models...
<alyssa>
I personally focus on the T860 (and T720/60 to various degrees), but T604 would certainly be great to be supported as well :)
<alyssa>
Mostly it just has a ton of errata that the rest of the later models don't :|
empty_string has quit [Quit: computers were a mistake]
BenG83 has quit [Quit: Leaving]
empty_string has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
<anarsoul>
nerdboy: I don't see any errors in this log
<anarsoul>
except glamor initialization failed
<nerdboy>
there's no gpu, it's all cpu
<nerdboy>
also fails to start the ut mir/desktop, which works on rockchip just not exynos
<anarsoul>
so get your exynos driver working first?
<nerdboy>
it's all modesetting/fbdev for both, so i'm not sure what you mean...
<anarsoul>
so is it modesetting or fbdev?
<nerdboy>
one for each card
vstehle has joined #panfrost
<nerdboy>
looks like that from xorg log, not *exactly* clear which drm interface gets used for what
_whitelogger has joined #panfrost
guillaume_g has joined #panfrost
kaspter has quit [Quit: kaspter]
marvs has quit [Ping timeout: 268 seconds]
warpme_ has joined #panfrost
pH5 has joined #panfrost
<rtp_>
nerdboy: from the logs looks like you're on snow or peachpi*. I've not tested recently but you need to patch the dts for the gpu node and panfrost for the whitelist. did you do that ?
<guillaume_g>
Would it be possible to add a bypass to the panfrost whitelist check by setting a config option? It would be a lot easier for prople to try panfrost on not yet officially supported platforms.
<guillaume_g>
alyssa: ^
<nerdboy>
that's kernel 5.4.0-rc5
<nerdboy>
on snow
<guillaume_g>
nerdboy: Is panfrost kernel module loaded?
<nerdboy>
yup
<guillaume_g>
nerdboy: so, you need to whitelistt604 in Mesa code
<rtp_>
guillaume_g: oh, I didn't notice you've added the dts bits for snow
<guillaume_g>
rtp_: :)
<nerdboy>
thanks, i can make a patch tomorrow...
<guillaume_g>
nerdboy: this is not for upstream yet, because t604 has a lot of errata as alyssa said. But current state is enough to get weston running as well as a number of glmark2* tests.
yann has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
fysa has joined #panfrost
sphalerite has quit [Remote host closed the connection]
<tomeu>
Using Docker executor with image registry.freedesktop.org/tomeu/mesa/debian/testing-slim:arm64-lava-2019-10-28-2-tomeu ...
<tomeu>
ERROR: Preparation failed: Error response from daemon: Conflict. The container name "/runner-866mxWt2-project-4345-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8" is already in use by container "3d15577861280f4302abfbb4c93b7cf34f9e68a75f89b7cf029593e66969ceb8". You have to remove (or rename) that container to be able to reuse that name. (<autogenerated>:162:0s)
<tomeu>
narmstrong: ah, it ended up working
<daniels>
narmstrong: ^ if you upgrade gitlab-runner to 12.4.0 then that should go away
megi has joined #panfrost
yann has quit [Ping timeout: 265 seconds]
yann has joined #panfrost
paulk-leonov has quit [Ping timeout: 250 seconds]
<HdkR>
Dang, Microsoft shipped out my Surface ProX a day late
maccraft123 has joined #panfrost
paulk-leonov has joined #panfrost
BenG83 has joined #panfrost
<EmilKarlson>
what soc is surface pro using?
<HdkR>
EmilKarlson: Surface ProX is using a modified Snapdragon 8CX that is overclocked and has a AI/DL/NN accelerator glued to it
<EmilKarlson>
no panfrost then?
<HdkR>
Correct
<robmur01>
HdkR: re earlier - most Rockchip SoCs also have a cool trick where UART2 is muxed into the USB OTG phy, so providing the right port is wired up you can get Tx/Rx directly through the USB data lines :D
<HdkR>
robmur01: That's really nice
<HdkR>
We need more devices doing that
<HdkR>
I presume once the USB OTG comes up then you lose the uart, but at that point it probably doesn't matter?
<HdkR>
Like if you're bringing up the OTG port, you've probably brought enough of the rest of the system up that you have output elsewhere
<robmur01>
aww, looks like it's not supported on 3399 :(
<robmur01>
I have played with in on 3288 though
fysa has joined #panfrost
<alyssa>
guillaume_g: The whitelist is specifically hardcoded because stuff on the whitelist is generally so broken there is zero reason to bypass it unless your express goal is dev, at which case you'll be compiling from source anyway to make changes
fysa has quit [Ping timeout: 264 seconds]
maccraft123 has quit [Ping timeout: 240 seconds]
<narmstrong>
daniels: good to know !
maccraft123 has joined #panfrost
<alyssa>
Er, stuff not on the whitelist
<HdkR>
alyssa: is that a 16element swizzle in that #2054 comment?
<urjaman>
heh, i read that as "stuff on the whitelist is already so broken that you dont want to see what stuff not on the whitelist is like" :P
<tomeu>
:D
<alyssa>
HdkR: unfortunately
<alyssa>
I mean
<guillaume_g>
alyssa: is it so broken, or just untested?
<alyssa>
guillaume_g: I mean, both, but mostly broken
<alyssa>
HdkR: That instruction is a vec4 but we do encode 16element swizzles in the MIR nowadays, to futureproof for CL
<guillaume_g>
alyssa: it is a mess to rebuild just to give a try on a system.
<HdkR>
alyssa: Neat
<tomeu>
guillaume_g: a day will come when these GPUs will be supported, but for now the opinion on the people working on it is that it would slow development too much
<guillaume_g>
tomeu: I understand that, but I guess some variants are not tested upstream but would work, at least at some point. :)
<tomeu>
at that point, those variants will be in CI and will be whitelisted
<rtp_>
guillaume_g: I guess it should not be so hard to create a script to automatically patch and build mesa every day/week/... :)
<alyssa>
rtp_: Any particular reason to want nightlies every night/week/etc?
<guillaume_g>
alyssa, tomeu: would you be interested to have an arndale board (exynos5250 with t604 and lots of errata...) for your CI?
<tomeu>
guillaume_g: in an existing lava lab? or would we have to hook them up and maintain them?
<guillaume_g>
tomeu: it would be to send it to you.
<tomeu>
ah, I would say no for now, until a customer appears
<tomeu>
hardware is the cheapest component of all this
<rtp_>
alyssa: it was more an answer to the issue of guillaume_g "< guillaume_g> alyssa: it is a mess to rebuild just to give a try on a system."
<daniels>
guillaume_g: we already have snow chromebooks in lava - but someone has to maintain them, and make sure that T604 works and isn't flaky ..
<guillaume_g>
daniels: ok, so no need for anrdale then. :)
<daniels>
guillaume_g: but thanks for teh otter!
<daniels>
er.
<daniels>
but thanks for the offer.
<alyssa>
robher: Do we have the ability to map BOs specifically in the lower 32-bit? (so the pointer in GPU space fits in a uint32_t)
<robmur01>
alyssa: currently the whole mm is constrained to 4GB anyway, isn't it?
<robher>
alyssa: they always are currently.
<robher>
But why do you want that?
<alyssa>
rob*: gotcha, thank you
fysa has joined #panfrost
<alyssa>
Gallium silliness trying to bring up opencl
<alyssa>
But if it's always 32-bit now, that's good enough for me ... if/when we extend, we can probably fix userspace the right way
<robher>
alyssa: if you rely on that, then we'll have an UABI problem.
<robmur01>
either way, technically we can *map* wherever we like, it's only the VA allocator that would need convincing to obey additional constraints where necessary
<robher>
It will probably move when we do shared VA support.
fysa has quit [Ping timeout: 265 seconds]
<alyssa>
robher: I'm not sure if I rely on it yet, this is to be figured out
<alyssa>
I don't plan to land this code until I figure out whether it's actually needed
<urjaman>
robmur01: btw did you figure out that race (that you commented had something to do with shared interrupts)?
guillaume_g has quit [Quit: Konversation terminated!]
<robmur01>
urjaman: I've not managed to look at it yet - my guess was that it might somehow be possible to run the job IRQ handler and thus free stuff before a job has truly finished, but I have no idea whether that can really happen
karolherbst has quit [Ping timeout: 276 seconds]
karolherbst has joined #panfrost
maccraft123 has joined #panfrost
maccraft123 has quit [Quit: WeeChat 2.6]
maccraft123 has joined #panfrost
fysa has joined #panfrost
fysa has quit [Remote host closed the connection]
fysa has joined #panfrost
pH5 has quit [Quit: bye]
<robher>
alyssa: FYI, my current plan for SVA is existing UABI users will get an address within kernel VA space (a high addr) (because userspace will never use kernel addresses). Then a new alloc flag will skip the VA alloc and we'll set the VA on mmap (this is what kbase does) and perhaps another ioctl to map the VA in case we don't want to mmap. The complication is 32-bit GPU VA (T720) on 64-bit systems which IMO we just say SVA is not supported on.
<robmur01>
robher: I don't think that works - on aarch64, userspace VAs alone can be >= 48 bits
<robher>
robmur01: with 52-bit VA?
<robmur01>
admittedly 52-bit support is mostly for kit which is unlikely to have a GPU, but coming up against VA_BITS=48 is certainly realistic
<HdkR>
Is there an ARM CPU that supports 52bit VA? It's an optional feature that I'd only see in like..Fujitsu's A64x CPU
<robher>
HdkR: there's kernel support now I think, so safe to assume it's coming if not already out there.
<HdkR>
Neat
<robmur01>
I'm not aware of any hardware actually implementing it yet, but my understanding is that server/HPC folks like being able to do things like to direct-map vast amounts of storage
<robher>
robmur01: But that's total VA bits across the kernel and userspace, not userspace bits? Or the split is gone now with KPTI?
<robher>
robmur01: I guess same VA will always have some restrictions as long as GPU VA < CPU VA. If mmap is limited to GPU VA size (or half to use the upper half for current UABI), then we'd be okay.
<robmur01>
robher: the kernel/userspace division actually happens at bit 55 - both pagetables are each VA_BITS big
pH5 has joined #panfrost
<robmur01>
(modulo the complication of 48/52 being dynamic at runtime)
<robmur01>
kernel addresses always effectively span downwards from 2^64-1
<robmur01>
and there's a big hole in the middle
<robher>
Isn't PAGE_OFFSET the start of kernel space? That's based on VA_BITS.
<robmur01>
kernel space itself is split in half between the linear map and vmalloc etc.
<robmur01>
that's what PAGE_OFFSET is about
<robmur01>
(in case it wasn't clear, that snippet above is quoted from "cat /proc/self/maps" - userspace really is using all 48 bits in anger)
BenG83 has quit [Remote host closed the connection]
yann has quit [Ping timeout: 265 seconds]
maccraft123 has quit [Quit: WeeChat 2.6]
maccraft123 has joined #panfrost
yann has joined #panfrost
Elpaulo has joined #panfrost
<alyssa>
robher: To be clear, will future kernels continue to return address in 32-bit-only GPU VAs if no new/special flags are passed?
<alyssa>
It's not clear to me if that is part of the current UABI or just an implementation detail
<alyssa>
(And accordingly, if I can rely on it in userspace or if I need to plumb through 64-bit support in the common code)
BenG83 has joined #panfrost
<robher>
alyssa: If you were to start relying on that, then yes. It would become ABI. I'm asking you to not rely on that.