Blikje has joined #maemo-leste
L29Ah has quit [Ping timeout: 268 seconds]
uvos has quit [Ping timeout: 268 seconds]
Blikje has quit [Ping timeout: 256 seconds]
L29Ah has joined #maemo-leste
freemangordon1 has joined #maemo-leste
freemangordon has quit [Read error: Connection reset by peer]
Pali has quit [Ping timeout: 256 seconds]
zhxt has quit [Ping timeout: 268 seconds]
zhxt has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 240 seconds]
macros_ has joined #maemo-leste
mardy has joined #maemo-leste
mardy has quit [Client Quit]
mardy has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
Twig has joined #maemo-leste
<mighty17[m]> does video accl work out of box for omap4?
<mighty17[m]> (its a mess with ducati :P)
xmn has quit [Quit: ZZZzzz…]
rafael2k has joined #maemo-leste
<freemangordon1> Wizzup: about llvmpip capture, who is rendering using llvmpipe?
<freemangordon1> X or hildon-desktop
<freemangordon1> ah, hildon-desktop
<freemangordon1> Wizzup: what I see in those traces is that 2D rendering is incomplete by the time application texture is rendered to back buffer
<freemangordon1> what's with my nick?!?
freemangordon1 is now known as freemangordon
<freemangordon> Wizzup: so, could you replace glFlush calls in glamor with glFinish and retry? or, use llvmpipe in glamor.
<freemangordon> hmm, hmm, no, looks something is wrong with scissor
<Wizzup> hi
<Wizzup> mighty17[m]: out of the box on what?
<freemangordon> Wizzup: hi
<Wizzup> hi
<freemangordon> Wizzup: I am looking at llvmpipe capture
<mighty17[m]> Wizzup: well, espresso (the tab) with omap2plus_defconfig ig
<Wizzup> freemangordon: right
<Wizzup> mighty17[m]: well it's a complicated question since it can refer to many things, iirc you need dts setup, clocks correct, userspace and X set up, etc etc
<Wizzup> mighty17[m]: but you've been working on this so that further makes me not understand :D
<mighty17[m]> Wizzup: i just mean video playback (ie decoding?)
<freemangordon> Wizzup: so, if you look at frame 22
<freemangordon> Wizzup: do you have 5 minutes now?
<freemangordon> we can postpone that for later on
<Wizzup> freemangordon: I have time now
<Wizzup> you want me to look using qapitrace that is llvmbacked right
<freemangordon> yes
<freemangordon> hmm
<freemangordon> wait, I think this will take as more tim
<freemangordon> *time
<freemangordon> 5 minutes will not be enough
<freemangordon> I have really 5 minutes now and have to go shopping
<freemangordon> ok, we made a deal with GF, she will go alone :)
<Wizzup> don't mean to disturn :)
<freemangordon> no, it is ok
<Wizzup> ok
<Wizzup> mighty17[m]: no, we haven't focussed on that at all
<freemangordon> so, please open llvmpipe trace in qapitrace
<Wizzup> yes, but should my qapitrace be llvmpipe backed as well?
<freemangordon> doesn;t matter
<Wizzup> ok
<freemangordon> I think
<Wizzup> it renders differently with amdgpu than with llvmpipe
<Wizzup> I will use llvmpipe with it
<freemangordon> with llvmpipe qapitrace it renders fine, right?
<Wizzup> yes
<freemangordon> no, we want the proken rendering
<Wizzup> ok
<freemangordon> *broken
<Wizzup> frame different already has a different result it looks likle
<freemangordon> hmm?
<freemangordon> can't parse
<Wizzup> I am looking at frame 20 :-)
<Wizzup> qapitrace renders it differently with different renderers
<Wizzup> is all I am saying
<freemangordon> yeah, I think frame 19 is the first broken one
<mighty17[m]> Wizzup: oh alrighty!
<Wizzup> freemangordon: ok, do you want me to just type what I see or wait for specific requests
<freemangordon> Wizzup: my idea is to try to understand where data uploaded with glTexSubImage2D disappears
<freemangordon> I mean - to try to analyze frames 19- together in an attempt to understand WTF is going on
<freemangordon> too bad we can't see the contents of texture 106
<freemangordon> oh, actually we can
<freemangordon> look at call 2205
<freemangordon> you can export the data from there and open it with gimp
<Wizzup> ok
<Wizzup> so the glTexSubImage2D call
<Wizzup> you want me to click export and look at the data
<Wizzup> most of the data is nan
<freemangordon> this is unsigned byte, not float ;)
<Wizzup> oh
<freemangordon> this is RGB data
<freemangordon> so, you can export and open with gimp
<freemangordon> as 'raw' image
<Wizzup> ok
<freemangordon> glTexSubImage2D call gives you the dimensions
<Wizzup> ok
<Wizzup> I have it open
<Wizzup> it is osso-xterm contents
<freemangordon> mhm
<freemangordon> and looks correct
<freemangordon> now, what I think we should look for, is why this texture (106) contents is not correctly updated
<freemangordon> I would say glTexSubImage2D is broken
<Wizzup> when can I see this texture?
<freemangordon> unfortunatel apitrace is not smart enough it seems
<freemangordon> to track textures
<freemangordon> you can;t see it
<freemangordon> but, we can decide what it's contents is based on glTexSubImage2D calls
<freemangordon> Wizzup: so, texture 106 is osso-xterm texture and I see no FBO attached to it
<freemangordon> so, the only way this texture can be changed is by glTexSubImage2D, IIUC
<freemangordon> to me, at the end of frame 19, both framebuffer and texture 106 are correctly rendered, agree?
<Wizzup> let me check
<Wizzup> no
<Wizzup> the framebuffer is not correct, or rather, it is different between llvmpipe and amdgpu
<Wizzup> amdpgpu renders some random artifacts of hildon-home
<Wizzup> on framebuffer
<Wizzup> on llvmpipe it is the terminal
<freemangordon> NV here renders it fine
<freemangordon> this is call 2329
<Wizzup> I was looking at 2330
<Wizzup> 2329 is ok
<rafael2k> morning - the 5.15 for pp is here: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 - I'm trying to import it to my pine64-linux under name maemo-kernel-5.15
<freemangordon> no, this is the 'new' buffer what you see there
<Wizzup> freemangordon: ok
<freemangordon> like, framebuffer after the swap
<Wizzup> rafael2k: did you try my git instructions?
<freemangordon> ofc it is not ok
<rafael2k> Wizzup: just woke up, not yet - still downloading the repo from github
<freemangordon> so, now (2330) we have good front buffer and texture 106 with correct contents
<Wizzup> freemangordon: presumably, I can't check out the texture atm, but if it was used to render the result then yes
<Wizzup> freemangordon: as in I don't see texture 106 anymore but I guess it was freed or something
<freemangordon> it was used in call 2236
<freemangordon> no, 106 is not deleted
<freemangordon> it is just that apitrace does not show it for us
<Wizzup> ok, it is also not in the gl state
<freemangordon> yes, because it is not current
<Wizzup> ok
<freemangordon> but I dont see it deleted
<Wizzup> ok
<freemangordon> sec, need some coffee
<Wizzup> same..
<Wizzup> there's this car alarm that has been beeping every 5 seconds for the whole night
<freemangordon> :(
<freemangordon> ok, so at the very beginning of frame 20 we have another glTexSubImage2D upload to texture 106
<freemangordon> call 2333 that is
<rafael2k> Wizzup: did not work the git command, I get fatal: ../sunxi64-linux/.git: '../sunxi64-linux/.git' is outside repository at '/home/rafael2k/programs/pinephone/pine64-kernel'
<rafael2k> git add remote mobian-5.15 ../sunxi64-linux/.git
<Wizzup> rafael2k: please search around on how to do it, it can be done
<Wizzup> freemangordon: let me look
<freemangordon> which uploads a 720x29 black rectangle at 0,182
<Wizzup> hm
<Wizzup> yeah, mostly black rectangle
<Wizzup> it also contains white
<freemangordon> not here
<Wizzup> are you looking at the frame data?
<Wizzup> vertex ata*
<freemangordon> no, I am looking at the exported data
<Wizzup> rafael2k: I can help later but not atm
<freemangordon> yes, vertex data
Blikje has joined #maemo-leste
<Wizzup> freemangordon: so vertex data starts with this for me: 0) [255, 255, 255, 255]
<freemangordon> yeah, correct
<Wizzup> that is white, not black
<Wizzup> but ok
<freemangordon> right
<Wizzup> it doesn't really matter I think
<freemangordon> mhm
<rafael2k> Wizzup: no rush with this
<freemangordon> Wizzup: so in call 2356 this is rendered to framebuffer
<Wizzup> rafael2k: you just need absolute path
<rafael2k> Wizzup: tks
<Wizzup> freemangordon: looking at the code it seems to do glTexSubImage2D, some scissor stuff, and then calls glBindTexture on 106 again, should it not do anything else?
<Wizzup> can it just call bind again?
<freemangordon> yes
<freemangordon> this is fibe
<freemangordon> *fine
<Wizzup> I guess the glEnable for gl_scissor_text makes it draw on the texture?
<freemangordon> as I said, texture is not deleted, so it is a valid object
<freemangordon> no
<freemangordon> scissor puts 'boundaries' on the target FBO and nothing gets rendered aoutside those
<freemangordon> *outside
<Wizzup> ok
<freemangordon> Wizzup: could you compare the visual contents of back buffer at start of frame 20 between amd and llvmpipe?
<Wizzup> at the glPixelStore?
<Wizzup> so 2331?
<freemangordon> yes
<freemangordon> I think the diff comes from frame 18, but still
<Wizzup> totally different
<Wizzup> it's just like after the swap call
<freemangordon> yes, exactly
<freemangordon> but, I see 720x720 osso-xterm
<freemangordon> not 720x1384 xterm
<freemangordon> and clutter seems to only draw the difference
<Wizzup> GL_BACK for me is 800x1440
<Wizzup> are you talking about something else?
<freemangordon> yes, but the osso-xterm there is 720x720
<freemangordon> or somesuch
<Wizzup> oh, right
<Wizzup> the initial height
<rafael2k> Wizzup: better I leave this git messing up with someone who knows what is doing - I'll focus on the kernel setup / tesing
<freemangordon> Wizzup: look at call 2082
<Wizzup> freemangordon: ok
<Wizzup> freemangordon: yeah so GL_BACK is still 800x1440 but the terminal isn't that size yet
<freemangordon> right
<freemangordon> GL_BACK is the size of the screen
<Wizzup> yeah
<freemangordon> not really important
<Wizzup> ok
<freemangordon> but, what I think happens is that we have difference in osso-xterm images between 2 back buffers
<freemangordon> now, the question is why this does not bother llvmpipe rendering
<Wizzup> or nvidia
<freemangordon> on nvidia rendering is broken too
<Wizzup> not for meridion
<Wizzup> he also tested it
<Wizzup> but could perhaps be coincidence in buffer mgmt or something maybe
<Wizzup> freemangordon: when you write 'we have a difference in osso-xterm images between 2 back buffers', what do you mean exactly
<Wizzup> I guess you're suggesting that mesa considers the back buffers fair game to change them in the meantime and we expect it not to changfe
<Wizzup> to drawing only the difference then gets broken?
<Wizzup> s/to/so/
<freemangordon> Wizzup: rather - "clutter expects back buffers to be equal but they are not because application window has not been resized when first texture upload happened"
<freemangordon> clutter expects equal initial condition
<freemangordon> *conditions
<freemangordon> I guess this could happen because pp is very fast
<Wizzup> hm
<freemangordon> Wizzup: can we have some online mtg, I cannot run llvmpipe retrace here
<freemangordon> I would like to see you screen share of frame 18
<Wizzup> sure
<Wizzup> I'll send you a msg
<freemangordon> no audio/vide, just screen share
<Wizzup> yeah ok
<freemangordon> I have no camera/mic here attached anyways :)
<freemangordon> yes :)
<Wizzup> ok
<freemangordon> so, it is the same on llvmpipe
<Wizzup> the apitrace on the right is llvmpipe
<Wizzup> (rendered)
<freemangordon> yeah
<Wizzup> ok
<freemangordon> I can't see the framebuffer
<freemangordon> thanks :)
<freemangordon> so, those are same, no?
<Wizzup> yeah
<freemangordon> ok, can we see what happens in frame 20?
<Wizzup> what call?
<freemangordon> call 2356
<freemangordon> not possible :)
<freemangordon> can we check @2331
<freemangordon> here
<freemangordon> see framebuffer contents
<Wizzup> different terminal sizes
<freemangordon> right
<freemangordon> could you check on the previous call?
<freemangordon> last one of frame 19
<freemangordon> swapbuffers one
<freemangordon> how's that possible?
<freemangordon> I would say qapitrace lies to us
<Wizzup> hm, why?
<freemangordon> I mean - this is the same buffer @start of frame 20, no?
<Wizzup> right
<freemangordon> but those were different 2 minutes ago :)
<freemangordon> ugh
<Wizzup> looks like they are different after glPixelStorei
<Wizzup> or do I misunderstand?
<freemangordon> glPixelStorei should not make any change to the framebuffer
<freemangordon> it just sets the format for GlTexImage etc
<Wizzup> ok
<Wizzup> well the behaviour is the same every time within qapitrace at least
<freemangordon> but!
<freemangordon> the right framebuffer cannot be correct
<Wizzup> the llvmpipe rendered one?
<freemangordon> yes
<Wizzup> weird, that is the correct though, for us
<freemangordon> because we uploaded 720x720 osso-xterm texture
<freemangordon> how this come to be fullscreen?
<Wizzup> are you confusing frame 18 and 19?
* freemangordon checks
<Wizzup> in frame 18 it is small
<Wizzup> in frame 19 it is normal size
<freemangordon> no
<freemangordon> which call in frame 18 that is?
<freemangordon> ah, right
<freemangordon> we uploaded 720x720 in frame 18
<freemangordon> this become front buffer in frame 19
<freemangordon> and become back buffer again in frame 20, right?
<freemangordon> unless we do 3-buffer
<freemangordon> maybe check the pointer
<freemangordon> parameterg of swapbuffers
<Wizzup> ok
<Wizzup> looks like only two pointers
<freemangordon> yeah, we have 2 buffers only
<Wizzup> the same order every time
<freemangordon> mhm
<freemangordon> so, how 720x720 from frame 18 backbufer become fulscreen in frame 20
<freemangordon> ?
<freemangordon> this one, yes
<freemangordon> that drawarrys, which texture uses?
<freemangordon> the one that draws it "correctly"?
<Wizzup> which drawarrays
<freemangordon> the one that draws correct osso-xterm on llvmpipe
<freemangordon> 2261 I thin
<freemangordon> *think
<freemangordon> could you click on the previous one?
<freemangordon> previous?
<freemangordon> hmm, this is frame 19
<freemangordon> things here are correct
<freemangordon> we shall look at either 18 or 20
<freemangordon> Wizzup: I mean - can you find the glDrawArrays call that magically turns 720x720 to fullscreen
<freemangordon> on llvmpipe retrace
<Wizzup> I don't think that happens, there is a glclear and then another draw
<Wizzup> in frame 19
<freemangordon> but how then we start with correct back buffer in frame 20?
<freemangordon> frame 19 is ok
<Wizzup> not sure
<Wizzup> brb 1 minute
<Wizzup> b
<freemangordon> hmm
<freemangordon> where is that uploaded?
<Wizzup> which one?
<Wizzup> for the record I added filtering to only show certain events
<freemangordon> yeah
<freemangordon> which call uploads 720x720 texture
<Wizzup> in frame 18?
<freemangordon> mhm
<Wizzup> 1941?
* freemangordon checks
<freemangordon> no, that's the draw
<freemangordon> not the upload
<freemangordon> so, it is texture 66
<Wizzup> how do you know? sorry
<freemangordon> we want either glTexSubImage2D or glTexImage2D call
<freemangordon> those upload image data
<Wizzup> I don't see the call that uploads texture 66
<freemangordon> maybe it is 67, I am trying to find
<freemangordon> 1016
<freemangordon> is the first upload
<freemangordon> I think 1193
<freemangordon> yep, this is it
<freemangordon> osso-xterm in landscape
<Wizzup> ok
<freemangordon> this is 66
<Wizzup> I think I am losing track of what we are investigating
<freemangordon> :)
<freemangordon> Wizzup: I want to understand how that lanscape 1440x594 texture becomes fullscreen portrait
<freemangordon> texture 66 that is
<Wizzup> ok, but it shouldn't ever touch a swapped out buffer,no?
<Wizzup> oh, hm
<Wizzup> I guess some frames in the middle are like the start animation
<freemangordon> yeah
<freemangordon> ok, afk for a while, lunch
<freemangordon> brb
<Wizzup> ok, I'll close the screen sharing for now
<freemangordon> ok
<freemangordon> Wizzup: to me call 2338 is wrong
<Wizzup> the glScissor call?
<freemangordon> yes, to me all glScissor calls are wrong
<Wizzup> ok, do you mean they do not have the right arguments
<freemangordon> yes
<freemangordon> I think we shall render the whole texture
<freemangordon> not only part of it
<freemangordon> if we take frame 20 as example
<freemangordon> call 2356 should have scissors with the size of the texture, not the size of the canged part
<freemangordon> *changed
<freemangordon> at least that's my understanding
<Wizzup> ok
<freemangordon> could you capture the same trace from within VM
<freemangordon> ?
<Wizzup> I need to take a break now, brb
<freemangordon> ok
<Wizzup> uh
<freemangordon> I can do it too
<Wizzup> ok
<Wizzup> ty
<freemangordon> later on
<Wizzup> brb
<Wizzup> b
<freemangordon> Wizzup: to me it seems llvmpipe retrace ignores scissors, that's why it renders correctly
<Wizzup> ah
<freemangordon> this is a bug though :)
<Wizzup> just to be clear by the way, this might only be a bug for the fallback path?
<Wizzup> (there TFP is not available?)
<Wizzup> s/there/where/
<freemangordon> this is a bug in mesa
<Wizzup> right, I mean, a bug in mesa llvmpipe
<freemangordon> mesa/llvmpipe
<freemangordon> yeah
<Wizzup> interesting, given that the nvidia binary driver also has the problem
<freemangordon> what do you mean "has the problem"
<freemangordon> I see corrupted rendering here as well
<freemangordon> because it obeys scissors
<freemangordon> but, I think we shall focus on TFP path
<freemangordon> there we have broken textures
<freemangordon> and this I would say is a bug in either glamor or in lima
<freemangordon> basically, 2D path
<Wizzup> phone sec
<Wizzup> freemangordon: uh
<Wizzup> so the llvmpipe trace file is not using TFP, agreed?
<Wizzup> I think we ought to fix that first
<Wizzup> and then look at potential bugs in the TFP path
<freemangordon> yes, it is not using TFP
<freemangordon> but, TFP is extension which is either supported or not
<freemangordon> we cannot 'fix' it
<Wizzup> so the scissor calls are not wrong?
<freemangordon> in TFP path?
<Wizzup> no, in the path we were looking at together
<freemangordon> this is non-TFP path
<Wizzup> yes
<Wizzup> let me clarify
<freemangordon> I think those calls are wrong
<Wizzup> we looked at non-tfp path, and we found a bug, maybe, I think it is worth fixing
<freemangordon> not really
<freemangordon> we should not be using fallback path
<freemangordon> this ruins the performance
<freemangordon> basically, this leads to glReadPixels afaik
<Wizzup> maybe, but lima with fallback path is already much better if we fix it I think
<freemangordon> no, we shall fix TFP path
<Wizzup> I am not saying we shouldn't look at the other problem
<Wizzup> but keeping this path broken seems silly
<Wizzup> then we should just not have it at all
<freemangordon> I agree, but this should not be used anyways
<Wizzup> it is being used in my VM and probably most VMs that people use, as well as upon initial bringup of most devices
<Wizzup> but I shall not try to argue the merits of fallbacks now
<freemangordon> Wizzup: at least on vmware and vbox it is TFP that is used
<Wizzup> I think your setup is special, the one we recommend on the wiki is not acceleration (but still fast on modern cpu)
<Wizzup> my vm:
<Wizzup> user@devuan:~$ glxinfo |grep -i 'renderer string'
<Wizzup> OpenGL renderer string: llvmpipe (LLVM 7.0.1, 256 bits)
<freemangordon> does it have GL_OES_EGL_image_external?
<freemangordon> es2_info | grep external
<freemangordon> GL_RENDERER: llvmpipe (LLVM 7.0.1, 256 bits) :p
<freemangordon> and yes, we have GL_OES_EGL_image_external
<freemangordon> which is TFP
zhxt has quit [Ping timeout: 256 seconds]
<Wizzup> we don't check for that extension in clutter
<freemangordon> sure we do
<freemangordon> sec
<Wizzup> we look for EGL_NOKIA_texture_from_pixmap and EGL_KHR_image_pixmap
<freemangordon> hmm
<Wizzup> G_MESSAGES_DEBUG=all (or w/e the env var is called) will show if it doesn't find them
<freemangordon> GL_OES_EGL_image
<freemangordon> but yeah
<Wizzup> so pretty sure vm uses fallback path
Pali has joined #maemo-leste
<Wizzup> but can check now if you want
<freemangordon> if you can capture trace, it will be perfect
<freemangordon> I will do it later on if not
<Wizzup> (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_init: checking for texture_from_pixmap
<Wizzup> (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_init: checking for EGLImage 'texture from pixmap' ability
<Wizzup> (/usr/bin/hildon-desktop:4149): ClutterEGL-DEBUG: 13:31:05.368: clutter_eglx_texture_pixmap_update_area: Falling back to X11
<freemangordon> ok
<Wizzup> I can capture a trace but it will be just like me other llvmpipe one
<freemangordon> ok, but if we cannot reproduce int the VM I am afraid it will be very hard to fix
<freemangordon> maybe I shall try another renderer/driver
<freemangordon> or in vmware
<freemangordon> iirc it is not using llvmpipe
<Wizzup> you have a pinephone, no?
<freemangordon> yes, I have
<Wizzup> but please be more clear about 'if we cannot reproduce it'
<freemangordon> if we cannot reproduce broken rendering
<freemangordon> in the VM
<Wizzup> if the scissor calls are wrong, we could attempt to fix, trace that result and rerun on amdgpu or something
<freemangordon> understand, but this will be really hard
<Wizzup> let me think about some other ways
<Wizzup> does xnest support 3d/mesa?
<freemangordon> ok, so we have the broken an all but llvmpipe, right?
<freemangordon> *that broken
<Wizzup> and meridion's nvidia binary driver
<Wizzup> per the apitrace image dumps
<freemangordon> weird
<Wizzup> fwiw I am fine with looking at the TFP bug now, just wanted to make it clear that we make widespread use of the fallback path
<freemangordon> yeah, agree
<freemangordon> hmm, I doubt nvidia driver ignores scissirs
<freemangordon> *scissors
<Wizzup> it looks like xephyr/xnest doesn't do hw accel rendering, only sw (so llvmpipe)
<freemangordon> maybe we shall capture on d4
<Wizzup> I tried that
<Wizzup> apitrace segfaults
<Wizzup> in our pvr mesa so
<freemangordon> I remember I sent a patch for that ;)
<Wizzup> to apitrace?
<freemangordon> mhm
<Wizzup> ok
<Wizzup> I thought maybe it was a bug in our pvr mesa stuff
<freemangordon> lemme try to find it
<freemangordon> yes
<Wizzup> so I'll build it on the droid4 I guess?
<freemangordon> don;t really remember, but yeah, I think it makes sense to try upstream apitrace
<Wizzup> and we will use this trace how?
<Wizzup> btw, explain to me why llvmpipe also renders lima trace fine
<Wizzup> if it doesn't support TFP
<Wizzup> I guess it does support TFP
<freemangordon> we will use that trace to compare the scissors
<freemangordon> rertace does not need to support TFP
<freemangordon> it already has the texture data
<Wizzup> I will build tag 9.0 of apitrace, tag 1.0 requires newer cmake (sigh)
sunshavi has quit [Ping timeout: 240 seconds]
<freemangordon> yeah
<Wizzup> autotools almost never has these problems :)
<freemangordon> not in the last 10 years at least
<Wizzup> right
<freemangordon> hmm, see
<freemangordon> seems we have the same issue with tfp path
<Wizzup> right
<freemangordon> if you look at frame 27
<freemangordon> texture in call 2340 looks fine to me
<freemangordon> but scissor is only 55 pixels tall
<rafael2k> autotools rocks
<freemangordon> :nod:
<Wizzup> freemangordon: let me open the lima trace
<freemangordon> ok
<freemangordon> if you change height in call 2325 to be 1440, the frame renders correctly
<Wizzup> ah
<freemangordon> ok, seems something has been optimized
<freemangordon> so scissor box includes only the updated area
<freemangordon> and somehow it counts on framebuffer to contain valid data
<Wizzup> yeah
<freemangordon> from previous draws on a different framebuffer
<Wizzup> which I guess they cannot rely on
<freemangordon> yes, but why do they do?
<freemangordon> also, this seems to work on pvr
<Wizzup> good question, llvmpipe is fine with it
<Wizzup> yes
<freemangordon> to me llvmpipe simply ignores the scissors
<freemangordon> but, we have pvr and at least one nvidia that does it correctly
<freemangordon> which does not make sense to me by looking at the trace
<Wizzup> yes and the nvidia one run was not used for X, it was secondary render
<freemangordon> or, something has changed between es2 and es3
<Wizzup> which could explain the clean buffers
<freemangordon> clean?
<Wizzup> not dirty/wrong
<Wizzup> 13:57 < freemangordon> and somehow it counts on framebuffer to contain valid data
<freemangordon> yeah
<freemangordon> but how that valid data end up there?
<freemangordon> unless they use common memory for both back buffers
<Wizzup> from previous calls/swaps?
<freemangordon> which does not make sense at all
<freemangordon> hmm, maybe there exist a way to do "hidden" copy on swap
<Wizzup> yeah
<freemangordon> but I have never heard of anything like that
<freemangordon> well, actually there is such thing like buffers age
<freemangordon> and if clutter 0.8 is smart enough to use that, it might explain what we see
<freemangordon> but I am not sure it is
<freemangordon> interesting reading https://gitlab.freedesktop.org/lima/mesa/-/issues/59
<freemangordon> I wonder if default is EGL_BUFFER_PRESERVED
<freemangordon> "The initial value of EGL_SWAP_BEHAVIOR is chosen by the implementation. "
<Wizzup> heh
<Wizzup> ironically I saw this two days age
<Wizzup> ago
<Wizzup> when I was just looking at the differences in extensions
<Wizzup> didn't think much of it but did look it up
sunshavi has joined #maemo-leste
<Wizzup> freemangordon: fwiw apitrace with your patches in there still segfaults in libGLESv2_PVR_MESA.so
<freemangordon> :(
<Wizzup> but sounds like the buffer age might very well be the thing
<freemangordon> I guess weh shall capture this with pvrtrace
<Wizzup> maybe we can try to set the swap behaviour first?
<freemangordon> mhm
<freemangordon> just cloned clutter, to see if this is already set
<Wizzup> no calls to eglSurfaceAttrib
<Wizzup> in clutter 0.8
<freemangordon> yeah
<freemangordon> will try it first in the VM
<Wizzup> ok
<Wizzup> I will need to go to a shop quickly before they close
<freemangordon> will provide patch if it doesn;t break anything
<freemangordon> ok
<Wizzup> I'll be back in 25mins
<Wizzup> or so
<freemangordon> ok
_inky has quit [Ping timeout: 250 seconds]
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 240 seconds]
<freemangordon> Wizzup: changes nothing in the VM at least
<freemangordon> I set it to EGL_BUFFER_DESTROYED, hoping that it will break something
<freemangordon> maybe it is simply ignored by mesa
<rafael2k> so, if nothing goes wrong in the testing, I think next pp kernel is ready, based on 5.15.10
<rafael2k> turning the pp in a build machine <-
_inky has joined #maemo-leste
<freemangordon> Wizzup: for you to test when have time https://pastebin.com/1pYU4A05
<rafael2k> I'll upload the new 5.15 based pp packages soon for anyone who also wants to test
<freemangordon> anyway, lemme take a capture
<Wizzup> hi
<Wizzup> 14:51 < freemangordon> maybe it is simply ignored by mesa
<Wizzup> you mean llvmpipe here specifically right
<freemangordon> yeah
<Wizzup> ok
<Wizzup> let me warm up my fingers and try the patch
<freemangordon> ok, the captured trace is broken on nvidia :)
<Wizzup> wrt scissor?
<freemangordon> with stock clutter
<freemangordon> without that patch
<freemangordon> I'll capture now with a apatch
<freemangordon> *with the patch
<Wizzup> ok
<Wizzup> I applied it now and the rendering issues with TFP path still exist
<Wizzup> on lima that is
<freemangordon> the same on retrace
<freemangordon> ugh
<freemangordon> seems this attribute is not supprted
<freemangordon> on nvidia that is
<Wizzup> 1) What are the semantics if EGL_BUFFER_PRESERVED is in use
<Wizzup> RESOLVED: The age will always be 1 in this case.
<Wizzup> hm
<freemangordon> mhm
<Wizzup> btw we can query for the swap behaviour
<freemangordon> yeah
<freemangordon> but I guess this is harmless
<Wizzup> but that is only in error path
<freemangordon> mhm
freemangordon has quit [Read error: Connection reset by peer]
<Wizzup> I see this in cogl:
<Wizzup> /* Some implementation require a clear before drawing
<Wizzup> to an fbo. Luckily it is affected by scissor test. */
<Wizzup> /* FIXME: test where exactly this is needed end whether
<Wizzup> a glClear with 0 argument is enough */
freemangordon has joined #maemo-leste
<Wizzup> freemangordon: wb
<Wizzup> freemangordon: clutter/cogl/gles/cogl-fbo.c has some weird comments
<Wizzup> freemangordon: regarding scissor and glclear
<freemangordon> my PC just reset out of the blue :(
<Wizzup> :(
<freemangordon> will needs some time to restore the environment
<Wizzup> ok
<Wizzup> * clutter/clutter-stage.c: modified comments, made GLES use glScissor based
<Wizzup> partial updates rather than glViewport (which was too inaccurate and not
<Wizzup> actually much faster with current drivers)
<Wizzup> I suppose that might clarify
<Wizzup> clutter/clutter-stage.c has some weird comments as well regarding DOUBLE_BUFFER and VIEWPORT_DAMAGE
<Wizzup> seems like they struggled quite a bit with old n900 drivers to make this work well
<freemangordon> you mean lines 75-?
<freemangordon> right
<Wizzup> yeah glScissor is also mentioned in the changelog
<freemangordon> ugh, it seems pvr driver do blit, not flip
<Wizzup> and there is that comment that they only reason they use scissor test is to clear a fbo or something
<freemangordon> ok, maybe you shoudl set that to 1 and test
<Wizzup> which var in particular?
<freemangordon> DOUBLE_BUFFER
<Wizzup> not VIEWPORT_DAMAGE?
<freemangordon> no
<Wizzup> ok
<freemangordon> this shoudl fix it
<freemangordon> this is exactly the damage tracking we are missing, IIUC
<Wizzup> I had some other local comments
<Wizzup> code changes*
<Wizzup> let me remove those
<freemangordon> I guess this should also fix tearing, but not really sure
<freemangordon> on d4 that is
Twig has quit [Ping timeout: 256 seconds]
<Wizzup> most problems are gone
<Wizzup> the osso selection in particular is still problematic
<Wizzup> but the conversations bug is gone
<Wizzup> oh, firefox is still messy
<Wizzup> ok I spoke too soon
<Wizzup> btw, hum: (hildon-desktop:10764): ClutterEGL-DEBUG: 15:33:09.110: clutter_eglx_texture_pixmap_paint: X errors
<Wizzup> oh that is maybe just when windows are closed
<freemangordon> mhm
<Wizzup> yeah so I thought it got better, and maybe it did some, but there are still problems
<Wizzup> I need to go back to my test cases and try
<Wizzup> so the virtual keyboard renders ok now in portrait always
<Wizzup> the text input applet also no longer has trouble
<freemangordon> is it fixed for TFP or for x11 case?
<Wizzup> nothing is entirely fixed
<freemangordon> I think TFP has other issues
<Wizzup> ok
<Wizzup> let me force fallback
<Wizzup> I had TFP on
<freemangordon> yeah
<Wizzup> no, several problems still exist
<Wizzup> those could be entirely different problems
<freemangordon> mhm
<Wizzup> specifically vkb is ok
<freemangordon> I captured a trace in the vm
<freemangordon> lets see if replay on nv will be ok
<Wizzup> so what is fixed with fallback + double buffer = 1 + buffer preserved is
<Wizzup> 1. vkb rendering (it shows ok, and it also doesn't 'jump' up for every key press)
<Wizzup> 2. display and text input applets in cpa (sometimes those would 'bounce' forever)
<freemangordon> this affects TFP path as well
<Wizzup> 3. firefox doesn't flicker insanely or at all really
<Wizzup> without fallback, firefox flickers insanely
<Wizzup> and in either case, the osso-xterm selection bug is -not- fixed
<freemangordon> it is, in replay
<freemangordon> please capture a trace
<Wizzup> interesting
<freemangordon> as my capture here in VM is ok on NV
<freemangordon> hmm, wat was the command to replay?
<Wizzup> there is apitrace replay
<Wizzup> but it renders way too fast
<Wizzup> so I just do dump-images and look at them all
<freemangordon> ok
<Wizzup> so to be clear, you want me to capture another osso-xterm select regions with my finger session
<Wizzup> but this time with the buffer management change, the double buffer change and the fallback change?
Twig has joined #maemo-leste
<freemangordon> hmm, what is "buffer management change"? swap behaviour?
<Wizzup> yes
<freemangordon> no, remove that
<freemangordon> double-buffer change should be enough
<freemangordon> and what is "fallback change"?
<Wizzup> use_fallback = TRUE;
<Wizzup> iow force disable tfp path
<freemangordon> can;t we do that from a env var?
<Wizzup> probably but this was way easier for me
<freemangordon> Wizzup: ok
<Wizzup> also, did you see this:
<Wizzup> We *should* be double-buffered, but because we're just blitting in
<Wizzup> glSwapBuffers rather than flipping, we can do without the extra areas
<Wizzup> drawn. THIS MUST BE SET TO 1 IF FLIPPING IS EVER IMPLEMENTED
<freemangordon> yes
<Wizzup> I mean I guess you did
<Wizzup> ok
<freemangordon> and we are flipping ;)
<freemangordon> I guess on fremantle pvr blits, thats why the tearing
<Wizzup> tearing on the d4 you mean
<Wizzup> well this was a useful exercise then at least
<freemangordon> no, I mean on fremantle
<Wizzup> ok
<freemangordon> but I expect this change to fix tearing on d4
<Wizzup> that would be neat
<freemangordon> the point is:
<freemangordon> back then, on fremantle, because pvr or x11 or no idea who was/is using single buffer to do blits, we have that tearing
<freemangordon> but clutter tracks dameage only for the last frame
<freemangordon> nowdays we have a real double-buffering, so we must enable last 2 frames damage tracking
<freemangordon> this is what that note says
<freemangordon> *IIUC* :0
<freemangordon> :p
<freemangordon> so, please do 2 capture, both with DOUBLE_BUFFER=1
<freemangordon> one with TFP and another without
<Wizzup> of osso-xterm with selection?
<freemangordon> yes
<Wizzup> ok
<Wizzup> do you want lima and llvmpipe renders
<freemangordon> I think the TFP one will be needed to track why glamor or lima does not render pixmap texture correctly
<Wizzup> s/renders/traces/
<freemangordon> that would mean 4 traces, no?
<Wizzup> i.e. shall I do the same with LIBGL_ALWAYS_SOFTWARE=1
<Wizzup> yes
<Wizzup> I suppose we don't need it now
<freemangordon> yeah
<freemangordon> we may want to do llvmpipe glamor though
<freemangordon> because I think glamor has bugs, no matter what uvos says :p
<freemangordon> but, not now
<Wizzup> how does this look to you:
<Wizzup> MESA_DEBUG=flush,incomplete_tex,incomplete_fbo LIBGL_DEBUG=verbose G_MESSAGES_DEBUG=all COGL_RENDERER=egl_xlib COGL_DRIVER=gles2 apitrace -a egl -o hildon-desktop-doublebuf-fallback.trace maemo-summoner hildon-desktop.launch
<freemangordon> ugh
<freemangordon> why those mesa flags?
<Wizzup> this is just how I run the command normally
<Wizzup> I was using them earlier
<Wizzup> let me remove them
<Wizzup> just checking with you
<freemangordon> "apitrace trace -a egl maemo-summoner /usr/bin/hildon-desktop.launch" is all I did in the VM :)
<Wizzup> freemangordon: btw I replayed it on my laptop and it looks good
<Wizzup> (what does not look good on lima)
<Wizzup> now let me do with tfp on
<freemangordon> This issue reminds me of a proverb that my manager told me back then when I was so much younger, and which translates roughly to " His donkey died because of complex reasons" :)
<Wizzup> meaning? :D
<freemangordon> well, it does not work because of several issues, not one or 2
<Wizzup> right
<Wizzup> does the trace also replay ok for you?
<freemangordon> lemme check
<freemangordon> yep, looks perfect
<Wizzup> hm, now with tfp it looks ok
<Wizzup> wtf
<freemangordon> mhm
<freemangordon> as expected
<freemangordon> ;)
<Wizzup> well I did rebuild it
<freemangordon> as I said, TFP was bitten by the same scissors issue
<freemangordon> was/is
<freemangordon> but, we have issues in lima/glamor too
<Wizzup> I think if we have lima specific bugs we can start asking for their help
<Wizzup> freemangordon: wait, hang on, I remember now
<freemangordon> that's why as told you to capture both tfp and fallback :)
<Wizzup> freemangordon: so regarding this:
<Wizzup> 16:00 < Wizzup> hm, now with tfp it looks ok
<Wizzup> 16:00 < Wizzup> wtf
<Wizzup> this happens because things are slower
<Wizzup> that is why I was previously struggling to capture traces of some of it
<freemangordon> what is slower? TFP compared to fallback?
<Wizzup> no, so let me explain what I mean
<Wizzup> I was doing osso-xterm test with clutter and TFP enabled
<Wizzup> and it looked ok on the screen
<Wizzup> right?
<Wizzup> that is only because it was run within apitrace
<Wizzup> if I run h-d outside of apitrace with TFP the same bug that we see with fallback path is there
<freemangordon> ah, I see
<freemangordon> so, a missing fence ;)
<Wizzup> possible yes
<Wizzup> otherwise it looks pretty ok
<freemangordon> ok, do you want to rebuild clutter with DOUBLE_BUFFER enabled and rebuild for -devel?
<freemangordon> or I shall do that?
<Wizzup> I can do it, just want to check with you that we have more work to do here potentially
<Wizzup> let me capture a few more traces
<Wizzup> one in particular
<freemangordon> ok, but I don;t think we have any more issues in clutter
<freemangordon> well, we may want to compare fps with VIEWPORT_DAMAGE enabled vs disabled
<freemangordon> but not now
<freemangordon> also, we shall do that on n900
<Wizzup> actually nevermind I think
<Wizzup> I replayed the trace and dumped the images locally and the problem is gone
<Wizzup> so it's either a lima problem or a glamor problem
<freemangordon> lima I would say
<Wizzup> (it is scrolling in conversations)
<freemangordon> because glamor does 2d
<freemangordon> and we receive ready textures
<Wizzup> yeah and conversations uses 3d
<Wizzup> (qml)
<freemangordon> mhm
<Wizzup> ok
<Wizzup> I'll do a clutter build
<freemangordon> don't forget to revert the other changes :)
<Wizzup> no worries, those are on a pinephone
<Wizzup> I only do this work from my laptop and vm
<freemangordon> ah, ok
<Wizzup> shall I remove the comments
<freemangordon> no
<Wizzup> the one regarding blitting?
<freemangordon> maybe add a new one
<Wizzup> ok
<freemangordon> saying "this no longer holds true on leste, so we enable", etc
<freemangordon> mhm
<Wizzup> so on the lima front
<Wizzup> do you suggest I just send the traces I uploaded to them?
<freemangordon> yeah
<Wizzup> ok
<freemangordon> we may provide more info if requested
<freemangordon> what's the channel?
<Wizzup> I am in the channel
<Wizzup> #lima on oftc
<freemangordon> oftc?
<Wizzup> irc.oftc.net and you must register and verify
<freemangordon> ok
<Wizzup> otherwise you are muted
<freemangordon> by muted you mean I can only see what others are saying, right?
<freemangordon> sorry for the maybe stupid question, but how to register?
<Wizzup> I think /msg NickServ help
<Wizzup> and then register, and then I had to 'reverify'
xmn has joined #maemo-leste
<rafael2k> wow, you are ready doing serios debbuging! cheers!
<rafael2k> lemme know if there is something I can test here
<rafael2k> I'm watching kernel compilation TV here in on Maemo PP TV
<freemangordon> :)
<freemangordon> season 5?
<rafael2k> finishing season 5 already
<Wizzup> freemangordon: it's ready btw
<Wizzup> in -devel
<freemangordon> installing already :)
<Wizzup> I think there is still tearing
<Wizzup> sorry for spoiler :P
<Wizzup> but maybe not in your setup, if you did more work
<freemangordon> :)
<Wizzup> this d4 is a bit out of date
<freemangordon> well, it does not boot for me at all
<freemangordon> hung on Starting PowerVR
<Wizzup> not good :)
<freemangordon> and then DDK message
<freemangordon> and that's all
<Wizzup> maybe dsme is not called dsme
<freemangordon> hmm?
<Wizzup> maybe you renamed it
<freemangordon> no
<freemangordon> why should I
<Wizzup> to prevent it from booting to h-d or something
<freemangordon> no, I just rebooted from osso-xterm
<freemangordon> after doing dist-upgrade
<Wizzup> did that complete entirelyt?
<Wizzup> on -devel or -experimental?
<freemangordon> yeah
<freemangordon> -experimental
<Wizzup> hmm weird
<Wizzup> pretty sure my daily one is up to date
<freemangordon> it seems it just hang after starting powervr service
<Wizzup> I will upgrade mine but I do not think I am seeing this
<Wizzup> hm my device says that xserver-xorg-video-omap is being held back
<Wizzup> wonder why
<freemangordon> that's why dist-upgrade
<Wizzup> even with dist-upgrade
<freemangordon> hmm
<freemangordon> weird
<Wizzup> so mesa failed for -devel last night
<Wizzup> because of some really annoying CI bug
<Wizzup> I'll get that started now
<Wizzup> I'll need that to figure out what's up anyway
<freemangordon> hmm, even emergency shell does not start
<freemangordon> why is powervr needed there?
<Wizzup> probably because it is in sysvinit runlevel or something like that
<Wizzup> is this custom kernel or the one in the repos
<freemangordon> should be the one in the repos
<Wizzup> btw with pinephone upgraded things are better for sure
<Wizzup> but the vkb still has occasional flicker/glitch, but I am going to attribute that to the other thing we're going to chase down
<freemangordon> this is with TFP?
<Wizzup> yes
<freemangordon> ok
<rafael2k> Unpacking libclutter-0.8-0:arm64 (0.8.2.75+2m7) over (0.8.2.74+2m7.2) ...
<rafael2k> ; )
<freemangordon> :)
<Wizzup> rafael2k: try pkill hildon-desktop when that is done
<rafael2k> Wizzup: will this make me lose network connection? I can not lose ssh right now in the middle of kernel compiling.
<freemangordon> no
<rafael2k> ok
<freemangordon> in theory :)
<rafael2k> lemme wait a bit, I don't want to spend any amp more turning on the screen right now
<Wizzup> conceptually :p
<Wizzup> rafael2k: again, just lmk when you want the easy steps to compile on pc/laptop ;)
<freemangordon> Wizzup: what fps do you get when scrolling in h-d?
<freemangordon> CLUTTER_SHOW_FPS=1 that is
<rafael2k> Wizzup: I want (if this kernel is not 100% perfect... next try I'll cross)
<Wizzup> freemangordon: on pp?
<freemangordon> mhm
<Wizzup> freemangordon: and portrait?
<freemangordon> both
<freemangordon> just curious
<Wizzup> freemangordon: 22 landscape, 55-62 on portrait
<freemangordon> portrait seems fine, glamor/modesetting seem to SW rotate :(
<Wizzup> yes, but that is a later worry imho
<freemangordon> yeah
Twig has quit [Ping timeout: 252 seconds]
<freemangordon> ok, I am done for now, bbl
<Wizzup> mhm
<Wizzup> I'll look at the problem
<freemangordon> d4 you mean?
<Wizzup> the dist-upgrade at least
<freemangordon> ok
<freemangordon> Wizzup: well, /usr/bin/pvrsrvinit never seem to exit
<Wizzup> should it not be in /sbin?
<Wizzup> anyway I will upgrade and look
<Wizzup> but I will also be busy for some part this evening
<freemangordon> me too
<Wizzup> yeah I guess that makes sense
<Wizzup> :D
<sicelo> < Wizzup> [17:43] hm my device says that xserver-xorg-video-omap is being held back <<<--- i got this too
Twig has joined #maemo-leste
<Wizzup> sicelo: yes, so I'll try to figure it out once mesa is built
<rafael2k> fixed ofono packaging using internal libell
<rafael2k> so we don't need to import newer libell to beowulf (this is how it was built ofono in maemo in the first place anyway... so the right thing to do)
<Wizzup> yup
<Wizzup> going to be a nice christmas update
<Wizzup> esp if we can get this lima/glamor bug fixed
<rafael2k> that would be pappa frost biggest one
<Wizzup> newer clutter makes things much better btw
<rafael2k> cool! will try soon, certainly kernel compilation is finishing!
<Wizzup> that poor sd card ;)
<Wizzup> bbiab
<rafael2k> I compiling in the eMMC
<rafael2k> it is faster
<rafael2k> it has luks and crypto... which does not help, but anyway...
<Wizzup> and it'll die sooner and is not replaceable
<Wizzup> :P
mrkrisprolls has quit [Ping timeout: 268 seconds]
mrkrisprolls has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
inky_ has quit [Ping timeout: 268 seconds]
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
<freemangordon> Wizzup: if you have some spare time, could you patch clutter on pp to dump the default value of EGL_SWAP_BEHAVIOUR?
<rafael2k> compilation still going on... eheheheheh
<rafael2k> 4h already
<Wizzup> freemangordon: will do
<Wizzup> I tested setting it and it did not make a difference fwiw
<Wizzup> freemangordon: might be tomorrow... picking up gf at the airport
<Wizzup> freemangordon: but reading the links I shared, it seems very unlikely it is on by default
<Wizzup> given that lima authors added patches to mesa to allow drivers to disable it
<Wizzup> the partial update way might work too
n900 has quit [Quit: WeeChat 2.3]
n900 has joined #maemo-leste
<sicelo> nice hostname & nick n900
akossh has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 240 seconds]
<buZz> hehe, qtwebbrowser is pretty nice :D too bad of the onscreen keyboard
akossh has quit [Quit: Leaving.]
inky has quit [Ping timeout: 240 seconds]
mardy has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
Twig has quit [Ping timeout: 240 seconds]
_inky has joined #maemo-leste
<freemangordon> Wizzup: Linux devuan-droid4 5.15.2 #1 SMP PREEMPT Wed Dec 15 00:29:28 UTC 2021 armv7l GNU/Linux
<freemangordon> hangs as soon as pvr is inited
uvos has joined #maemo-leste
<uvos> buZz: whats wrong with the osk?
<buZz> oh eh, i was typing on the hw keyboard, it still appeared :)
<uvos> it should not
<uvos> did you build it yourself?
<freemangordon> buZz: what device is that?
<uvos> freemangordon: this is not him
<uvos> freemangordon: the application has a built in keyboard
<freemangordon> ah
<uvos> but i ported it to ask mce
<uvos> if its neede
<uvos> d
<freemangordon> ok
<freemangordon> uvos: btw, we made some progress with lima
<uvos> ok
<uvos> ill read backscroll later
<freemangordon> ok
<buZz> freemangordon: droid4
<uvos> oh btw are you on devel?
<buZz> uvos: eh , no i just installed it from appstore
<uvos> devel or stable
<buZz> i might be, i keep forgetting to switch back , lemme check
<buZz> on stable
<uvos> ah ok
<freemangordon> night guys!
<buZz> nn freemangordon
<uvos> your mce it too old
<uvos> gn8
<buZz> well, cool stuff :) its a pretty fast browser
<buZz> sadly webgl wasnt working :P
<uvos> its not accelreated
<uvos> at all
<uvos> is all sw rendering
<buZz> isnt it just chrome's engine underneath?
<uvos> a fork of it yeah qwebengine
<uvos> but its broken on pvr
<uvos> it fails to compile a shader
<buZz> ah hm
<buZz> i -think- i had functional webgl on droid4 at some point, slow, but functional
<uvos> firefox works fine
<uvos> and is accelerated
<uvos> dunno of webgl works
<uvos> it should really
<buZz> i'll try :)
<buZz> ooo, maybe troubled because of having gl4es installed :D