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!
dri-logger has quit [Ping timeout: 265 seconds]
megi has quit [Ping timeout: 268 seconds]
dddddd has quit [Remote host closed the connection]
Barada has joined #lima
Barada has quit [Quit: Barada]
dddddd has joined #lima
Barada has joined #lima
yann has quit [Ping timeout: 240 seconds]
yann has joined #lima
jorik__ is now known as jonkerj
megi has joined #lima
Elpaulo has joined #lima
mrueg has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mrueg has joined #lima
megi has quit [Ping timeout: 250 seconds]
Barada has quit [Quit: Barada]
megi has joined #lima
yann has quit [Ping timeout: 268 seconds]
yann has joined #lima
robertfoss has quit [Ping timeout: 276 seconds]
robertfoss has joined #lima
dddddd has quit [Remote host closed the connection]
ddevault has joined #lima
<ddevault> greetings
<ddevault> what're the odds of getting OES_texture_float/OES_texture_half_float enabled for lima?
<ddevault> ARB_texture_float seems to be mentioned, which makes me think it's in the cards
<anarsoul> why do you need it?
<ddevault> it's used by gio
<ddevault> I don't know exactly why they need it, but they aren't enthused about working around its absence
<ddevault> after a slightly deeper dig into lima, it's less obvious than I hoped
<ddevault> continuing to dig
<anarsoul> it shouldn't be too difficult to add fp textures
<anarsoul> in theory if you add them to lima_format.c it should just work
<anarsoul> wanna try a patch?
<ddevault> I was looking for docs which might suggest how lima_format.c's magic values come into being
<ddevault> if I grok that then I could write a patch
<ddevault> was looking at panfrost for inspiration, since it supports fp textures, but it's a bit different
<ddevault> lovely
<anarsoul> so 0x26 is RGBA FP16
<anarsoul> 0x2F seems to be RGB FP16
<ddevault> half float, then
<ddevault> doesn't seem to be full float
<anarsoul> I don't think that it supports FP32 since PP is FP16 only
<ddevault> no worries
<ddevault> half float also gets me what I want
<anarsoul> so be careful with fragment shaders :)
<ddevault> :)
<anarsoul> it's always FP16
<anarsoul> mediump
<anarsoul> A FP16 and L FP16 are also available
<ddevault> A? L?
<anarsoul> alpha, luminance
<ddevault> ah, alpha/luminance
<anarsoul> and I for intencity IIRC
<anarsoul> and AL FP16 :)
<ddevault> dumb question: what's the difference between pixel and texel formats
<anarsoul> pixel for rendering, texel for sampling
<ddevault> do you know how I should decide which texel format to pair with this pixel format?
<anarsoul> well, you have to associate it with pipe format
<anarsoul> and I'm afraid it's not renderable, so no pixel format
<ddevault> oh, these are texel formats
<ddevault> there wouldn't happen to be a page like this for pixel formats...
<ddevault> not really groking this yet. I suspect I put in NONE and hope that it's enough
<ddevault> a vain hope, I expect
<anarsoul> should be fine if you don't need to render into fp16
<anarsoul> if you actually need to render into it, you'll have to do reverse engineering :)
<ddevault> last question, at least until I compile and test this: how do I determine if R and B need to be swapped
<ddevault> aside from testing it and noticing shit's funky
<anarsoul> ddevault: it's obvious: mali4x0 doesn't support BGR formats natively, you need to use RGB format and set a flag to swap R and B
<ddevault> I've never written a GPU driver patch before, thanks for your patience with my dumb questions
<anarsoul> so if you need to render into float formats I'd just suggest to try different values for pixel format - 0x0 to 0x20 that are not used yet
<anarsoul> np
<anarsoul> or rather 0x0 to 0x1f
<ddevault> sounds good
<ddevault> bleh, I will have to do that
<ddevault> looks like gio is rendering to this fb
<anarsoul> there's LIMA_PIXEL_FORMAT_RGBA64
<anarsoul> I have suspicion that it's actually FP16
<ddevault> music to my ears
<ddevault> let's try it
<ddevault> 0x26 lines up with the texel format number, fwiw
<ddevault> but that's not true of any other combination, so it's probably meaningless
<anarsoul> likely it is
<anarsoul> it looks like enum, not a bitfield to me
<anarsoul> so just add handling for PIPE_FORMAT_R16G16B16A16_FLOAT and PIPE_FORMAT_R16G16B16_FLOAT
<anarsoul> latter is likely not renderable
<ddevault> good news is that I confirmed the software I want to run works fine with half floats alone
<anarsoul> it's a good idea to handle PIPE_FORMAT_A16_FLOAT, PIPE_FORMAT_L16_FLOAT, PIPE_FORMAT_L16A16_FLOAT and PIPE_FORMAT_I16_FLOAT
<anarsoul> please don't forget to submit an MR when you're done
<anarsoul> :)
<ddevault> naturally :P
<ddevault> I hope you don't think I want to run a hand-patched mesa forever
<ddevault> yuck
<ddevault> do you know what the ro column in this table means?
<anarsoul> see LIMA_FORMAT macro
<ddevault> for the TEXEL_FORMAT macros, would you prefer _FP or _FLOAT
<anarsoul> I'd suggest to stick to pipe format naming convention
<ddevault> seems fair
<ddevault> it's inconsistent now so was worth asking
<anarsoul> yeah, it definitely needs a clean up
<anarsoul> feel free to do that if you're up for it, but as a separate commit
<ddevault> of course
<ddevault> but it does not unfortunately seem to get me OES_texture_float
<anarsoul> likely you need to enable PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR in lima_screen.c
<ddevault> or half_float, rather
<anarsoul> yeah
<ddevault> there are no other PIPE_CAP_TEXTURE_* here
<ddevault> my previous understanding of this file was
<anarsoul> so you need PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR
<ddevault> okay cool this answers my question
<ddevault> thanks