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 and - Contact ARM for binary driver support!
kaspter has joined #lima
<anarsoul|c> Looks like you didn't build lima or kmsro
<anarsoul|c> So it uses llvmpipe
Barada has joined #lima
Barada has quit [Quit: Barada]
Barada has joined #lima
Barada has quit [Client Quit]
<adema> I believe I built lima, I have the dri library installed in /usr/lib/dri/
<linkmauve> adema, you also need kmsro, otherwise you won’t be able to allocate buffers for display and such.
<adema> I have /usr/lib/gallium-pipe/
<adema> is that not enough? Sorry for knowing actually nothing about mesa / lima :/
<linkmauve> I don’t have that, but here I have /usr/lib/dri/ which is the one I need for my Allwinner SoC.
Barada has joined #lima
Barada has quit [Quit: Barada]
<adema> not recently I have to admit
<adema> I thought that repository was obsolete since lima got merged into mesa :/
<enunes> this one is just a readme page
<adema> going to read it :)
<adema> -Dplatforms=drm is not supported anymore right?
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #lima
<ahiemstra> am I reading correctly that it states all shader operations are done using fp16?
<enunes> ahiemstra: for the most part yes due to the mali400 limitations, for textures there is an optimized path if you dont do math on texture coordinates in your shader, but otherwise everything falls back to fp16, including integers
<ahiemstra> right, that probably explains the problems I'm having
<ahiemstra> time to do a cpu implementation of my shader I suppose to see if I can figure out where things are failing exactly
<enunes> yeah the mali400 must be seeing all sorts of applications it was never even remotely designed for
<enunes> adema: I guess it was made built-in and no longer an option a while ago but there was just a warning, does it throw an error now?
<enunes> it does apparently
<enunes> well remove 'drm' from that list then, I'll take it out of that helper doc in the next revision
kaspter has quit [Quit: kaspter]
<linkmauve> ahiemstra, you could use llvmpipe, which will do fp32 and integer.
<ahiemstra> in this case it's in a library, having that force llvmpipe on the user isn't really nice
<ahiemstra> but yes, if I can't figure out a good fallback that's probably going to be what needs to be done
<enunes> what sort of problems does it have?
<ahiemstra> basically, I have a shader that renders a line using a signed distance field, this works fine on many systems but on the pinephone it ends up rendering a blocky, way too thick line
<ahiemstra> after trying a bunch of things the only thing I could conclude is that there's a loss of precision at some point
<ahiemstra> this is how it ends up looking on pinephone:
<enunes> do you have another one of how it is supposed to look like?
chewitt has joined #lima
<ahiemstra> not of the same application
<ahiemstra> but this is the example application running on my desktop
<ahiemstra> and this is how that looks on the pinephone
<enunes> oh wow, that doesn't look like a precision thing at a first glance
<enunes> is this GLES2 or GL? now would also be good to know more details about what features or tricks are being used to render that
<ahiemstra> GLES2
<ahiemstra> and the full chart shader is somewhat complex (probably a bit too much for the mali in the first place) but I reduced things to just a line segment which already had the issue
<ahiemstra> for the line segment, basically what it does is calculate the distance from the pixel to the line and based on that distance determine how much color the pixel should have
<ahiemstra> point here is a uv coordinate
<ahiemstra> thing is, if I play around with the `* 100` in the c assignment I start to see artifiacts as the multiplier goes up, which is why I though it would be a precision issue
<enunes> those are rendered as triangles or lines?
<ahiemstra> it's a fragment shader that's applies to a plane, there's no geometry involved
<enunes> huh ok, then I guess I agree it is fairly complicated to throw as a fragment shader
<anarsoul> ahiemstra: that just won't work on fairly large render targets (I'd say 256x256) due insufficient precision
<anarsoul> with fp16 you have 10 bits of mantissa, so you have enough precision to address up to 1024 pixels, but you'll start loosing precision once you do some calculations
<ahiemstra> right\
<ahiemstra> that's what I was afraid of
putti_ has joined #lima
Putti has quit [Read error: Connection reset by peer]
<marex> enunes: anarsoul: this GPU module section seems to have complete register bits for the mali400 in zynqmp, interesting
<marex> but well, this sucks ... ... the ZynqMP has one clock gate for I guess GPU and one for each PP
<anarsoul> marex: interesting, thanks
<marex> anarsoul: sure, maybe its useful
<marex> who knows
<anarsoul> did ARM allow to list it there?
<marex> anarsoul: better download it before xilinx decides there is too much documentation ^_^'
<marex> anarsoul: well, I dunno ...
<marex> anarsoul: the stupid thing about ug1087 from xilinx zynqmp is that to my knowledge, there is no PDF of it :(
<marex> anarsoul: I would expect that a SoC vendor did clear it with ARM
<anarsoul> I'm not sure if it's a good idea to use it then since we don't want lima to be taken down by ARM
<marex> anarsoul: apparently its been there for two years
<marex> anarsoul: how does one check whether it is OK to use it or not ? ask xilinx ?
<adema> If it's publicly available on the internet, why would it not be ok to use it?
<marex> anarsoul: also, this kind of argument could be stretched to the point where you won't be able to use any SoC datasheet which lists registers to develop code, because how can you know the SoC vendor could list the register bits in that datasheet ?
<adema> once you've read it, you cannot un-read it and forget right?
<marex> sometimes I wish I could un-read some datasheets and code :-)