<marcodiego>
is there any estimate of when it will be possible to run wayland or x with the lima or panfrost driver
<HdkR>
When it's ready
<Lyude>
mhm, there are multiple people working on this but most of them are doing it in their spare time
<Lyude>
for panfrost at least
<Lyude>
lima can give you a better answer about utgard in their own irc channel
<marcodiego>
thanks!
<Lyude>
iirc it is already possible for utgard
<Lyude>
np
<marcodiego>
I usually watch Alyssa's work on gitlab and was scared to see no progress last week. Thought it was something related to cease and desist letters
<HdkR>
Cease and desist letters?
<HdkR>
Impossible >>
<marcodiego>
good to know that
<Lyude>
yeah, arm is well aware of what we are doing
<Lyude>
as well a bunch of hw vendors have been helping out as well
<Lyude>
we're pretty safe
<HdkR>
Turns out a lot of people want open source Mali to happen :P
<marcodiego>
Lyude, can you tell me more about "bunch of hw vendors have been helping out" ?
<marcodiego>
Lyude, any chance of people being employed to work on it?
_whitelogger has joined #panfrost
<Lyude>
marcodiego: sending us hw to work with, maybe
<Lyude>
(answer 1, answer 2)
marcodiego has quit [Quit: Leaving]
hanetzer has quit [Remote host closed the connection]
hanetzer has joined #panfrost
BenG83 has quit [Ping timeout: 250 seconds]
<narmstrong>
Lyude: if you have an idea why I have this crash it could help... what kind of panfrost test did you run on the vim2 ?
marcodiego has joined #panfrost
<HdkR>
Lyude: Any reason why all the ioctl definitions use _IOWR instead of the equivalent _IO{,W,R,WR}? Causes encoding to be a bit weird
<HdkR>
Nice. I have a stream captured that looks correct?
<HdkR>
All ES 1.x things so I can't even relate the shader back to something real
<HdkR>
Is the older kbase mem_alloc struct actually 56 bytes? The kbase I have is a union with only 40 bytes
<HdkR>
Also all of the ioctl structs no longer have a header on them?
<HdkR>
If that's the difference between new kbase and old kbase then I'm happy though
<alyssa>
marcodiego: Nah, just focused on a new project which has been eating my attention
<marcodiego>
alyssa, good to hear from you
<marcodiego>
alyssa, I've been thinking about buying a renegade elite with the hope that it gets ryf-ready in a not too distant future
<Lyude>
HdkR: which ones
<Lyude>
the new mali kapi one?
<Lyude>
(we've been working on getting rid of the custom ioctl headers we have)
<HdkR>
Lyude: This is for panwrap. All the ioctls have the header union removed now and the `mali_ioctl_mem_alloc` struct is laid out differently than what is in the repo
<HdkR>
Unless panloader things are known broken now?
<HdkR>
`union mali_ioctl_header header;` Was causing major wrap failure :P
<alyssa>
HdkR: `panloader`, the repo, is deprecated
<alyssa>
Modern panwrap ought to share headers; it's built alongside mesa
<HdkR>
oh?
<HdkR>
Guess i'll grab that. I have it working now at least :P
<alyssa>
:)
<Lyude>
HdkR: if you've got any systems with midgard btw, we could use some help with getting the winsys up
<HdkR>
What's the current state of the winsys? I saw some branches being pushed around
<Lyude>
HdkR: take a look at tomeu's gitlab on fdo, I think they have a wip winsys
<Lyude>
should 'just build' on most systems, bug me if it doesn't
<HdkR>
While this repo is checking out I can hook up another one of the XU4Q boards
<Lyude>
if any of them have T860s that would be useful :)
<HdkR>
mmm, nope, older
<Lyude>
it seems like there's been more luck getting this to run on those then with the T820 I've got
<HdkR>
They are T628
<Lyude>
ahh
<Lyude>
i have some T860s headed my way
<Lyude>
should be here this week or next
<HdkR>
Nice
* HdkR
stacks a few odroid boards
<Lyude>
gonna see if i can get the devicetree platform for mali_kbase working on this vim2 and whether or not that ends up fixing the issues we've been seeing trying to get demos to run, + getting fedora running on this vim2 by default
<Lyude>
since the latter will make it a lot easier to justify working on this at my job :)
<HdkR>
:P
<HdkR>
I'm going to need a custom power solution for all these little boards eventually
<HdkR>
Lyude: So what's the current state of this winsys code? How well is it working?
<HdkR>
Smells like this Dvalin board isn't significantly different than Bifrost from what I can tell with the traces. Should be trivial to add the additional support
<Lyude>
HdkR: I honestly don't know, I haven't gotten a chance to really try it yet
<Lyude>
I think tomeu said they have some demos almost running with it
<HdkR>
I recall something about the screen being rotated 180degrees
<Lyude>
lolwat
<Lyude>
that is still progress though
<Lyude>
- workaround: users must rotate machine upsidedown
<HdkR>
:D
* HdkR
grabs another network cable
<HdkR>
I really /really/ hate Ubuntu's unattended upgrades package
<Lyude>
HdkR: fedora!
<Lyude>
:)
<HdkR>
These boards include Ubuntu images and I don't want to fuss with it :P
<Lyude>
ah
<HdkR>
Well I'll give it a few minutes and I'll clean up my mess of boxes I guess
<HdkR>
Jeez, it's still going. I even got distract by a cute cat
<HdkR>
got distracted*
<urjaman>
afaik the 180 degree thing got fixed
<HdkR>
Oh neat, I missed that
<urjaman>
(not that i've gotten anything else done except lurking on irc...)
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<Lyude>
narmstrong: poke, you around?
<narmstrong>
Lyude: yup
<HdkR>
kutf.ko is the resulting file?
<HdkR>
Should I remove the system provided kbase and just use this module?
<Lyude>
looking in the mali_kbase code, I only seem them trying to bring up a single clock, and rk3399 seems to only have a single clock defined for their GPU as well
<narmstrong>
Lyude: theorically, yes, but we can only enable one
<narmstrong>
Lyude: i removed the CLK81 and it "worked" well, until I got the GPU crash !
<narmstrong>
Lyude: did you push your kernel somewhere ?
<Lyude>
narmstrong: what's the GPU crash you got?
<narmstrong>
I need to cleanup the gpu DT node and push it upstreal now we know it's ok
<Lyude>
narmstrong: thats the current kernel I'm using
<Lyude>
but this seems to be as far as I can get with kmscube
<TheKit>
is there a chance to have winsys with downstream MTK kernel? I tested latest master on Gemini PDA and it still works for glmark-es2, with FPS being around 1/3 of official Android blob running with same XShmCopy setup, so pretty cool
<alyssa>
Only 1/3? :(
<Lyude>
it might help to explain what a MTK kernel is as well
<alyssa>
MediaTek
<TheKit>
3.18 kernel with Mali driver, but without DRM driver
<Lyude>
TheKit: as long as you can get an up to date enough mali_kbase
<Lyude>
TheKit: does this device have normal devicetree support for the mali GPU?
<Lyude>
I figured, they aren't using the devicetree platform but their own mtk platform, and that's a really old version of the kbase driver
<Lyude>
TheKit: do they not have any kind of mainline kernels you can use?
<TheKit>
only with UART support
<TheKit>
*with only UART support
<Lyude>
wow
<Lyude>
i'm actually kind of astonished that gemini went with a system with that bad mainline kernel support
<Lyude>
TheKit: do you happen to know the name of the actual soc on the gemini?
<TheKit>
MT6797
<TheKit>
there was pinctl support submitted for it recently
<TheKit>
but I don't know what else is needed to attempt to drive display
<Lyude>
wait, I think I misinterpreted what you said. "with only UART support" do you mean you just can't get the kernel installed unless you've got access to UART?
<TheKit>
I mean it does not have most of SoC-specific drivers
<Lyude>
mm, TheKit: honestly whether or not we support older mali_kbase is going to depend on how much extra work it needs, but also I'd rather just have our own kernel module if we want to support devices like this
<Lyude>
then there is probably hope, just a matter of porting over the platform specific stuff in the mali_kbase repo for your SoC that you linked earlier
<TheKit>
but how does the DRM integration work? mali_kbase provides rendernode, then?
<Lyude>
(if you do that i'll be happy to add it to that branch, I've been considering adding people's platforms in there to make it easier for everyone to test this)
<Lyude>
TheKit: well it doesn't, that's why we're eventually having our own kernel module
<Lyude>
although you should still be able to get winsys support with or without drm
<Lyude>
but yeah, mali_kbase uses it's own not-drm thing
<TheKit>
without drm, where would the output go?
<Lyude>
TheKit: the screen :P, or panfrost can render to a drm device other then itself
<Lyude>
for instance, on the vim2 i'm trying to get working it should be rendering to the meson drm device
<TheKit>
I mean there is no drm for the screen :)
<Lyude>
TheKit: drm and display aren't mutually exclusive, it's just drm is the interface that all mainline kernel drivers use
<Lyude>
TheKit: are you saying your system's display driver doesn't have drm support?
<Lyude>
(remember: display is separate from the GPU here)
<Lyude>
(this is not the case on many other GPUs)
<TheKit>
yes, it can import buffers via MediaTek inteface, but not DRM
<Lyude>
ouch :(
<Lyude>
TheKit: to support with winsys would require us to have a system and the time to focus on it, and I don't think we have either of those
<Lyude>
unless mediatek wants to submit a winsys driver for their display chip, but if they don't have DRM support that seems very unlikely
<TheKit>
I suppose it could be possible to implement fake DRM driver, but that depends on having other parts working first to be feasible
<Lyude>
honestly
<Lyude>
it is probably a /lot/ more sensible for mediatek to make that thing be able to run on a mainline kernel
<Lyude>
or whoever wants to do the work for that
<TheKit>
surely not MediaTek, unfortunately, as that is pretty outdated chip for them now
<Lyude>
mm
<Lyude>
sorry I can't help you more btw
<Lyude>
arm's kind of terrible with this stuff sometimes
<TheKit>
no problem, you answered what I was seeking to know
<Lyude>
(s/sometimes/a lot)
<Lyude>
TheKit: glad to hear, if there's anythin g else I can help with let me know. also
<TheKit>
thanks
<Lyude>
i hear from most people that the rockchip systems are a lot easier to get panfrost working with
* Lyude
is getting one soon herself
<Lyude>
and I will be very glad when I have one, it's going to make figuring out how to get this vim2 working a LOT easier :\
<TheKit>
does vim2 render via OpenGL?
<TheKit>
ah, that's the platform, not text editor
<Lyude>
TheKit: the vim2 actually has pretty decent mainline kernel support
<Lyude>
so it's got it's own meson drm driver
<Lyude>
ah, yeah, I kept getting confused by the name as well since I'm a hardcore vim user :p