ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
<anarsoul> ddevault: does it work now?
<ddevault> rebuilding mesa
<ddevault> I have to do it from scratch each time if I want to avoid a native build
<ddevault> for reasons, don't judge me <_<
<anarsoul> :)
<anarsoul> I build it natively
<anarsoul> it's pretty fast on rockpro64
<anarsoul> and it's OKish on pine64-lts
<anarsoul> just make sure you have ccache
<anarsoul> I don't really believe in cross-compilation. It's almost always broken one way or another
<ddevault> I'm using postmarketOS, they make it pretty trivial
<anarsoul> fair enough
<ddevault> does not seem to have worked
<anarsoul> can you show your diff?
<anarsoul> (pastebin please)
<ddevault> certainly
<anarsoul> LIMA_PIXEL_FORMAT_FP16 should be 0x06, not 0x26
<anarsoul> it's only 5 bits
<anarsoul> :)
<anarsoul> let me check the rest...
<ddevault> good catch, but that shouldn't affect the extension appearing
<ddevault> I might want to restart some things
<anarsoul> well, that's weird
<ddevault> no, rebooting the display server doesn't help. Didn't think it would but might as well try
<anarsoul> it should have appeared since you exposed PIPE_FORMAT_R16G16B16A16_FLOAT
<anarsoul> can you show output of es2_info?
<anarsoul> PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR just indicates that hw supports linear filter
<anarsoul> *filtering
<ddevault> by my reading of src/mesa/state_tracker/st_extensions.c
<ddevault> grep for rendertarget_mapping
<ddevault> these first few lines should control half-float support
<ddevault> linear is something else
<anarsoul> are you sure you've applied the patch?
<ddevault> aye
<ddevault> wait, no
<ddevault> I might still be running the previous patch version
<ddevault> lemme build things again to be sure
<ddevault> and get that constant fix in while I'm at it
<anarsoul> can you just check the sources in your build dir?
<ddevault> not really
<ddevault> I'm rebuilding the package, and shit gets cleaned up
<ddevault> annoying, I know
<ddevault> okay, the build I'm running now def has the latest patch
<ddevault> will get back to you when it's done
<ddevault> okay, progress
<ddevault> now it shows in es2_info, but the application I'm trying to run still doesn't think it works
<anarsoul> how exactly it decides that it doesn't work?
<ddevault> reading the code now
<anarsoul> (I wonder if it expects fp32 to be working...)
<ddevault> according to author it should work with just half float
<ddevault> reading code to ascertain truth
<anarsoul> I don't think that ver[0] >= 3 :)
<ddevault> aha
<ddevault> shit
<ddevault> wait, it shouldn't matter
<anarsoul> so it doesn't even need float textures
<ddevault> that's just one of several branches here
<ddevault> see the second branch
<ddevault> line 69
<anarsoul> yeah, even if it doesn't have it
<ddevault> the error I get is from the last line of this function, 95
<anarsoul> I don't see why it should fail
<ddevault> well, if all three branches fail, then the triples list is empty
<ddevault> then the for loop iterates zero times and goes to the failure branch
<ddevault> in theory the second branch is working now (will verify), but it could still fail in the loop
<anarsoul> what is tt.internalFormat?
<ddevault> the first member of the struct
<ddevault> so either R16F (first branch) or RGBA (other branches)
<anarsoul> are you sure it still fails there? :)
<ddevault> yep, just verified it
<ddevault> gonna try to extract glError
<ddevault> it hits the second branch and adds the GL_OES_texture_half_float triple
<ddevault> hm, glerror is zero here
<anarsoul> :D
<ddevault> well, it definitely makes it this far
<anarsoul> but st != gl.FRAMEBUFFER_COMPLETE ?
<ddevault> yeah
<ddevault> printing st now...
<ddevault> 36054
* ddevault consults GLES.h
<anarsoul> GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
<ddevault> cheers
<ddevault> but hmm
<ddevault> why
<ddevault> wrong pixel format?
<ddevault> can I crank up lima logging a bit
<anarsoul> I don't think it fails in lima
<ddevault> ah yeah it fails on amdgpu too if I force the second branch
<ddevault> cheers
<anarsoul> LIBGL_DEBUG=verbose <your app>
<ddevault> doesn't add anything of interest
<ddevault> lemme read some specs
<anarsoul> MESA_DEBUG=incomplete_fbo
<anarsoul> or MESA_DEBUG=1 :)
<ddevault> it's almost like it was tailor-made for me <3
<ddevault> except that it doesn't add any details
<anarsoul> likely you built mesa without any debug :)
<ddevault> oh, dur
<ddevault> dammit, here goes another mesa build
<anarsoul> btw you want release build once you're done
<ddevault> course
<anarsoul> otherwise it's gonna be pretty slow
<anarsoul> especially on compiling shaders
<ddevault> at the moment I'm only interested in this device as a development platform
<anarsoul> pinephone I assume?
<ddevault> aye
<ddevault> I have to write quite a bit more code before it's ready to be my daily driver
<ddevault> I want to build gio so that I can use it to write a dialer and maybe an SMS app
<anarsoul> and wait for someone to fix modem audio
<anarsoul> and implement anx7688 driver so usb-c actually works
<anarsoul> and that's probably it?
<ddevault> rig up something nice for alsa, write a new on-screen keyboard, rig up my lock screen better, make idle behavior more configurable in sway, improve power management, find and improve some touch-friendly application launcher
<ddevault> touch bindings for sway
<anarsoul> why there's only 24h hours in a day...
<ddevault> plus SMS & calling app
<anarsoul> can someone make our planet spinning slower? :)
<ddevault> figure out video acceleration
<ddevault> slowing the planet would not slow the passage of time, unfortunately
<anarsoul> that's pretty ambitious plans
<ddevault> in my experience, you just have to start doing them, then people show up and help
<ddevault> and in any case, I'm fine with placing phone calls and sending messages at the terminal
<ddevault> my first SMS program is probably going to store SMS in a maildir and implement a sendmail->sms shim so I can repurpose a mail reader
<anarsoul> :)
<anarsoul> who uses SMS nowadays anyway
<ddevault> this is where I'm at now: https://sr.ht/kPMC.png
<anarsoul> looks good
<ddevault> oh yeah, I have to replace that bar
<ddevault> add that to the list :<
<anarsoul> you may as well start writing your own compositor
<anarsoul> another wlroots based compositor for phones
<ddevault> I am the maintainer of several wayland compositors
<anarsoul> cool
<ddevault> for the moment, I just plan on making some conservative improvements to sway to this end
deesix has quit [Ping timeout: 276 seconds]
<ddevault> I'm sick of writing greenfield wayland compositors -_-
<ddevault> oh, at some point I should also probably find something better than mpv * --shuffle as my audio player
<ddevault> lots to do but I'm still excited about this phone, it's all I've ever wanted from a phone :D
deesix has joined #lima
<anarsoul> anything wayland-based could be used in other distros/environments as well
<anarsoul> not sure I'm ready to replace my android phone with pinephone atm :)
<anarsoul> but who knows, maybe some day
<anarsoul> (I do have pinephone btw)
<ddevault> neither can I, but working towards that goal
<anarsoul> that's definitely exciting times
<anarsoul> ddevault: btw note that using fp16 textures and render targets would be 2x slower than rgba8888
<ddevault> for this use-case it doesn't really matter
<ddevault> but I will pass your warning on to the dev
<anarsoul> it does if you're planning to run full-screen app
<anarsoul> if it uses more memory bandwidth -> it uses more energy -> shorter battery life
<ddevault> only if it redraws often
<anarsoul> yeah, but still
<ddevault> ¯\_(ツ)_/¯
<ddevault> this is not the power performance bottleneck right now
<anarsoul> there's no good reason for using fp textures on mobile devices :)
<ddevault> listen, this guy is saving me from writing my own GUI framework
<ddevault> I can only shave so many yaks
<anarsoul> :)
<ddevault> okay, now have a debug build
<ddevault> _lima_resource_create_with_modifiers: pres=0xaaaaf6fb53e0 width=256 height=256 depth=1 target=2 bind=a usage=0 tile=1 last_level=0
<ddevault> this is the only thing I get while this function is executing
<ddevault> not much here
<anarsoul> and about MESA_DEBUG=1?
<ddevault> that is MESA_DEBUG=1
<anarsoul> and MESA_DEBUG=incomplete_fbo?
<ddevault> no difference
<anarsoul> so it created pipe_resource successfully
<ddevault> just out of curiosity...
<ddevault> nevermind, that was a dead end
<ddevault> but it did allude to the next problem we'll face once this is done with
<anarsoul> try it with MESA_LOG_FILE?
<ddevault> set to? 1?
<anarsoul> to some filename
<ddevault> guessed that, didn't help
<ddevault> digging through the mesa logging code, I'm probably turning it on wrong
<anarsoul> what flags do you build it with?
<ddevault> s/buildtype=release/buildtype=debug/ +my patch
<anarsoul> you also need to drop -Db_ndebug=true
<ddevault> ;_;
<ddevault> see you in 40 minutes
<anarsoul> :)
<anarsoul> setup yourself ccache
<anarsoul> I'm pretty sure it's doable
<ddevault> it's alledgely set up by default in pmbootstrap
<ddevault> but w/e
<ddevault> I have booze, so it's not so bad
<anarsoul> :)
<ddevault> in case you were wondering
<ddevault> the next issue I expect we're going to face is sRGB
<anarsoul> we're faking sRGB support for GL2
<ddevault> why can't people just stick to GLES2 and call it a day
<anarsoul> it's not supported by hw anyway
<anarsoul> see R8G8B8A8_SRGB and B8G8R8A8_SRGB in lima_formats.c
<ddevault> source: I changed the code to pretend that the first attempted triple worked, and got an sRGB error from later in the pipeline
<ddevault> finally something useful
<ddevault> Mesa: attachment incomplete: bad internal format
<ddevault> see src/mesa/main/fbobject.c:909 (grep OES_texture_float)
<ddevault> I could get a little further by just adding PIPE_CAP_VERTEX_COLOR_UNCLAMPED, but I'm not sure what that implies
megi has quit [Ping timeout: 268 seconds]
<ddevault> yes, that works
<ddevault> now we have the sRGB issue
<ddevault> it's looking for GL_EXT_sRGB
<ddevault> by my reading of the code, it should already be there... but it's not
<ddevault> I have a lead, testing it
<anarsoul> hmm
<ddevault> my lead is the lack of an *X8_SRGB format
<ddevault> st_extensions.c seems to be happy with *A8_SRGB
<ddevault> but st_format.c less so?
<ddevault> can't hurt, anyway
<ddevault> grepping for srgb does little on this page
<anarsoul> that's for VERTEX_COLOR_UNCLAMPED
<ddevault> I see
<ddevault> this GPU allegedly supports DX9, so enabling it doesn't seem wrong per-se
<anarsoul> probably
* ddevault isn't sure if he could hedge his bets any harder than that
<anarsoul> I'm not sure why it needs it though
<anarsoul> well, you can run the tests :)
<ddevault> aye
<ddevault> I feel like I'm missing something when it comes to sRGB
<ddevault> st_extensions enables EXT_sRGB if any of the A8B8G8R8 (in any order) pipe formats are supported for SRGB
<ddevault> which lima qualifies for
<ddevault> so why isn't it enabled...
<anarsoul> piglit has glsl-clamp-vertex-color test
<ddevault> ack
<anarsoul> are you sure that sRGB is part of gles2?
<ddevault> not in the slightest
<ddevault> but I am sure that the gio dude is going to make me pry sRGB out of his cold, dead hands
<ddevault> in fact it seems to be part of GLES 1
<anarsoul> I'm not sure why it doesn't get enabled for you
<ddevault> let's see if adding X8 formats helps
<anarsoul> ddevault: btw you should probably build mesa natively (if you have enough storage) and just install it into your local prefix
<anarsoul> that should be more convenient for development
<anarsoul> and then use script like this to set env: https://gist.github.com/anarsoul/92e5db186ea301aa7f84bc35c972b665
<ddevault> yeah, I know how to build mesa
<ddevault> I'm just lazy, I'll set it up tomorrow if this continues until then
<anarsoul> sounds good
<anarsoul> 1.5h for you till tomorrow :)
<ddevault> I'll be asleep by then
<ddevault> if this mesa I'm building now doesn't cut it, I'm done for tonight
<ddevault> did not work
<ddevault> good night!
<ddevault> thanks for all of your help, anarsoul
<anarsoul> np, thanks for working on this
<anarsoul> good night
Barada has joined #lima
_whitelogger has joined #lima
mripard_ is now known as mripard
yann has quit [Ping timeout: 240 seconds]
jernej has quit [Ping timeout: 246 seconds]
jernej has joined #lima
yann has joined #lima
ecloud_ has joined #lima
ecloud_ has quit [Ping timeout: 265 seconds]
megi has joined #lima
chewitt has joined #lima
warpme_ has joined #lima
chewitt has quit [Quit: Zzz..]
<ddevault> morning
<ddevault> update from the gio folks on their use of FP16 and sRGB: https://todo.sr.ht/~eliasnaur/gio/49#event-20021
chewitt has joined #lima
Barada has quit [Quit: Barada]
<anarsoul> ddevault: we may get support for single-channel FP16 textures, but I'm not sure about render targets
<anarsoul> ddevault: as for sRGB: Mali4x0 doesn't support sRGB at all. So we're faking support and rendering will differ on different devices :)
<ddevault> understood
<ddevault> I'm just trying to get fake support to work :)
<ddevault> but first I need to figure out this FP issue. I had gotten past this earlier
chewitt has quit [Quit: Zzz..]
<ddevault> looks like EXT_color_buffer_half_float support will be non-trivial
<ddevault> it seems no mesa drivers support it at all
<ddevault> bleh, I have exhausted my patience for this workstream
<ddevault> if this guy wants gio to work on mobile devices he's going to have to be a lot more conservative with his OpenGL profile
megi has quit [Ping timeout: 250 seconds]
megi has joined #lima
yann has quit [Ping timeout: 252 seconds]
yann has joined #lima
yann has quit [Ping timeout: 245 seconds]
<anarsoul> ddevault: why EXT_color_buffer_half_float will be non-trivial?
<ddevault> because there's no support code for it at all in mesa
<ddevault> unlike EXT_color_buffer_float, which is just plug A into B
<ddevault> there is no A or B for half float
<anarsoul> ddevault: just duplicate EXT_color_buffer_float stuff?
dddddd has joined #lima
<ddevault> maybe
<ddevault> but more than I have time for right now
<anarsoul> ddevault: yeah, I'd say that float textures is quite unusual requirement for UI framework
<ddevault> aye
<ddevault> to be fair, he has his own vector drawing library which is optimize me harder tier
<ddevault> I imagine it's used for that
robher has quit []
robher has joined #lima
<anarsoul> btw, regarding "Are you saying the Lima driver somehow restricts the shader precision to mediump when outputting to a half float fbo"
<anarsoul> fragment shader on Mali4x0 is only mediump
<anarsoul> it doesn't support highp in hardware
<rellla> i'm not sure, if i did texture descriptor right, so any review is appreciated :)
<anarsoul> rellla: I'll look into it later today
<rellla> great
dddddd has quit [Ping timeout: 240 seconds]
deesix has quit [Ping timeout: 252 seconds]
deesix has joined #lima
dddddd has joined #lima
yann has joined #lima
warpme_ has quit [Quit: Connection closed for inactivity]
warpme_ has joined #lima
robertfoss has quit [Ping timeout: 250 seconds]
robertfoss has joined #lima