<hanetzer>
aight guys, I'm off work and will now be flashing the coreboot/petitboot payload for testing purposes :)
<hanetzer>
sphalerite: it no boot :<
_whitelogger has joined #panfrost
narmstrong has quit [Ping timeout: 268 seconds]
narmstrong has joined #panfrost
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
_whitelogger has joined #panfrost
<bbrezillon>
I had to do this change http://code.bulix.org/8hh6m3-663504 the fix the Y-flip on gallium-hud+panfrost, which, when thinking about it, is the correct thing to do since the hud logic assumes x=0,y=0 is the top left corner, and the vertex shader is converting pos into NDC
<bbrezillon>
what I don't get is how it can work with swrast
<bbrezillon>
alyssa, daniels: any idea ^
<sphalerite>
alyssa: gp2x is an old linux-based portable gaming console
_whitelogger has joined #panfrost
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
raster has quit [Remote host closed the connection]
<hanetzer>
ok, this may be more doable than I thought... managed to make a 2mb Image.lzma
<sphalerite>
nice!
rhyskidd has quit [Quit: rhyskidd]
stikonas has quit [Quit: Konversation terminated!]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
stikonas_ has joined #panfrost
stikonas_ has quit [Read error: Connection reset by peer]
stikonas has joined #panfrost
stikonas has quit [Read error: Connection reset by peer]
stikonas_ has joined #panfrost
stikonas_ has quit [Read error: Connection reset by peer]
stikonas_ has joined #panfrost
<alyssa>
bbrezillon: :eyes:
<alyssa>
Yeah, that looks like what it would be.
<alyssa>
The better question is figuring out how that pipes around wrt NIR
<alyssa>
Since obviously I have dignity and refuse to ingest TGSI diretly :P
<alyssa>
bbrezillon: We're advertising PIPE_CAP for upper left.
<alyssa>
bbrezillon: Other drivers seem to only support one or the other
<alyssa>
But the caps were derived from softpipe at some point (wrongly)
<alyssa>
So there's your answer. Stop exposing one or the other :)
<alyssa>
(Or do export them but then have to do more stuff to mess with the viewport.)
jernej has quit [Ping timeout: 252 seconds]
<alyssa>
Aside: Panfrost seems a lot slower lately..
<alyssa>
I guess that's the uploads.
fysa has quit [Ping timeout: 252 seconds]
adjtm has quit [Ping timeout: 250 seconds]
adjtm has joined #panfrost
<alyssa>
anarsoul: I notice you copied panfrost_is_scanout
<alyssa>
You should maybe not do that... removing that function is a considerable TODO for pan..
<alyssa>
Though I guess it's fine here
<bbrezillon>
alyssa: yep, that's what I started to do
<bbrezillon>
but then we need to call lower_wpos_ytransform() (either in the tgsi_to_nir or directly from the driver)
<bbrezillon>
which I did
<bbrezillon>
but it doesn't seem to solve my problem
<hanetzer>
sphalerite: oh nice. looks like this is much easier than I thought. stock archlinuxarm aarch64 kernel is a 24mb Image file; that lzma's down to 7.3mb
<hanetzer>
so I may be able to leave more stuff enabled :)
<sphalerite>
yay!
<sphalerite>
meanwhile I'm screwing around with initramfs stuff
<bbrezillon>
looking at the fragment shader dump, it seem that the fragment shader used to draw the hud background just forwards the color it's been passed, so patching input gl_Position is not useful in that case
<bbrezillon>
alyssa: I see that you have a y_flip in pan_fragment.c
<bbrezillon>
do you remember why it's done for the scanout buf only?
<alyssa>
bbrezillon: That's about flipping the entire framebuffer
<alyssa>
Not just the draw
<alyssa>
Since... OpenGL has scanout buffers logically upside down, or something
<sphalerite>
hanetzer: although maybe we should discuss this in #linux-rockchip? :p
<alyssa>
sphalerite: Please :P
<hanetzer>
sphalerite: sure.
<alyssa>
bbrezillon: It's not realy correct -- causes issues with GLX clients from Xwayland...
<bbrezillon>
hm, okay
<bbrezillon>
'cause, if we have a way to flip-Y pos at the fragment (using a shader prop or something similar), we simply test the frag_shader->info.fs.origin_upper_left value
<bbrezillon>
*at the fragment shader level
<bbrezillon>
*we could
<alyssa>
bbrezillon: I think this might be too different types of flips but I'm not sure
<alyssa>
The pan_fragment.c flip is more about, like, negative-Y viewport IIRC
<bbrezillon>
alyssa: if that's not possible, I'm not sure how to solve this
<bbrezillon>
should we patch the position at the end of the vertex shader?
<alyssa>
bbrezillon: Did you try removing the CAP?
<bbrezillon>
yep
<alyssa>
:/
<alyssa>
...Did you try posting your patches somewhere so I can poke? :P
<bbrezillon>
urjaman, alyssa: doing native compilation in a chroot
<bbrezillon>
and I haven't setup git, and of course, I'm root when I commit :P
<alyssa>
bbrezillon: sh00r
<bbrezillon>
to give you the full context, I mount a rootfs over NFS on the target, and when I need to compile something I do it on the host (using chroot and qemu + a native aarch64 toolchain)
<bbrezillon>
it's definitely slower than doing cross compilation, but I didn't have to recompile everything
<alyssa>
bbrezillon: I just dev on host :P
<alyssa>
Since my personal machnie is a RK3399
<alyssa>
And my target machine is a RK3399
<alyssa>
Might as well just stick a keybaord in :p
<bbrezillon>
too many keyboards on my desk right now :p
<MoeIcenowy>
currently I use cross-compile on Lima/Panfrost
<bbrezillon>
alyssa: anyway, panfrost/hud-debug should be cleaner now