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!
jrmuizel has joined #lima
nerdboy has joined #lima
nerdboy has joined #lima
* nerdboy checks off another chromebook soc for panfrost/drm functionality
<anarsoul> wrong channel? :)
<nerdboy> depends on model/gpu?
<nerdboy> even snow has up-scaled gpu compared to pine64
* nerdboy still figuring out which hardware has what kind of "frost"
<nerdboy> also break my habit of saying "lima" for mali hardware
<libv> if only had not tried to stop things by mentioning the word "trademark" after they had seen my first proposal.
<libv> if only ARM, even
jrmuizel has quit [Remote host closed the connection]
camus has joined #lima
kaspter has quit [Ping timeout: 276 seconds]
camus is now known as kaspter
jrmuizel has joined #lima
kaspter has quit [Ping timeout: 265 seconds]
yuq825 has joined #lima
kaspter has joined #lima
romainmahoux[m] has quit [Read error: Connection reset by peer]
Danct12 has quit [Write error: Connection reset by peer]
z3ntu has quit [Read error: Connection reset by peer]
bshah|matrix has quit [Read error: Connection reset by peer]
dllud has quit [Ping timeout: 245 seconds]
romainmahoux[m] has joined #lima
yuq825 has quit [Remote host closed the connection]
yuq825 has joined #lima
dllud has joined #lima
<MoeIcenowy> anarsoul: maybe there's still rendering issues
<MoeIcenowy> on X11 some parts of gtk3-demo cannot be rendered correctly
<MoeIcenowy> (or maybe it's because X11 is spamming us?
<anarsoul> likely there's still some issues :)
<anarsoul> we're not passing neither piglit nor deqp completely
<MoeIcenowy> I am considering to deploy a Pine A64-LTS as piglit playground
<anarsoul> MoeIcenowy: you made another typo
<anarsoul> "reset scissor state *if* scissor test is disabled"
<anarsoul> also add my and Qiang's r-b tags
<MoeIcenowy> oooooooops
gtucker has quit [*.net *.split]
bshah|matrix has joined #lima
z3ntu has joined #lima
Danct12 has joined #lima
<anarsoul> MoeIcenowy: I think it's probably better to set up deqp
* anarsoul is going to try it this weekend
nerdboy has quit [Ping timeout: 240 seconds]
nerdboy has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #lima
gtucker has joined #lima
dllud has quit [Ping timeout: 245 seconds]
dllud has joined #lima
nerdboy has quit [Ping timeout: 264 seconds]
<anarsoul> yuq825: enunes: rellla: any comments on ?
<anarsoul> yuq825: also what's left for ? Why it's still in WIP?
<yuq825> for 1763, still need some test on weaker CPU like H3
<yuq825> that's for find a balanced threshold to re-generate PP stream
<anarsoul> isn't it faster than A64?
Barada has joined #lima
megi has quit [Ping timeout: 276 seconds]
Barada has quit [Quit: Barada]
Barada has joined #lima
<yuq825> I tested 1763 on amlogic s905x, haven't done on H3
<anarsoul> I see
<yuq825> I did test an early version of 1763 on H3, and see some flicker, I guess due to the regenerate pp stream threshold, but recently there's some fix into mesa, so need to test on H3/A64 with 1763 again
<anarsoul|c> Flickering can be due missing fence
<anarsoul|c> So if we do the same for scissors it should greatly improve performance of X11
<anarsoul|c> Currently it suffers due to FB reload, I tried to disable it just to check if it fixes cursor lag - and it does. But unfortunately it makes everything but cursor black.
<anarsoul|c> Well, everything but updated parts of screen
Barada has quit [Quit: Barada]
<yuq825> yes, reload with small scissor like cursor could be optimized like this
Barada has joined #lima
dddddd has quit [Remote host closed the connection]
Barada has quit [Client Quit]
Barada has joined #lima
Barada has quit [Quit: Barada]
tlwoerner has quit [Ping timeout: 268 seconds]
tlwoerner has joined #lima
Barada has joined #lima
<narmstrong> anarsoul: tomeu is adding CI for panfrost, I'll add the necessary to run lima aswell
mardestan has joined #lima
<mardestan> does someone know how many vector registers mali 400mp gpu has?
<mardestan> it seems 6 for normal and 6 for pipelined so 12 alltogether.
Barada has quit [Quit: Barada]
<mardestan> some amount of sm3.0 hardware temporaries
<mardestan> libv: sorry I will leave soon, as everything has been said allready, however i am thinking how can utgard deal with dependencies/hazards?
<mardestan> seems like hardware handles them, but very confused about the number of registers 6*(128/4) does not really equal sm3.0 spec
<mardestan> oops 6*(128/4/4) i meant, it comes up as 48 but should be 32
<MoeIcenowy> yuq825: I think you have some A64?
<MoeIcenowy> just set A64 to the lowest frequency
<mardestan> I am fed up anyways about talking to myself, i think i do not want to help you retarded guys anymore.
<mardestan> i think it is bye by me. You are fucking stupid idiots imo.
mardestan has quit [Quit: Leaving]
Barada has joined #lima
yuq825 has quit [Quit: Leaving.]
mrueg has quit [Quit: - Chat comfortably. Anywhere.]
mrueg has joined #lima
tlwoerner has quit [Ping timeout: 265 seconds]
megi has joined #lima
dddddd has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
adjtm has quit [Ping timeout: 276 seconds]
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 268 seconds]
tlwoerner has joined #lima
<MoeIcenowy> anarsoul: the next blocker to use lima on desktop seems to be `gp error irq state=400000` ?
jrmuizel has joined #lima
Barada has quit [Quit: Barada]
adjtm has joined #lima
<anarsoul> MoeIcenowy: yes
<MoeIcenowy> BTW, does ARM driver has interface for userspace to know kernel-space error info?
<anarsoul> no idea
<Tofe> I wonder, for the scissors for example, the driver always talks in fb coordinates ? it doesn't depend on the application's window buffer or something like that?
<anarsoul> Tofe: fb is actually a surface that it renders into
<anarsoul> it's not /dev/fb*
<Tofe> ah ok, I misunderstood the code, good to know
* bshah closes #101 issue finally \o/
<rellla> anarsoul: is still the tool to get a dump from the blob?
<anarsoul> yeah
<anarsoul> and it's not very convenient, you'll have to parse dumps manually
<anarsoul> i.e. good enough for dumping texture descriptor
<anarsoul> but not so good for analyzing command stream
<rellla> i just want to take a quick look at the outstanding texture things...
<anarsoul> ah, OK
<anarsoul> that would be cubemap
<anarsoul> I have the dump if you need it :)
<rellla> is there any info to rect anywhere already?
<anarsoul> rect is not supported in GLES
<anarsoul> you'll have to emulate it
<rellla> ah
<rellla> that means treat it as 2d with no mipmap?
<anarsoul> it also has coordinates in texels and not in [0,1]
<rellla> yes
<anarsoul> also we can't support rect textures larger than 1024x1024
<anarsoul> we can't sample them accurately enough
<anarsoul> btw, we don't support GL 3.1, can we just disable GL_ARB_texture_rectangle extension?
<rellla> first i have to find out, where the necessary bits have to be added ...
<anarsoul> check git log for panfrost
<anarsoul> they had it few months back till they figured out how to do that in hw
<rellla> ok, emulating rect you mean?
<MoeIcenowy> anarsoul: we cant
<MoeIcenowy> cogl/clutter seems to expect it
<anarsoul> MoeIcenowy: fix cogl/clutter?
<anarsoul> we can't do it in hardware
<anarsoul> emulating it requires manipulation with texture coordinates
<anarsoul> and it automatically brings down precision to fp16
armessia has joined #lima
<armessia> Hi guys
<armessia> I've been looking into adding cubemap support the past few days
<armessia> Have some basic example working
<armessia> Will push my branch later today so you can have a look
<anarsoul> armessia: nice!
<MoeIcenowy> anarsoul: I still think we should emulate it
<anarsoul> MoeIcenowy: it's useless
<anarsoul> if it tries to sample from texture that is larger than 1024 in any dimension rendering will be incorrect
<MoeIcenowy> To be honest, my reason to use mainline driver is to prevent application changing
<anarsoul> MoeIcenowy: it's hardware limitation
<armessia> anarsoul: tnx :-)
<MoeIcenowy> but if the application do not go beyond 1024
<MoeIcenowy> the emulation is still useful
<anarsoul> yeah, and we'll get reports that lima misrenders something
<armessia> The case where the coordinates are coming from register won't work yet, but if the come straight from varying it does/should
<anarsoul> rect textures aren't supported in either gles2 nor gl2
<anarsoul> it's extension for gl2
<anarsoul> hardware doesn't support rect textures
<anarsoul> => driver shouldn't advertise support for this extension
<anarsoul> armessia: it shouldn't be difficult to fix
<armessia> anarsoul: I think so too, will have to have a further look though
nerdboy has joined #lima
nerdboy has quit [Changing host]
nerdboy has joined #lima
<Tofe> So, the reason of my crash is that the driver has a "const" op to execute, but that kind of op doesn't have any slot
<anarsoul> that's surprising
<anarsoul> can yo share the shader?
<Tofe> I'm... not even sure which one is it
<anarsoul> :D
<anarsoul> then record apitrace please
<Tofe> I guess QML has some shaders it uses for some predefined blending or so
<bshah|matrix> Tofe: dump all the shaders? And then grep? :D
<anarsoul> bshah|matrix: grep for what?
<bshah|matrix> There's some env var for it
<anarsoul> you don't know which one results in too many constants in instruction
<MoeIcenowy> Tofe: how do you know this reason?
<Tofe> MoeIcenowy: I have the full crash stack
<MoeIcenowy> Tofe: just use LIMA_DEBUG=gp, and put all the spells to a pastebin
<bshah|matrix> Ah wait, const is not coming from shader... Sorry for noise
<bshah|matrix> Tofe: do you know what In qml/qt triggers that?
<anarsoul> MoeIcenowy: I suspect it's gonna be fragment shader
<Tofe> bshah: if only... it's our phone qml app, but it's a big qml app, so I wouldn't be able to say what exactly. It crashes when we show the window initally
<anarsoul> Tofe: apitrace please
<Tofe> yes yes, one moment, remember I never used that one so far :p
<Tofe> damn, there's no recipe for OpenEmbedded yet it seems
<anarsoul> :(
<Tofe> well, I'll create one, I just hope it'll go smoothly
<Tofe> oh, great, it bundles its own khronos headers, and they make the assumption that unix==X11
<anarsoul> MoeIcenowy: I think lima won't be able to run apps that use cogl/clutter unless it switches to using GL_TEXTURE_2D
<MoeIcenowy> anarsoul: why
<anarsoul> it's not supported by hardware and fp16 precision is not enough to emulate it properly
<anarsoul> MoeIcenowy: Utgard PP support only fp16, that's only 10 bits precision for mantissa
adjtm has quit [Ping timeout: 276 seconds]
<anarsoul> it has special path to use varyings directly as coordinates for sampler instruction, but coordinates have to be normalized, i.e. in 0..1 range
<anarsoul> this special path has fp32 precision
<anarsoul> but once you load varying into register and use register as coordinates for sampler instruction your precision drops to fp16
<anarsoul> and thus only 10 bits
<anarsoul> it results in unreadable text if you use textures for UI
<MoeIcenowy> anarsoul: oops deqp doesn't do well when surfacelsss
<MoeIcenowy> less *
<MoeIcenowy> so it's needed to setup some display and use x11/wayland
<anarsoul> MoeIcenowy: use wayland
<anarsoul> weston should work fine
<MoeIcenowy> the problem is to set up a display ;-)
<anarsoul> I believe you can run headless weston
<MoeIcenowy> currently I hooked an unpowered LCD screen to Pine A64-LTS
<MoeIcenowy> anarsoul: but I doubt whether lima will work on headless weston
<anarsoul> why not?
<MoeIcenowy> here on my PC es2gears_wayland totally fail on headless weston
<anarsoul> hm
<MoeIcenowy> and I think it reasonable to doubt whether acceleration will work on headless "display"
<anarsoul> well, I'm not sure how they do it in gitlab CI
<MoeIcenowy> because it needs the underneath display to allocate buffers
<MoeIcenowy> oh on my PC GLES programs inside headless weston totally doesn't touch GPU
<MoeIcenowy> it uses llvmpipe
<anarsoul> well, looks like CI uses surfaceless
<anarsoul> what's the issue with surfaceless?
<MoeIcenowy> I totally cannot get it to run here
<MoeIcenowy> maybe some special parameters are needed?
<anarsoul> you need to enabled it in mesa as well
<anarsoul> "-D platforms=surfaceless,x11,wayland"
<anarsoul> s/enabled/enable
<MoeIcenowy> I didn't add -D platforms
<MoeIcenowy> auto should infer surfaceless
<anarsoul> and I don't think that it builds surfaceless by default
<anarsoul> yeah
<anarsoul> just checked it
<MoeIcenowy> I remember seeing it doing surfaceless...
<anarsoul> anyway, I'm at work now
<anarsoul> so I can't debug it
<anarsoul> panfrost uses it for CI so it should work
<MoeIcenowy> `EGL/Vulkan/VL platforms: x11 wayland drm surfaceless`
<anarsoul> see src/gallium/drivers/panfrost/ci/
<MoeIcenowy> surfaceless is inferred
<anarsoul> do you have it enabled in deqp?
<MoeIcenowy> yes
<MoeIcenowy> deqp can only select one target once
<MoeIcenowy> but maybe my deqp is too old
<MoeIcenowy> I'm still fetching from googlesources
<anarsoul> maybe
<Tofe> At last ! I got an apitrace !
<Tofe> How do you usually share that kind of file?
<Tofe> So now I see the various shaders involved, but I'm not sure what to look for, that could have ended with this "const" op
<Tofe> Damn, this kind of trace is very interesting
adjtm has joined #lima
<Tofe> The last used fragment shader is ... it looks quite straightforward...
kaspter has quit [Ping timeout: 240 seconds]
<Tofe> There is also a vertex shader, which does some math:
nerdboy has quit [Ping timeout: 258 seconds]
<anarsoul> that's not the one that fails
<anarsoul> Tofe: open an issue and attach the file to it
<Tofe> ok, will do
<anarsoul> Tofe: it looks like it's gpir compiler issue
<anarsoul> could you compile mesa with debug enabled so you keep all the asserts, just to see where it fails?
<Tofe> yes, I'll prepare that
<anarsoul> thanks!
<anarsoul> rellla: you probably want to mark as 'Tested-by' by you :)
<rellla> yeah, right.
<anarsoul> I'd also appreciate if you review
<rellla> i built that one, but didn't look deeper in the code yet. just let piglit run, but thats probably not the place where we should see the benefits?!
<rellla> anarsoul: i will try to have a look at it tomorrow
<anarsoul> thanks
<anarsoul> rellla: it should get rid of OOMs and page alloc failures that we see intermittently
<rellla> hm, maybe i should check that a second time... not that sth went wrong during built. i did many tests yesterday.
<anarsoul> I just pushed rebased version with fixes for few issues I noticed
<anarsoul> rellla: note that you need this kernel patch to use BO cache:
<anarsoul> otherwise it'll OOM badly for you
<rellla> should be applied...
<armessia> It's also working now when getting the coordinates from a register, at least in my test shader
<anarsoul> armessia: I'd suggest running it through piglit
<armessia> Had to create a new ppir_op for handling the register case, don't know if it's the good way of doing it.
<armessia> anarsoul: will try to get piglit up and running, haven't succeeded yet
<armessia> Trying to build it from buildroot might not have been the best idea :-)
<anarsoul> probably it's not
<armessia> What backend do you guys run piglit with? GBM?
<anarsoul> yep
<armessia> alright
<armessia> You run armbian?
<anarsoul> no, I run archlinux
<anarsoul> armessia: I think you shouldn't introduce new op for loading cube coords
<anarsoul> just check number of components, it's gonna be 2 for 2d textures, 3 for cubemap
<anarsoul> (since we don't support 3d textures)
<armessia> Had the same feeling
<armessia> But in the register case num_components is 0 in ppir_codegen_encode_varying?
<armessia> Or have I missed something?
<anarsoul> I believe for register case register itself has num_components set
<anarsoul> you can check it
<armessia> Tnx for the hint, will look into it tomorrow
<armessia> Will also try to get piglit up and running on arch
<anarsoul> what board are you using?
<armessia> Orangepi one (H3)
<armessia> Also have an orangepi PC2 (H5) lying around, but haven't tested lima on it yet
<anarsoul> if you're going to use native compilation I'd suggest to use faster board
<armessia> yeah native compiling will be an issue I guess, slow to say the least
<armessia> I'll look into setting something up to cross-compile, but haven't done that yet outside of buildroot or kernel compilations.
<anarsoul> it's OKish with ccache on A64
jrmuizel has quit [Remote host closed the connection]
armessia has quit [Quit: Leaving]