<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.
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
<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
<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