<cyrozap>
Off-topic, but I figured since I asked the question in here someone might be interested in the answer: I figured out what that peripheral in that USB host controller is used for--it's dedicated hardware to perform additions/subtractions on arrays of 16-bit integers. That is, into the corresponding registers you first write a 16-bit value, the array address (8 byte aligned), the count of 16-bit ints to
<cyrozap>
operate on, and the element offset into the array of 16-bit ints (so an element offset of 1 is a byte offset of 2). Then, you set some flags in another register which configures the math operation and tells it to "run".
<cyrozap>
That algorithm I was asking about, which makes that neat pattern when plotted, is what (sometimes) generates the value that is written into the "element offset" register.
<cyrozap>
So in a way this hardware is like an extremely-limited vector processor--you can only add/subtract a single constant to/from each element in an arbitrary-length array, but subtraction won't work if _any_ element in the array is less than or equal to the value of the constant (the data in the array is left alone and the hardware clears a flag in its status register).
<cyrozap>
The point of this hardware, I think, is to accelerate additions/subtractions on arrays of buffer pointers, since when looking at memory dumps from this device it seems the USB 3 hardware uses those pointer arrays to know where to read/write USB data (which the firmware then instructs the PCIe DMA controller to transfer to/from the host).
<HdkR>
huh, neat
camus has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
cowsay has joined #panfrost
cowsay_ has quit [Ping timeout: 265 seconds]
<bbrezillon>
italove, alyssa: Re Midgard regression => I could not ignore it if those tests were added to CI :P
ids1024 has quit [Ping timeout: 246 seconds]
ids1024 has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
guillaume_g has joined #panfrost
raster has joined #panfrost
yann has joined #panfrost
amonakov has joined #panfrost
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #panfrost
kaspter has quit [Ping timeout: 268 seconds]
kaspter has joined #panfrost
ente has joined #panfrost
alpernebbi has joined #panfrost
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
chewitt_ has joined #panfrost
chewitt has quit [Ping timeout: 268 seconds]
<raster>
grrr come on container builds...
<HdkR>
Container builds are quite nice when they work. They are the worst things in the world when they don't
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos has joined #panfrost
<raster>
HdkR: well they work... i didnt think they would fail for my MR
<raster>
why doesnt /label work?
<bbrezillon>
icecream95: did you try alyssa's branch + INTERSECT mode?
<raster>
ah well
<raster>
/cc will do
davidlt has quit [Ping timeout: 265 seconds]
adjtm_ has quit [Quit: Leaving]
warpme_ has joined #panfrost
Danct12 has joined #panfrost
nlhowell has quit [Ping timeout: 268 seconds]
chewitt_ is now known as chewitt
raster has quit [Quit: Gettin' stinky!]
raster has joined #panfrost
nlhowell has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
davidlt has joined #panfrost
camus has joined #panfrost
vstehle has quit [Quit: WeeChat 3.0]
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
vstehle has joined #panfrost
_TPG has joined #panfrost
<_TPG>
hi
<_TPG>
i'm just curious about performance of panfrost on pine64 rockpro64
<_TPG>
i'm now running Plasma Wayland 5.21.4
<_TPG>
on mesa 21.1.0 rc1
<_TPG>
and im getting only 30 fps
<_TPG>
when i start to move any windows fps drops :(
<_TPG>
glxinfo and es2_info show everything is fine and panfrost is loaded
<_TPG>
qt-5.15.3
<raster>
_TPG: well... I havent actually tried x11 with panfrost... i've always done wl compositing to test it
<macc24>
raster: _TPG said that they are running plasma wayland
<raster>
oh dang
<raster>
missed that
<amonakov>
_TPG: you should also mention your desktop resolution :)
<macc24>
is devfreq scaling gpu frequency correctly?
<_TPG>
1920x1080/60p
<_TPG>
macc24 ? sorry i'm new to this panfrost
<raster>
unfortunately my displays device only does 30hz
<raster>
let me fix that and drop quality a bit
<_TPG>
tell my what cmd run and i'll post output here
<_TPG>
s/my/me
<macc24>
_TPG: ill check if it's slow for me too on my rk3399 laptop... when i find it
<_TPG>
sys says simple_ondemand
<macc24>
put value of max_freq in min_freq
<macc24>
does this help?
<raster>
i get 60fps moving a window around here
<raster>
admittedly i have disabled most fancy stuff ...
<_TPG>
i changed to performance i get 10+ fps
<raster>
ok. got a full desktop reconfigurd now with pager etc
<raster>
i have 2 terminal windows up - i can drag them artound at 60fps easily
<raster>
those 2 windows with the bubbles are spinning them around at 60fps
<macc24>
raster: how fast is enlightenment?
<raster>
well... see screenshot
<raster>
:)
<raster>
fyi this is pretty mich mainline git master of mesa and kernel
<raster>
so my guess for now is.. it's something plasma is doing to either tickle a slow path in panfrost
<raster>
or it's just doing things "slowly"
_TPG has quit [Ping timeout: 240 seconds]
<raster>
i will admit - e's renderer is cpu-heavy as it spends a lot of cpu time trying to minimise rendernig effort
<raster>
aah well
<raster>
he's gone
<raster>
:)
<orkid>
hah! THE raster! thank you for enlightenment! :) :)
<raster>
hehhehehe
_TPG has joined #panfrost
<raster>
i lurk...
* raster
pokes alyssa or tomeu to approve his patch
<macc24>
damm
<_TPG>
macc24 i did put value of max_freq in min_freq
<macc24>
i just installed plasma on my kevin, and it runs
<_TPG>
no improvement
<macc24>
huh
<raster>
macc24: on "ondemand" cpu freq schedulingi get 60fps
<raster>
i can switch to performance and no changes other than cpu% that e uses drops
<macc24>
_TPG: if you already set performance governor pinning gpu clock to max wont change anything
<raster>
(100% cpu at 500mhz != 100% cpu at 5ghz ... as i keep saying)
<macc24>
raster: i use conservative because appoarently it is more battery friendly
<raster>
this above is all a rockpro64 fyi... so panfrost is certainly capable of good performance
adjtm has joined #panfrost
<_TPG>
should i file a bug report for panfrost or not ?
<raster>
macc24: sure - makes sense. but as i'm plugged into a power brick... i can not care other than heat
<raster>
_TPG: what distro do you run?
<_TPG>
raster OpenMandriva Lx cooker
<raster>
aaaaah bugger.
<raster>
there goes that idea
<_TPG>
i'm one of developers
<raster>
i was going to say "try the efl-git and enlightenment-git aur pkg" ... :)
<raster>
(as that'd be pretty much zero effort to try)
<raster>
but only on arch/manjaro and friends
<_TPG>
other distros uses some outdated software, which does not interest me much
<raster>
arch certainly doesnt... but thats off topic
<macc24>
_TPG: disable all desktop effects you can find in settings
<raster>
mostly because arch h as package builds for git efl/e which would instnantly put you on the same level as me with no effort to add dependencies - it'd be a one liner with yay -S enlightenment-git
<macc24>
it helped me get better performance on Giant Fucking Screen™ on kevin
<raster>
i'd at least be able to see if you get much lower fps with the exact same compositor or not
<_TPG>
i see even fps drop when sddm starts
<_TPG>
like whole sddm greeter gets sluggish
<_TPG>
and laggy
<_TPG>
htop is clean
<macc24>
i think sddm uses xorg
<_TPG>
macc24 my own uses wayland and weston for greeter
<_TPG>
anyways no difference on sddm either X11 or wayland
<_TPG>
its just slow
<raster>
i can't see it being slow... :|
<raster>
is weston fast?
<macc24>
raster: i can check on my kevin if weston is fast on t860 sy 2400x1600
<macc24>
s/sy/at
<raster>
well i imagine it'll be fine
<macc24>
alright
<raster>
i suspect it's something plasma is doing
<macc24>
back to poking my duet with linux trying to dualboot it
<raster>
what - i don't know.
<_TPG>
i'll file a bug report then
<_TPG>
thanks for the help
_TPG has quit [Quit: Connection closed]
guillaume_g has quit [Quit: Konversation terminated!]
nlhowell has quit [Quit: WeeChat 3.1]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 240 seconds]
ballerburg9005 has joined #panfrost
<ballerburg9005>
hello, where would be the right place to implement double/triple buffering to cure Xorg screen tearing, or maybe it is already implemented?
<macc24>
ballerburg9005: are you using modesetting ddx driver?
<ballerburg9005>
macc24: I wouldn't know
<ballerburg9005>
I am using 5.11 kernel
<ballerburg9005>
with video acceleration
<ballerburg9005>
S905X3
<anholt>
modesetting driver is the right place, there's even a branch doing it somewhere in the MRs.
<anholt>
iirc
<ballerburg9005>
what is MR?
<macc24>
merge request
<ballerburg9005>
oh, nice
<ballerburg9005>
I searched it quickly but I didn't find anything
<macc24>
i am not seeing any screen tearing on my machine on xorg
<anholt>
the usual solution to avoiding tearing in xorg is you run a compositing manager.
<ballerburg9005>
I am talking about video tearing
<ballerburg9005>
1080p videos and such
<anholt>
yep, and whatever is doing that should be using the present extension (either through GL or by itself), which your compositing manager then either uses present to present, or unredirects, and regardless it ends up not tearing.
<ballerburg9005>
hm
<ballerburg9005>
doesn't it kill resource usage?
<anholt>
I don't know what you mean.
camus has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
thecycoone has joined #panfrost
popolon has joined #panfrost
davidlt has quit [Ping timeout: 240 seconds]
<ballerburg9005>
anholt: I switched to compton but it sadly has no effect
<ballerburg9005>
I don't believe it can do any good, since the video runs over hardware acceleration not trough GL (which would be too slow anyway), from what I understand it would bypass anything else
<macc24>
ballerburg9005: you can't decode video with opengl
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
alyssa has quit [Remote host closed the connection]
alyssa has joined #panfrost
<icecream95>
dhewm3 does glClear(GL_STENCIL_BUFFER_BIT) in the middle of a frame, but if INTERSECT mode is used then it also clears depth for areas that are not rendered to
<alyssa>
oh boy.
<alyssa>
bbrezillon: ^
taowa has quit [Ping timeout: 248 seconds]
taowa has joined #panfrost
<bbrezillon>
icecream95: ouch
<bbrezillon>
ok, so we need to use ALWAYS when we're targetting a Z24S8 buffer, and only one component is cleared
<bbrezillon>
because we have the zs_clean_pixel_write_enable flag set in that case
<alyssa>
ahhh
alpernebbi has quit [Quit: alpernebbi]
<cphealy>
Does anyone here have a recent build of Mesa running on a platform with G52 that they can share the GL and EGL extension list from? Perhaps from Weston startup or kmscube or something like that?
<icecream95>
bbrezillon: dhewm3 works with that branch
<bbrezillon>
icecream95: yay!
<cphealy>
bbrizillon: Thank you!
<bbrezillon>
guess that leaves the question of what we should do on Bifrost
<bbrezillon>
v7
<cphealy>
bbrizillon: Few questions on this: I notice that we are missing EGL_ANDROID_native_fence_sync. Is there anything special needed to be done with Panfrost to make this work? When I look at other Mesa gallium drivers (etnaviv), this extension is supported.
<cphealy>
bbrizillon: Also, regarding the reporting of ASTC support, is this through panfrost natively supporting ASTC or is it perhaps the SW fallback?
<bbrezillon>
regarding the native fence cap, I'd need to check, but it shouldn't be too hard to support if it's not already supported
<bbrezillon>
and we're supposed to support ASTC natively
<alyssa>
at least 2D ASTC is supported natively
<alyssa>
courtesy of Icecream95
<cphealy>
That's great to hear regarding ASTC, nice work Icecream95! ;-)
<cphealy>
It does bring up an interesting question for clients using the GL API: How does a GL app know if the ASTC support is backed by actual HW or is a CPU implementation that results in no graphics memory savings?
<chrisf>
cphealy: theoretically**** in desktop GL you can use ARB_internalformat_query2 to ask about how well things are supported
<chrisf>
im not sure i added enough stars
<cphealy>
;-) I'll have to look into ARB_internalformat_query2 as I'm not familiar with it.
<cphealy>
bbrezillon: regarding the native fence cap, having that in place would be nice to have given the additional functionality enabled in Weston timeline debugging wise (among other things.)
<chrisf>
cphealy: in practice apps bring their own model of what works and doesnt
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #panfrost
<icecream95>
I think ARB_internalformat_query2 would give wrong results about RGTC support on Midgard (and a bunch of other Mesa drivers)...
<cphealy>
icecream95: are you aware of any method with panfrost for determining how many bytes of compressed textures are used by an app vs how many bytes of uncompressed textures are used?