ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #panfrost
* icecream95 wonders if this could be a Panfrost bug
<icecream95> V
<icecream95> Fixed! https://0x0.st/omEC.png
<icecream95> Hmm.. this is odd. I have four draw buffers bound, but clearing them all only clears the left half of the second one
<icecream95> More accurately: It only clears tiles on the left half, as well as any tiles which get rendered to on the right half
* icecream95 wishes there was a way to change PAN_MESA_DEBUG options while in RenderDoc
<icecream95> PAN_MESA_DEBUG=nocrc fixes that issue
<HdkR> can't you have renderdoc launch a bash script which sets what you want?
<icecream95> HdkR: This is more for while replaying it
<icecream95> This is probably the same issue with CRCs not being written that I hit a few days ago
<HdkR> ah, would need to be set initially then. I wonder if `setenv` would even work to have mesa pick up new variables.
<icecream95> It wouldn't. But I (not in upstream Mesa) did implement a mechanism where doing setenv would trigger a GPU core dump
<HdkR> nice
<icecream95> Never actually used it to debug anything, though...
hexdump0815 has joined #panfrost
hexdump01 has quit [Ping timeout: 480 seconds]
chewitt has joined #panfrost
greenjustin has quit [Remote host closed the connection]
<icecream95> Fun... the nir_foreach_shader_out_variable in pan_nir_lower_zs_store doesn't work with depth fragment fetch and gl_FragDepth write because there are multiple variables for FRAG_RESULT_DEPTH
<icecream95> Even regular framebuffer fetch is completely broken for GLES 2.0
<icecream95> Erm no, it works, but more by luck than anything else
<icecream95> Hmm.. why are my STK patches making it 3x *slower* on Midgard?
<icecream95> Float blending, maybe?
<icecream95> It's still twice as slow even after fixing that
<icecream95> Oops, did I just reimplement !13979 by accident... again? I forgot about that.
chewitt has quit [Ping timeout: 480 seconds]
<macc24> HdkR: setenv?
<macc24> the c function?
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #panfrost
<HdkR> macc24: Yes. mesa has to query the environment variables somehow
<HdkR> If I recall it just uses `getenv` which will pick up what you put down with `setenv`
<macc24> HdkR: setenv("GALLIUM_HUD", "fps", 1); before running execl() worked fine for me
<HdkR> But does it work before eglCreateContext?
<macc24> i have no idea
<HdkR> and if you shutdown the GL context and close everything, set new environment variables, then bring it back, will it pick it up? Questionable.
<macc24> i just use setenv to set stuf then exec into program using mesa
<HdkR> Sure, that will be fine
<HdkR> But if you're wanting to change things in renderdoc captures there is no execve
<HdkR> That's the difference here
<macc24> ah
<icecream95> Who needs environment variables when you can rewrite a tiny file thousands of times over the course of execution of a program?
<HdkR> I feel called out.
<HdkR> :D
<macc24> i irrationally hate this line
<HdkR> Don't look at FEX-Emu source then. I use pre-{increment,decrement} all over the place.
<macc24> it's one thing to use it inside an expression, but on itself i'd rather value--; than --value;
<icecream95> macc24: you hated that more than how I parse the same number two different ways?
<macc24> icecream95: what different ways?
<icecream95> macc24: fscanf, strtoll
<icecream95> (Quiz question: What would happen if the file contained "0x1234"?)
<macc24> icecream95: well i would fgets into a buffer and parse that buffer
<macc24> but my usecase for that is very different, https://github.com/R-ARM/Rtoybox/blob/master/Rmenu2/main.c#L195
<icecream95> macc24: "exit(0); break;" You really want to make sure execution finishes, don't you?
<macc24> heh
<macc24> i could've done a `*(int *)0x0 = 1;` instead to be 1000% sure
<HdkR> tgkill(::getpid(), ::gettid(), SIGKILL);
<icecream95> Open a webpage with instructions for the user to open taskmgr and kill the process to be extra sure
<icecream95> If running in a container, maybe just killing PID 1 would work
<macc24> that program is running on very limited resources
<macc24> basically, i thought to myself "what if i made my own menu instead of using emulationstation"
<macc24> so i did, then nuked it because it was shit, re-done it, nuked it again and this is my 3rd shot
* icecream95 decides that Libreoffice is not overkill enough for an assignment due in an hour so installs Scribus
* macc24 hands icecream95 a vim-8.2.4651-1-x86_64.pkg.tar.zst
<macc24> :)
<icecream95> macc24: Not nvi or elvis or joe or jed or jstar or nex?
<macc24> icecream95: no
<HdkR> Embrace the greatness of neovim
<macc24> if vi had syntax highlighting i would just use vi
<HdkR> Main issue I had with vim is performance. Once I was hitting 10k line files some performance problems were cropping up
<macc24> 10k lines?
<HdkR> Relatively small but some extensions I use make it pretty rough.
icecream95 has quit [Ping timeout: 480 seconds]
rasterman has joined #panfrost
icecream95 has joined #panfrost
<icecream95> My STK renderer rewrite using colour/depth fbfetch made it a whole... -40% faster!
<icecream95> Yup, that's negative. Hopefully there is something obvious I screwed up, otherwise this was a failed experiment
* icecream95 wonders how perf counter values differ between the renderers
icecream95 has quit [Ping timeout: 480 seconds]
<CounterPillow> is there a counter to see the cache misses? Might be a cause for mystery performance losses
<alyssa> icecream95: Woof :-(
<alyssa> CounterPillow: yes, far too many of them in fact ;)
alyssa has quit [Quit: leaving]
rasterman has quit [Quit: Gettin' stinky!]