<HdkR>
It's in the spec as a reserved keyword only
<alyssa>
Groan
<alyssa>
So there's no rect texture hardware and I should just use the NIR lowering, then?
<HdkR>
If the hardware doesn't have explicit support for it then you should lower
<alyssa>
I mean
<alyssa>
Does it have explicit support?
<HdkR>
How would we know? We can't test it :P
<HdkR>
Good thing is that rectangle textures can be emulated entirely with npot textures
<alyssa>
Gotchu
<alyssa>
In that case just a matter of, uh,
<alyssa>
HdkR: Okay how do I actually test this tho
<alyssa>
We don't exactly have working desktop GL
<HdkR>
piglit should have rectangle tests
<alyssa>
We don't exactly have working readpixels()
<HdkR>
Oof :P
<HdkR>
Run an app that uses rectangle textures, hope for the best
<HdkR>
Does glReadPixels not work because you need to convert from AFBC to linear format?
<alyssa>
Nope, scanout is linear atm
<alyssa>
It's just unimplemented IIRC
<alyssa>
:P
<HdkR>
ah
<alyssa>
Or broken
<alyssa>
Not sure which one
<alyssa>
txs is an instruction we need, tho..
<HdkR>
txs = texture size?
<alyssa>
Yeah
<HdkR>
So you can use txs in the shader instead of burning a couple of uniforms?
<alyssa>
No idea
<HdkR>
Well, txs is a Midgard instruction rather than a nir op right? :)
<alyssa>
NIR op
<HdkR>
oh
<alyssa>
I meant, I need to figure out how it's done in hw
<alyssa>
In mdg
<HdkR>
How you would do it would be to convert the coordinates in to uv space by dividing the provided coordinates to texture2DRect by the texture size
<HdkR>
and then do a regular lookup
<HdkR>
er, regular fetch
<alyssa>
HdkR: It's all common NIR code, just needed to enable it ;P
<HdkR>
Well that's nice at least :)
<alyssa>
:)
<HdkR>
I guess we have Adreno and VC3D that also care about it
<alyssa>
Yeah
<alyssa>
HdkR: It's just a uniform
<alyssa>
I guess that takes the fun away
<HdkR>
Makes sense
<HdkR>
Not everyone has a texture size instruction and it may or may not be faster to go that route anyway
<alyssa>
Presumably there's an optimization opportunity here (to store the reciprocal of the size as the uniform, rather than the size itself, so lowered rect textures just have a cheap multiplication) but hey
<HdkR>
I'm sort of surprised it doesn't already do that :P
<alyssa>
It might be there, didn't look too close
adjtm has quit [Remote host closed the connection]
adjtm has joined #panfrost
<tomeu>
alyssa: you can blog once you get gnome-shell rendering ok, that should be a much bigger thunder :)
<tomeu>
alyssa, Lyude: if someone imports mali_kbase, I can start sending pull requests
<tomeu>
for the nanopc-t4, I didn't need any changes to the mali node in the DT
<tomeu>
the one already in mainline just worked once I updated ARM's driver to comply with the gpu bindings in mainline
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
BenG83 has quit [Ping timeout: 240 seconds]
pH5 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
_whitelogger has joined #panfrost
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
afaerber has quit [Quit: Leaving]
afaerber has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
yann has joined #panfrost
<yann>
if I understand correctly, current panfrost cannot run GLES apps on Xorg, right ?
<tomeu>
maybe it does
<tomeu>
I try to stay away from X11 these days
<tomeu>
but in principle what I had to implement to get gles2 clients in wayland should be enough for X11
<tomeu>
glamor I guess doesn't work, though
<yann>
ok, could be worth a try then. On kernel side, you're using the ARM driver right ?
<yann>
tomeu: ok, so not the rockchip-modified r18p0 version from rockchip's kernel tree ? I was wondering about upgrading that, r27p0 sounds like good news :)
<tomeu>
no, I use that with mainline
<yann>
well, what i'm after is rendering hw-decoded video, and I've understood that mainline is still not yet with a working mpp
<tomeu>
yann: on what hw?
<yann>
rk3399
<tomeu>
ah yes
<tomeu>
ezequielg: do you have any code that could be already tested?
* tomeu
isn't following closely the VPU work
<yann>
tomeu: btw, did you try high frame rates already ? The problem driving me to panfrost despite its early status is a framerate one - with the rk kernel both es2gears (and our video-rendering app) has a strange behaviour, where eg. in a 120Hz I get a sub-multiple of that as frame rate (60fps or 40fps depending on resolution)
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<tomeu>
yann: haven't really worried about FPS, tbh
<tomeu>
so much that I haven't checked any FPS value so far
<narmstrong>
it has correct configuration in a separate config file for amlogic, and should be the same as tomeu's rk3399 (except the dmabuf config) branch
<ezequielg>
even once a vpu driver is out, you'll need to build chromium, or develop va-api to use the driver.
<narmstrong>
and it has a clean git history
<ezequielg>
the driver won't work with current standard gstreamer
<yann>
ezequielg: the rockchip drivers for libmpp support could not be made to work ?
<chewitt>
thankfully someone is writing a V4L2 stateless decoder to use the new requests API
<chewitt>
MPEG2 is working on RK3288 (Tinkerboard)
<chewitt>
next up for testing is RK3399
<chewitt>
then more codecs to add
<ezequielg>
chewitt: i am writing :-)
<ezequielg>
i am not aware of anyone else
<ezequielg>
also, not aware of mpeg2 working on rk3288 - wonder how it works
<ezequielg>
yann: i don't know. my focus is on upstream :-)
<ezequielg>
but maybe once we get this to work on chromium, we could think of a vaapi thing or something.
<alyssa>
yann: Glamor doesn't work, so X doesn't work at all unless you disable GPU acceleration afaik
<alyssa>
That said, Xwayland works on sway, and GL apps can run under X and get piped into a Wayland session
<alyssa>
So start sway and open the X/GL(ES) app from there and things should mostly be okay
<yann>
alyssa: ok thx
<alyssa>
(Or ideally just run Wayland/EGL/GLES apps under, you know, Wayland, and things will be a lot happier)
<yann>
yeah, we've planned to support wayland some day :)
raster has quit [Remote host closed the connection]
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
AntonioND has joined #panfrost
BenG83 has quit [Quit: Leaving]
yann has quit [Ping timeout: 258 seconds]
belgin has joined #panfrost
BenG83 has joined #panfrost
stikonas has joined #panfrost
pH5 has quit [Quit: bye]
afaerber has quit [Quit: Leaving]
<Lyude>
tomeu: poke: import == put on the panfrost group page?
pH5 has joined #panfrost
yann has joined #panfrost
<Lyude>
either way, I'll see if i can get somehing done about that today while I'm in the office
belgin has quit [Remote host closed the connection]
raster has quit [Remote host closed the connection]
JasuM_ has quit [Ping timeout: 246 seconds]
<HdkR>
Lyude: Btw, once we eventually push code to mesa. Is it going to be one huge patch, "here is the code to replace Mali Blob for everyone"
<Lyude>
HdkR: perfect!
<Lyude>
that'll be easy :)
<Lyude>
Feel free to cc me on the patch series btw
<HdkR>
Lol
<HdkR>
Lyude: You could push the patch series :P
<Lyude>
actually I don't have push rights on mesa
<Lyude>
one of the few graphics related repos I can't push to
<HdkR>
er, I meant push to the ML
<Lyude>
oh! yeah I don't mind sending it
<Lyude>
when do we want to do this precisely?
<Lyude>
We got resource management checked off (I think, alyssa?), winsys, I think that just leaves splitting some stuff to meet 80 chars line width and that's it
<HdkR>
There might still be a memory leak somewhere
<Lyude>
if most of them are fixed, I think that's OK
<stikonas>
btw, is there an easy way to test panfrost on mainline kernel?
<stikonas>
some patch for kernel driver maybe?
<stikonas>
I already have panfrost mesa installed
<Lyude>
stikonas: yes-i'm going to setup a repo with the oot kernel driver tonight on panfrost's page
<stikonas>
oh thanks
<Lyude>
np
<Lyude>
my fault for slacking on it
<stikonas>
I have rockpro64 here and I use mainline 4.20 kernel...
<Ashy>
stikonas: Ive got a 970 evo on my rockpro64 finally now
<Ashy>
haven't moved the root drive over yet though
<Ashy>
s/drive/partition/
<alyssa>
Lyude: HdkR: If you don't mind, I would like to send the patch (/series) when it's ready. I know it really doesn't matter, but... I dunno, just symbolically?
<Lyude>
alyssa: i understand
<Lyude>
just cc me on it :)
<alyssa>
Of course :P
<Lyude>
tbqh with the amount of work you've put into this you deserve it
<alyssa>
Thank you <3
<HdkR>
alyssa: Go for it :)
<HdkR>
I'm not going to do it. Just talking about it
<alyssa>
Anyways, biggest thing we're missing is, um, licensing issues
<alyssa>
Mesa is permissive licensed (MIT or BSD or something), as is Panfrost's own code..
<alyssa>
...except we're including the GPLed kernel headers
<alyssa>
Which makes the whole driver GPL atm
<alyssa>
Either we need to make more progress on kernel or do some sort of shim or talk to a lawyer or something
<Lyude>
alyssa: I don't think that should be an issue since a header isn't code
<Lyude>
trying to think of who we can ask to make sure
<Lyude>
i'll just poke dri-devel, and if there's confusion in there I'll see if I can give one of our lawyers a quick poek
<Lyude>
*poke
<alyssa>
Lyude: It's my understanding it probably is an issue the way we have it set up now but IANAL
<Lyude>
hm
<Lyude>
we could always just teach meson how to link panfrost to mali_kbase for the time being
<Lyude>
with it outside of the src
<Lyude>
then just don't build panfrost if the location for mali_kbase isn't specified
<alyssa>
Slightly better but still kinda questionable for upstreaming
<alyssa>
Since lawyers would argue we're still a derivative work of the kernel since the code depends so strongly on their headers (seeing as it can't work without them!)
<Lyude>
yeah, let's bring this up in dri-devel
<stikonas>
Ashy: do tell me how fast rootfs is when you test it
<Lyude>
alyssa: yeah
<Lyude>
that's what I wanted to do with it originally as well :p
<Lyude>
still-having our own middleware is going to be better as we transition to our own kernel driver either way
<Lyude>
something like libdrm but not actually libdrm so we don't need to maintain much of an abi
<alyssa>
Mm, right
<alyssa>
Lyude: If we have two middleware packages (one MIT and one GPL, depending on what kernel you need) with the same interface, dynamic linked, I wonder if distros could sort that out and let users use what they need... but maybe we don't care
<alyssa>
That's de facto what happened with early freedreno with libdrm
<urjaman>
hmmmm
<Lyude>
oooh
<Lyude>
that's not a bad idea at all
<Lyude>
one other thing we could do
<Lyude>
although this is quite a longshot
<Lyude>
or, hm. nevermind, that idea I had was probably not a good one :)
<alyssa>
(It's somewhat difficult to care about supporting random kbase versions but I digress)
<Lyude>
alyssa: no i agree
<Lyude>
that's why I said minimal
<alyssa>
Mm
<Lyude>
i don't want the design of our driver to be around mali_kbase forever
<alyssa>
May I show you some code?
<Lyude>
alyssa: no i hate code, why would I ever want to see code
<alyssa>
^ That is what Mali userspace code looks like
<alyssa>
That handles several sets of incompatible kbase versions
<alyssa>
You don't want your code to look like that.
<Lyude>
holy fuck
<Lyude>
wow yeah ok
<alyssa>
(README says that's GPL code)
<Lyude>
i guess I never really went through all of the different ABIs they did
<Lyude>
but-doing the change I did recently with the mali uapi stuff wasn't that difficult at all
<Lyude>
hm
<alyssa>
Okay but maintaining it
<Lyude>
again i agree :p, i'm just trying to think if there's something else we could do that might be easier
<Lyude>
so i think if we transition from mali_kbase to our own kernel driver, and have a middleware ioctl handler like libdrm for panfrost, but just aim that at our own kernel driver for the time being
<Lyude>
that might be what we want
AntonioND has quit [Quit: Quit]
<Lyude>
since then if in the future we do need to hook back up to mali_kbase temporarily, we can write the code to do it
<Lyude>
but for the time being, we don't need to do anything
<Lyude>
we're going to want some sort of library like that regardless of what our plans are I'm fairly sure