alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 250 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 250 seconds]
kaspter has joined #panfrost
stikonas has quit [Remote host closed the connection]
<alyssa> ...and we're back :-)
nerdboy has quit [Ping timeout: 256 seconds]
cwabbott has quit [Ping timeout: 272 seconds]
<alyssa> Okay, so staring harder at bifrost register ctrl fields, what seems to be missing is a mode to write FMA with port 3 but do nothing with port 2
<alyssa> i think that mode 'would' be where we currently have a nop
<alyssa> but you never actually need to encode that (just write FMA with port 2 instead) so it doesn't really matter.
<alyssa> The better question is mode 3, which here is seen as a duplicate of 2 even though it should be that mystery mode logically.
<alyssa> Still more special casey than I'd like but moving in the right direction!
cwabbott has joined #panfrost
<alyssa> Okay, I can finally pack register fields.
<alyssa> Okay, and now I can assign ports, so we have the full pipeline from register allocation to packing onthe wire.
<alyssa> Way more involved than midgard but hey, It Works
<alyssa> Popping off for the night, but now that registers are under control, tomorrow we'll tackle instructions~ stay tuned for scenes from our next episode or something
_mixfix41_ has joined #panfrost
icecream95 has joined #panfrost
nerdboy has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
pH5 has joined #panfrost
davidlt has joined #panfrost
davidlt has quit [Remote host closed the connection]
guillaume_g has joined #panfrost
davidlt has joined #panfrost
mias has joined #panfrost
icecream95 has quit [Ping timeout: 250 seconds]
raster has joined #panfrost
<cwabbott> alyssa: I'm not sure how far your IR design has gone, but don't forget about the fact that there are some special paired instructions e.g. for doing 64-bit adds in a 32-bit clause where a special sideband value (here the carry bit) is carried directly from MUL to ADD so that you really need to keep them together
<cwabbott> that means that you need to model them as a special combined instruction that takes up both MUL and ADD in the IR, and can write an arbitrary pair of registers
<cwabbott> so, the moral of the story is, don't bake into the IR that an instruction can have a single destination, because sometimes it won't be true!
stikonas has joined #panfrost
alyssa has quit [*.net *.split]
_mixfix41_ is now known as MFX414
camus1 has joined #panfrost
kaspter has quit [Ping timeout: 250 seconds]
camus1 is now known as kaspter
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
raster has quit [Ping timeout: 264 seconds]
raster has joined #panfrost
Stary has quit [Ping timeout: 268 seconds]
alyssa_ has joined #panfrost
raster has quit [Ping timeout: 256 seconds]
mrfixit2001 has joined #panfrost
<mrfixit2001> Good morning all! I am the developer behind porting the retro-gaming build of Recalbox to the rockchip boards. I've been tinkering with the latest mesa and mainline kernel with my RK3399 rockpro64 (Mali 850). I wanted to share my experience so far and ask some questions.
<alyssa_> mrfixit2001: *waves*
<mrfixit2001> :) **waves back**
<alyssa_> feel free to ask away, I'll be here
<alyssa_> and not just because i'm not allowed to be anywhere else anymore
<alyssa_> f
<urjaman> F
<mrfixit2001> First, you'll be happy to know that I am able to start emulationstation and some of the less demanding emulators, like NES and SNES. The graphics are actually quite crisp on these.
<alyssa_> cwabbott: ...Joy.
<mrfixit2001> One oddity is that on the previous build using the mali blob and a custom 4.4 kernel, launching emulationstation included setting some environment variables first via command line: SDL_VIDEO_GL_DRIVER and SDL_VIDEO_EGL_DRIVER. Both were set to /usr/lib/libGLESv2.so.
<alyssa_> I can model fused MUL/ADD for the fat insructions, but that doesn't have the dest issue, great.
<mrfixit2001> Strangely - when these are set using panfrost - emulationstation fails to start.
<mrfixit2001> I've confirmed the libraries exist.
<mrfixit2001> If I don't set them, ES starts right up just fine.
<alyssa_> think
<mrfixit2001> When these variables are set, I receive: "(ERROR) : Error creating SDL window!
<mrfixit2001> Could not load EGL library. (ERROR) : Error initializing the GL renderer."
<mrfixit2001> As you can see - libraries all exist: https://pastebin.com/1YH4qbyK
<mrfixit2001> So that's one oddity. Minor, but odd.
<mrfixit2001> Another (hopefully easier) question... On my previous build with the mali blobs and 4.4 kernel this old code works just fine. Using panfrost, it does not work correctly. Can you advise what needs to be updated in this code to be compatible? https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef
<alyssa_> cwabbott: Aaaaa, I see, okay, thank you for pointing that out :)
<alyssa_> At least for that particular case of pointer arithm, I think it might be easier to model it as actual 64-bit operations in the pre-sched IR
<alyssa_> and then deal with this at sched time (duplicating/pairing/etc instructions as needed to make things work)
<mrfixit2001> I should point out that I'm actually testing with a 64-bit kernel and 32-bit userspace
<alyssa_> And then RA and packing don't particularly have to care.
<alyssa_> tomeu: ^
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #panfrost
<mrfixit2001> alyssa_ did you happen to see my link above about what I might need to modify in that code to make it compatible with panfrost?
<alyssa_> mrfixit2001: not sure, asking tomeu :)
<tomeu> mrfixit2001: well, what do you mean by "does not work correctly"?
<tomeu> I think most code should behave the same
<narmstrong> mrfixit2001: could help to have the errors returned by this program @
<narmstrong> for SDL, now SDL must use GBM (drmkms) backend, and I think you used a custom mali+framebuffer backed with mali blob
<alyssa_> Woot! Just emitted our first instruction (an FMA)
<mrfixit2001> I will see about compiling that code with some error reporting so I can tell you where it goes wrong. At the moment there's definitely still some SDL funkiness going on. For example, starting N64 emulators return " SDL_SetVideoMode failed: Could not create EGL window surface". I can hear the game playing in the background but there's no video.
<nhp> alyssa_: Exciting! What are you working on now?
<alyssa_> nhp: veeeeeeeeeeery early stages of a bifrost compiler
<alyssa_> well, was, it is now 10am and I'm off to class.
<nhp> Ah, nice :)
<mrfixit2001> Any update on when GLES3 will be added to panfrost? I'm thinking it's possible that's why I'm running into some issues in a few emulators.
<mrfixit2001> As an example, not sure if it's related to GLES3: warning: extension `GL_OES_standard_derivatives' unsupported
<nhp> Now
<nhp> Set PAN_MESA_DEBUG=gles3
<alyssa_> *gasp*
<alyssa_> Support is experimental - expect things to break - but also plenty works and it's worth a try for the adventurous :)
<nhp> I've been using GLES3 with RetroArch and it seems to work nicely there
<alyssa_> Biggest outstanding issue on master is relating to R11G11B10 framebuffers (which is why STK's deferred renderer doesn't work on master - there are out of tree patches to fix that but not mergeworthy)
<nhp> Something I noticed that is broken with GLES3 (at least I assume it uses it) is Firefox with WebRender on Wayland
<nhp> It just displays as very colorful triangles
<cwabbott> alyssa_: another thing to remember: I discovered that I had got the constant pair ordering thing slightly wrong, but I think I never updated the gitlab page
<cwabbott> the fix might only be in the old out-of-tree assembler
<cwabbott> that's important to get right, since if you don't you will absolutely tear your hair out since it randomly changes small parts of the immediate
<cwabbott> and everything will look correct
<cwabbott> on the page it says that you have to compare the high 4 bits of each 64-bit constant, but actually you have to take the difference and if it's greater than 8 you have to swap it (this will negate the 4-bit difference, which makes it less than 8)
<cwabbott> I suspected that the combination (difference - 8, const 0 high 4 bits) activates some sort of debug thingy (sometimes it hangs the GPU, sometimes it changes different parts of the constant)
nerdboy has quit [Ping timeout: 250 seconds]
<mrfixit2001> With GLES3 enabled, a few things that didn't run before do actually run :D So that's helpful!
<mrfixit2001> Another thing I have noticed which is very strange... panfrost does not like it if I change the resolution from the kms default. It doesn't render anything at all. It doesn't crash or throw any errors however.
<nhp> Are you testing this on the Pinebook Pro
<nhp> At least with mainline it won't do anything but 1920x1080
<mrfixit2001> No I'm testing on the rockpro64. I have a PBP as well, but the 1080p limitation is due to the EDP screen, not the kernel.
<nhp> Ah
<nhp> (I'm nadia:nhp.sh in #pinebook)
<alyssa_> cwabbott: ......Thak you for the heads up x_x
<mrfixit2001> :) hello again! I'm in that channel on discord right now
Stary has joined #panfrost
Elpaulo has joined #panfrost
raster has joined #panfrost
_whitelogger has joined #panfrost
chewitt has joined #panfrost
<mrfixit2001> Just to let you know regarding emulation - here is the graphics glitch with panfrost when emulating PPSSPP games: https://drive.google.com/file/d/1KmLwh0DpaRx7f6r_FIrXmGwgZKLzaDxo/view?usp=drivesdk
<mrfixit2001> Some screens and scenes all render fine - but gameplay isn't usable
<nhp> Try recording an apitrace of it
<mrfixit2001> apitrace package requires Xorg for some reason. My build is entirely GBM / GLES
<nhp> Also what API is PPSSPP using? iirc it can use GLES3?
<mrfixit2001> Yes it utilizes GLES. I've tested it with compiling it with different parameters - setting EGL on/off, setting FBDEV on/off... and the emulator won't work at all without enabling GLES3 - it starts but immediately freezes up into an endless debug loop of "Creating 2560 x 5 FBO using DEPTH24_STENCIL8 texture"
<mrfixit2001> Sadly, no matter what build flags I enable, the graphics glitch always remains
<mrfixit2001> I can confirm - no glitches using the mali blobs.
<nhp> Well, as far as I know GLES3 in panfrost is still incomplete
<nhp> so some broken stuff is to be expected
<mrfixit2001> I've also found that reicast (dreamcast) emulator runs using panfrost. It renders absolutely beautifully, but sadly it's slower than the mali blobs. Same is true of the one N64 emulator that actually runs.
<mrfixit2001> ^-- neither of those use GLES3
<mrfixit2001> Just wanted to report all my findings :)
<nhp> I think it would help the devs a lot if you built those on a system with X11 so you could record apitraces of the broken rendering and post them on the issue tracker on the GitLb
<nhp> GitLab*
<mrfixit2001> I'm testing using recalbox - which compiles on a buildroot toolchain. Enabling xorg in the defconfig would anger a lot of dependency packages and then a number of the emulators would need to have flags added to them in order to force them to ignore the x libraries. Not a project I have the time for at the moment, but I'll put it on my list :)
<nhp> You could grab the Manjaro image or something for the PBP and build the emulators on that
<mrfixit2001> I can say that I'm happy to see things in panfrost progressing so well. I last tested it 6 months ago and this is night and day. Great work devs, keep it up! I'll come back and test again in a few more months to see how it's progressed :)
<mrfixit2001> At this point my two concerns are that when I change the rendering resolution - the graphics seem to render to another plane - as the audio is there but the screen is blank. No errors or dmesg output of an issue. And finishing up the gles3 instructions. Once those two things are resolved then it would be good enough to use in the retrogaming
<mrfixit2001> systems.
<mrfixit2001> As a side question - should I expect to see dramatic improvements in performance as development continues? Or do we expect that the performance as-is won't change all that much?
<nhp> Does changing the resolution work in emulators that do software rendering?
<mrfixit2001> It seems to - yes. For example - using retroarch and running snes9x renders and plays fine. But other retroarch cores render to a black screen.
<nhp> The issue might be with RetroArch then
<nhp> Because RetroArch internally scales the output resolution of the core to your screen resolution
<mrfixit2001> Depending on the core - correct. I've tried setting different internal and output resolutions, but sadly it doesn't resolve.
<nhp> I actually have this same issue on amdgpu with the Beetle PSX core
<nhp> You could try rebuilding RetroArch with --enable-opengles3 --enable-opengl_core
<nhp> And then using the glcore driver
<mrfixit2001> I've also tried patching retroarch itself so that when it launches that it will select the same resolution as the current kms/fb so that no resolution change happens. Oddly, same issue.
<nhp> Another option is to build it with the drm_plain driver and bypass using the GPU entirely, that should be fine as long as you don't need any 3D cores
<mrfixit2001> I'll try those right now and see what happens
<nhp> s/drm_plain/plain_drm/
<nhp> Which cores are you having issues with this happening in
<nhp> I'm on my PBP right now and have RetroArch installed so I could test them here?
chewitt has quit [Quit: Adios!]
<mrfixit2001> Mupen64plus and flycast
<nhp> Oh, I couldn't get mupen64plus to work at all
<nhp> What video plugin are you using for it?
<mrfixit2001> Completely unrelated question - I have the following kernel patch which I had tested with 6 months ago. Do any of the included patches seem sane? https://pastebin.com/qJLPgaz3
<mrfixit2001> As for mupen64plus - I can actually get 2 of the plugins to render and play. But they are soooo slow. MK2 and gliden64. MK2 has rendering glitches even on mario64. But gliden64 looks beautiful. Just runs sooo slowly.
<mrfixit2001> But that's in mupen standalone. The libretro core fails.
<mrfixit2001> I've tried libretro-mupen and libretro-mupen-next.
kaspter has quit [Ping timeout: 246 seconds]
chewitt has joined #panfrost
kaspter has joined #panfrost
<mrfixit2001> both are compiled to use gles3. Mupen-next actually starts! But - renders a black screen.
<mrfixit2001> both are compiled to use gles3. Mupen-next actually starts! But - renders a black screen.
<nhp> You could try to build RetroArch and the cores against desktop GL
chewitt has joined #panfrost
<mrfixit2001> I've been tinkering with a lot of the mupen settings... trying to get it to run in retroarch at all...
<mrfixit2001> I just this second was able to see mario! :D let me get you the settings that affect it.
<mrfixit2001> Ok... with "Gpu Shader Depth Write" enabled - libretro_mupen64plus_next core renders a blank black screen. With it off and with framebuffer emulation enabled it renders most of the graphics but many are missing (like mario himself). With both disabled the game is fully rendered properly.
<mrfixit2001> It would also appear that panfrost hasn't added support for multisampling yet
<mrfixit2001> enabling multisampling also renders to a blank black screen
<mrfixit2001> the normal mupen64plus-libretro core doesn't load at all. But it's a bit dated anyways. My findings above are for the mupen64plus-next retroarch plugin.
<mrfixit2001> Mario 64 runs a bit slowly, unfortunately, but it's playable.
<mrfixit2001> alyssa_ I have the following kernel patch which I had tested with 6 months ago. Do any of the included patches seem sane or should I not use them? https://pastebin.com/qJLPgaz3
jernej has quit [Read error: Connection reset by peer]
jernej has joined #panfrost
nerdboy has joined #panfrost
nerdboy has quit [Ping timeout: 250 seconds]
raster has quit [Remote host closed the connection]
raster has joined #panfrost
MFX414 has quit [Ping timeout: 250 seconds]
stikonas_ has joined #panfrost
marcodiego has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
raster has quit [Quit: Gettin' stinky!]
davidlt has quit [Ping timeout: 246 seconds]
buzzmarshall has joined #panfrost
mias has quit [Ping timeout: 256 seconds]
buzzmarshall has quit [Remote host closed the connection]
enunes has quit [Ping timeout: 256 seconds]
enunes has joined #panfrost
<alyssa_> mrfixit2001: generally speaking, performance won't get worse ;-)
<alyssa_> There's still plenty of room for improvement but right now the focus has been on bifrost, with the expectation that midgard performance right now is "good enough" for a lot of interesting stuff.
<alyssa_> If there are specific bottlenecks on specific workloads, that could probably be worked on :)
<alyssa_> Multisampling support is largely missing yes, surprised it doesn't crash flat out
<HdkR> alyssa_: But without MSAA how are games supposed to pull alpha to coverage tricks? :P
<nhp> I hope at some point it might be possible to have better performance in OpenGL in kwin
<nhp> the performance with GLES is apparently better but requires rebuilding Qt
karolherbst has quit [Ping timeout: 246 seconds]
karolherbst has joined #panfrost
<mrfixit2001> alyssa_ thank you for the replies! Can you advise me if that panfrost kernel patch I shared has any value?