<popolon>
armagetronad too (a tron lightcycle like)
<popolon>
the tutorial part seems to crash, but the game itself works perfectly
<popolon>
minetest (a minecraft like) works perfectly too :)
<popolon>
I tried to change rendering settings, to near maximum and it freeze, but from start, with default settings, it works
<popolon>
loop debuggings info on terminal during the freese => finish with a LLVM ERROR: out of memory
<popolon>
looks like a problem with shaders
<popolon>
bye
<popolon>
and thanks again for your great work.
popolon has quit [Quit: WeeChat 2.5]
<SolidHal>
belgin, SolidHal here, the creator of that patch. I would advise against using that one. It causes memory corruption, and leads to kernel crashes. I developed a new fix that doesn't break anything. You can see it here
<bbrezillon>
robher: hm, then I don't understand what's happening
guillaume_g has joined #panfrost
empty_string has quit [Quit: Disconnecting from server]
mani_s has quit [Read error: Connection reset by peer]
griffinp has quit [Read error: Connection reset by peer]
mani_s has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
<bbrezillon>
robher, tomeu: I traced the time spent waiting on BO readiness and out_sync objs, and it looks like on the tests I running locally it's usually between 200 and 400 usecs
<bbrezillon>
while on the CI it's 0 usec
<bbrezillon>
like if the fence was signaled before the job is scheduled
warpme_ has joined #panfrost
pH5 has joined #panfrost
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #panfrost
bbrezillon has quit [Ping timeout: 245 seconds]
bbrezillon has joined #panfrost
davidlt has joined #panfrost
warpme_ has quit [Quit: warpme_]
grw has quit [Ping timeout: 246 seconds]
<tomeu>
bbrezillon: hmm, are you sure the logging is working as expected?
<bbrezillon>
tomeu: I think so
<bbrezillon>
it's no longer 0usec though
<bbrezillon>
but it's still pretty low
<tomeu>
guess you are using the performance devfreq governor locally?
<alyssa>
You can't do an assert() with side effects
<alyssa>
it'll run locally since you have a debug build, but won't ru at all in a release build
<alyssa>
and we compile CI without asserts
<alyssa>
So the CI isn't executing either of those functions
<alyssa>
you need to execute them yourself and store the return value and then assert on the return value, so the statement always executes (but is only checked for debug)
<HdkR>
Oof. I've done that before on accident :<
<alyssa>
Otherwise the waits get deadcode eliminated away on a release build
<alyssa>
tomeu: ^^
<tomeu>
yep, that's what I was expecting to happen
<tomeu>
alyssa: you seem to be in a much better timezone!
<alyssa>
Heh
* bbrezillon
facepalm
belgin has quit [Quit: Leaving]
<bbrezillon>
alyssa: thx for reminding me this subtelty :)
<bbrezillon>
I've been chasing this problem for 2 days
<alyssa>
bbrezillon: Hay, sometimes you just need the fifth and sixth eyeball :)
<alyssa>
Is the idea to never stall unless we're OOMing?
<bbrezillon>
yes
<bbrezillon>
actually no
<bbrezillon>
the idea is to not wait on BOs if we don't have to
<bbrezillon>
first try to get a BO from the cache, without waiting
<bbrezillon>
if it fails, try to allocate a new one
<bbrezillon>
and if the new allocation fails, try to get one from the cache, but this time wait
<alyssa>
Sure, okay!
* alyssa
has to run, but please do discuss in here and I'll try to give feedback time permitting! :)
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 245 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #panfrost
rcf has quit [Ping timeout: 245 seconds]
megi has quit [Ping timeout: 258 seconds]
<warpme_>
alyssa: in my todo bookmarks I have https://rosenzweig.io/t760.patch . I want to play a bit with H6 t720. Is it worth to play with this patch or rather this is old thing and let’s forget it?
rcf has joined #panfrost
<alyssa>
warpme_: I believe everything you need to get started is already in current git master :)
<alyssa>
(That patch was pushed a while ago)
<warpme_>
perfect
<warpme_>
current master gives me black screen so probably we are not yet there :-p
rcf has quit [Client Quit]
rcf1 has joined #panfrost
rcf1 is now known as rcf
tgall_foo has quit [Read error: Connection reset by peer]
<alyssa>
Oops
tgall_foo has joined #panfrost
davidlt has joined #panfrost
<tomeu>
warpme_: I think we just regressed at some point
<tomeu>
warpme_: I was planning to start with the simplest test case (kmscube?) and dump cmdstream traces from blob and panfrost to see what differs
<alyssa>
tomeu: Better start with a job that does nothing but clear.
<alyssa>
After that, one triangle.
* tomeu
was assuming that somple clears do work
<alyssa>
Though if you have traces on hoof from kmscube/etc, I can take a peak
raster has quit [Remote host closed the connection]
raster has joined #panfrost
<daniels>
bbrezillon: 'not wait on BOs if we don't have to' - or not wait at all :P
raster has quit [Remote host closed the connection]
raster has joined #panfrost
<bbrezillon>
daniels: well, not waiting at all would be better, but unfortunately tomeu's CI doesn't like it
<daniels>
:D
<alyssa>
:|
<alyssa>
bbrezillon: Very much sounds like a bug masking another bug
<bbrezillon>
alyssa: which one?
<alyssa>
bbrezillon: "not waiting at all would be better, but unfortunately tomeu's CI doesn't like it"
<alyssa>
It much sounds like something is borked deeper in the stack, and the extra wait there is just masking the problem
<bbrezillon>
daniels is trolling because the 21FPS -> 25FPS improvement I was mentioning the other day actually became 25FPS -> 26FPS after fixing a few bugs
<bbrezillon>
most of them relating to not waiting on BO readiness :)
<alyssa>
bbrezillon: Woop.
<bbrezillon>
and I guess the 21FPS was because I didn't use the performance governor when testing
<alyssa>
I recall getting 23fps or so on -bterrain
raster- has joined #panfrost
raster has quit [Read error: Connection reset by peer]
raster- has quit [Remote host closed the connection]
raster has joined #panfrost
<bbrezillon>
alyssa: with a release build?
<bbrezillon>
and performance governor activated?
<tomeu>
will be lots of fun to work on performance
<robmur01>
robher, bbrezillon: you know the joke is that even "non-cacheable" is cacheable, right? ;)
<tomeu>
here we were all, happily not thinking about caches...
afaerber has quit [Quit: Leaving]
megi has joined #panfrost
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #panfrost
griffinp has joined #panfrost
afaerber has joined #panfrost
rcf has quit [Ping timeout: 268 seconds]
rcf has joined #panfrost
rcf1 has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
raster has quit [Remote host closed the connection]
<alyssa>
bbrezillon: That'd be great!
<alyssa>
Also, while you're at it, give the same treatment to mipmaps
<alyssa>
Mipmapping (generate_mipmap) is currently handled via u_blitter
warpme_ has joined #panfrost
<alyssa>
Mathematically, mipmapping is doing a downscale with a bilinear filter
<alyssa>
It's working always on powers-of-two, so essentially, you're taking 2x2 sets of pixels and averaging their colour values to get a single 1x1 pixel.
<alyssa>
The upshot is that bilinear texture filtering does exactly that, given a suitable sampler.
<alyssa>
Also, automipmap generation is loosely defined in the spec iirc so it just has to look right :p
<alyssa>
So essentially the idea to mipmap a m-by-n texture is to render to an FBO of size (m/2)-by-(n/2)
yann has joined #panfrost
<alyssa>
And the fragment shader is "just" sampling from the (m-by-n) texture with a linear MIN filter (the MAG filter is irrelevant, establishing so is left as an exercise to the reader)
<alyssa>
This is a slightly different shader from the wallpaper shader -- wallpapers can use texelFetch() whereas mipmapping gets texture() -- but conceptully the same
<alyssa>
So that's established with a TILER/FRAGMENT pair
belgin has quit [Quit: Leaving]
<alyssa>
The other catch is that it's recursive, of course -- for mxn, you have l=log2(min(m, n)) levels (iirc), so you have l TILER and l FRAGMENT jobs
<alyssa>
By constructing manually, however, we can do an optimization we can't with u_blitter: chain all of the TILER jobs together into a single job chain, and chaini all of the FRAGMENT josb together into a single job chain
<alyssa>
Conceptually, TILER jobs do tiling which can be done in parallel for different render targets (with distinct tiler heaps and polygon lists for each render target). Whether that parallelism matters is debatable, but it is correct.
<alyssa>
The FRAGMENT jobs, of course, have a strict in-order dependency of higher level rendering on lower levels (why?). You can enforce this by setting the job_barrier` flag in the job descriptor header.
stikonas has joined #panfrost
megi has quit [Quit: WeeChat 2.5]
davidlt has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
<alyssa>
alyssa note to self: make TLS scratchpad CPU-invisible (?)
<alyssa>
alyssa note to self: remove tiler_dummy
<xdarklight>
"I'll let future alyssa deal with this." ;)
<xdarklight>
and then in the future "damn you past alyssa"
<alyssa>
xdarklight: Past Alyssa is kind of annoying
<alyssa>
But whatever, I don't care about future Alyssa
<alyssa>
;)
<xdarklight>
:)
<xdarklight>
been there, done that myself
<alyssa>
xdarklight: Would you like to write that patch? First contribution woot woot?
* alyssa
would deal with it now but her dev machine is like a 5 minute walk away :p
<xdarklight>
I have way too much on my own TODO-list
<alyssa>
Aww
<xdarklight>
still need to review some Amlogic and Intel SoC patches, then there's this board lying on my desk with serial TX soldered where I still have to figure out the boot selection pins to boot it via UART so I can then find out there the serial RX line goes
<alyssa>
Do NOT tempt me I am very busy but.... ehhhhh... how hard could it be already wrote one driver.... ummmmm ;p
<alyssa>
Lack of programmable fragment shaders dramatically limits usefulness
<alyssa>
Neat fixed-function effects but... you'd have to start writing GL extensions
warpme_ has quit [Quit: warpme_]
<alyssa>
Back to code review..
popolon has joined #panfrost
<popolon>
hi again.
<popolon>
magaglest works fine, just a little slow (some things are slow like selecting units, and select a place by right click is often on bottom of the screen, could be related to GL face detection)
<popolon>
on RK3288.
<popolon>
with last git version of panfrost.
adjtm_ has joined #panfrost
<popolon>
extremetuxracer (command etr) has a some glitchs not so far from warzone2100, but seems to work fine.
<popolon>
and I can't launch warzone2100, don't know why I changed, i have an error : [wzMainScreenSetup:1692] Can't create a window, because: Couldn't find matching GLX visual