<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>
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>
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>
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 :-)