<freemangordon>
tmlind: trying to devmem2 on anything in the range from 0x5000FE00 to 0x5000FF0C gives bus error (and 'external abort on non-linefetch'), so OCP on 3430 *must not* be touched
<tmlind>
freemangordon: hmm i'm pretty sure i tested that when adding it, did you do echo on > control for the module before reading?
<freemangordon>
kmscube is running while I am trying to read those vals
<freemangordon>
lemme do what you say (control)
<tmlind>
ok, yeah that's the ocp range, right? that is broken on 34xx afaik, so yeah if the ti-sysc sgx quirk is applied for 34xx instead of 36xx we need to fix it
<freemangordon>
maybe it is not applied, but anyways ti-sysc tries to read memory that's not accessible
<tmlind>
it is enabled based on the sgx revision register, if it was enabled for 34xx, sounds like you should see errors all the time when idling sgx
<tmlind>
actually when enabling sgx
<tmlind>
note the comments in the dts on how we read the sgx ip rev register, not the ocp register on 34xx unlike on 36xx
<freemangordon>
tmlind: I disabled pvr from touching OCP and everything works now, see backscroll
<tmlind>
yeah nice :)
<freemangordon>
but, ti-sysc will try to read OCP revision with your omap3-prm-gfx.patch, no?
<tmlind>
with the runtime pm in use with ti-sysc we should not tinker with the ocp regs in the pvrsgx driver at all
<tmlind>
oh it does toggle something, ok so let's move it to the pvrdrv where it belongs
<freemangordon>
ok, but please, disable all this crap for 3430 :)
<tmlind>
so how do you have interrupts working for 34xx then? no way to mask them?
<freemangordon>
by enabling SYS_USING_INTERRUPTS
<freemangordon>
why would I want to mask interrupts?
<tmlind>
with SGX_OCP_REGS_ENABLED commented out so SysEnableSGXInterrupts does nothing?
<freemangordon>
yes
<tmlind>
ok yeah so must not touch the ocp regs on 34xx, others should have the interrupt handler in pvr-drv.c
<tmlind>
the interrupt enable/disable in pvr-drv.c
<freemangordon>
I commented out lines 104-107 in syslocal.h
<freemangordon>
and enabled SUPPORT_ACTIVE_POWER_MANAGEMENT and SYS_USING_INTERRUPTS
<freemangordon>
and that's it
<tmlind>
ok, maybe push out your kernel changes so i can see what it's against?
<tmlind>
you do have 1.17 instead of 1.14 in the .config, right?
<freemangordon>
I am using your tree, nothiong but 1.17 there :p
<tmlind>
yeah because the default is 1.14 otherwise and you easily test the wrong driver :(
<freemangordon>
"gpu: pvr: Drop all old ddk versions"
<freemangordon>
"ARM: omap2plus_defconfig: Use ddk-1.17 by default"
<freemangordon>
:)
<freemangordon>
I just removed your tiler patches as they break 3430
<tmlind>
ok so if you post a patch with your changes and which commit it's against i'll test here when i get a chance and try to do a fix for the pvrsgx tree
<tmlind>
ok i'll try to get the pvr branch working both for omap3 and 4 at least
<freemangordon>
tmlind: I will have to come-up with yet another macro to define that disables oc appcess
<freemangordon>
*ocp
<tmlind>
nah let's just remove that crap and add do it in pvr-drv.c based on the quirks flag there
<tmlind>
these ifdefs are just totally out of control
<freemangordon>
I don;t feel comfortable doing that
<freemangordon>
or, you want you to do it?
<tmlind>
i'll do it, just post your hacks so far so i can verify against that on n900
<freemangordon>
ah, ok
<freemangordon>
ok, need to clone your tree first :)
<tmlind>
so what you have working, and what commit it's against
<tmlind>
a patch is fine too just do git diff from some my commit with all the reverts etc
<freemangordon>
ok, sec
<freemangordon>
hmm, wait, I want to test with your omap3-prm-gfx.patch patch first, gimme 10 minutes
<tmlind>
ok yeah i'll have to take a look at that stuff later, nice that you chased down the issues though :)
<freemangordon>
:)
<freemangordon>
BTW, if you have a couple of minutes, read the backscroll from after we talked yesterday evening
<freemangordon>
to confirm SGX idles fine
<tmlind>
yeah that's all there is to it, clocks get disabled, then the prm driver disables the power domain after the module is idle
Twig has joined #maemo-leste
brabo has joined #maemo-leste
Twig has quit [Remote host closed the connection]
Twig has joined #maemo-leste
inky_ has quit [Ping timeout: 245 seconds]
_inky has quit [Ping timeout: 245 seconds]
uvos has joined #maemo-leste
<freemangordon>
tmlind: it works with omap3-prm-gfx.patch patch on top as well
<freemangordon>
Wizzup: how had is to port pvr xorg river to 1.17?
<freemangordon>
*how hard
<freemangordon>
I don;t thing glamor makes sense
<freemangordon>
*think
<uvos>
pvr xorg driver makes no sense
<uvos>
its not even a kms driver
<uvos>
the omapdrm one makes some sense
<uvos>
but you cant get 2d acell with it because 1. the module it uses for that is closed source and dosent work with modern xorg abi
<Wizzup>
freemangordon: to port the n900 one we use right now?
<Wizzup>
I don't think that would make sense per se, I'd probably suggest to take the modesetting driver and add 2d on top of it using the 2d sgx code in some fashion
<uvos>
so it would make more sense to decouple dri3 from glamor in modesetting, there is no reason for dri3 to not work with sw 2d rendering
<Wizzup>
but the exact calls tht are used there do not exist
<uvos>
and this decoupaling was planned
<uvos>
and then droped when everyone moved to wayland instead
<Wizzup>
The 2d code/api probably exists in some form still, but not in the one we use currentenly on the n900, but also that's a very old fbdev driver with endless hacks I'd really like to not use
<uvos>
pvr2d still exists
<Wizzup>
right, but I recall the api changed some or something
<Wizzup>
in any case I think we should be able to register a specific exa module for the driver, no?
<Wizzup>
We could add another AccelMethod to modesetting for example
<uvos>
yes
<uvos>
but a seperate modesting based ddx makes more sense
<uvos>
since we could build that seperatly instead of forking all of xorg
<Wizzup>
right but the proof of concept / work would be the same
<uvos>
sure
<Wizzup>
that's just a packaging change
<uvos>
"so it would make more sense to decouple dri3 from glamor in modesetting, there is no reason for dri3 to not work with sw 2d rendering"
<uvos>
this makes the most sense at first
<uvos>
and would allow the same state as omap ddx on d4 atm
<uvos>
with acell
<uvos>
ie 3d but no 2d
<Wizzup>
yeah maybe you said the same but I can't comprehend fully because of my limited xorg knowledge
<uvos>
and would be welcomed upstream most likely
<Wizzup>
right it would also provide exa on d4
<uvos>
as again this was planned anyhow
<Wizzup>
can you explain that in more layman terms?
<uvos>
so in modesetting dri3 is tied to glamor because glamor implements some bits of it in gl. so modesetting without glamor falls back to dri2 for 3d. dri2 needs special driver support that wayland kms/drm drivers dont nesscarly have (ie pvr dont some other modern drivers dont).
<uvos>
implementing non gl fallback paths for non glamor modesetting would allow dri3 to be used and thus accelerated 3d on pvr, in the same fashion as the omap ddx for 1.9 without the sgx2d module that is closed source
<Wizzup>
wasn't the sgx2d a very small lib that fmg re'd before?
<uvos>
ie any gl draw calls by applicaitons are acellerated as is compositing
<uvos>
but core x rendering is not
<uvos>
Wizzup: the pvr2d lib for was 1.9 was of sane size yeah
<uvos>
we would need to implement something like it if we want core x to be acclerated
<uvos>
but this could come later
<Wizzup>
ok
<Wizzup>
I'd be happy to help but I really don't know where to start
<uvos>
well i dont either
<uvos>
im not convinced fmg is correct even wrt glamor being a bad idea
<uvos>
its possible its perf will be bad
<uvos>
but at least on pvr sgx545 it must have been possible to be ok (given that glamor was initally developed for this chip a long time ago....)
<uvos>
we could also check out how modern kms/drm ddx drivers work that support dri3 without glamor
<uvos>
like the nouveau
<uvos>
and i think the omap5 one (maybe)
<uvos>
the difference being that the omap5 dirver implments 2d accell (and very likely drawing surfaces for the present extension) on the 2d core that omap5 (and omap4670?) have
<uvos>
*omap4470
<Wizzup>
I think pvr has a 2d unit
<uvos>
right
<Wizzup>
so using that rather than 3d sounds like a good idea
<Wizzup>
in principle
<uvos>
or rather it dose 2d somehow
<Wizzup>
right
<uvos>
its proubly useing the 3d engine
<Wizzup>
I am not so sure
<uvos>
but later omaps have a deicated 2d chip
<Wizzup>
if it uses the 3d engine then yeah, it might be the same
<uvos>
well it would be better optimized
<uvos>
they have special microcode for 2d
<Wizzup>
I think it might make sense to at least fix glamor and then see just how bad it is
<Wizzup>
depending on how much fixing it needs
<Wizzup>
getting the 2d to go is also a way into mainline..
<uvos>
fixing it its easy (realtivy)
<uvos>
fixing it without copying every surface is hard
<uvos>
and ofc prf wise its not fair if you copy every surface :P
<freemangordon>
thats the issue
<freemangordon>
we cannot fix it without copying every surface
<freemangordon>
with doing that perf goes down the drain
<freemangordon>
my test application does that copying with 15fps on n900
<freemangordon>
and was something like 50-60 fps on d4
<freemangordon>
but, keep in mind this is *the only* thing test app does
<freemangordon>
so in RL performance will be even worse
<uvos>
still faster than glxgears on ddk1.9 :P (wich clearly is also copying surfaces)
<uvos>
*es2_gears
<uvos>
but ok
<uvos>
if its not possible idk
<freemangordon>
sec
<freemangordon>
uvos: if you want to review the code I am using to test fix for glTexSubImage2D, please LMK
<freemangordon>
it is perfectly possible I am doing something wrong, thus the bad perf
<uvos>
i have seen it
<freemangordon>
ok
<freemangordon>
this runs with 15fps
<uvos>
i dont know enought about gl to say
<freemangordon>
but even if it was running with 50fps, still copying every BO backed texture is insane
<uvos>
yeah
<freemangordon>
so, I am not sure my idea of having pvr driver that is not glamor makes sense
<freemangordon>
*makes no
<uvos>
im not saying it dosent
<freemangordon>
uvos: so, you say we shall stay with modesteenig/dri2?
<uvos>
no
<uvos>
i would investigate dri3 without glamor in modesetting
<freemangordon>
please explain to us mortals who are not deep in xorg architecture :)
<freemangordon>
who will implement 2d accel?
<uvos>
no one
<freemangordon>
that'd mean we'll scroll long lists for ages, no?
<freemangordon>
and there will be no XV surface, and... and...
<uvos>
yeah, yes yeah
<uvos>
but we can improve that later
<freemangordon>
so no video playback, and basically useless device
<freemangordon>
how?
<uvos>
well you create a module that implements core x rending on pvr2d
<uvos>
lots of work
<freemangordon>
can't we just RE the one from 1.14 and port it to 1.17
<uvos>
dident 1.14 drop that allready
<freemangordon>
lemme check
<uvos>
but yeah maybe depends on if pvr2d still is the same api wise
<uvos>
but at first you can get something that at least works as well as ddk 1.9 on d4 by "just" implementing dri3 on modeseting
<uvos>
analogous to how the nvidia mesa ddx driver dose it
<uvos>
*modesetting without gl
<freemangordon>
but we won;t have 3d, no?
<uvos>
yes we would have 3d
<freemangordon>
but for gbm and wl only, no?
<uvos>
glamor is only a hard requirement for dri3 on modesetting beacuse it uses it to render the present surfaces iiuc
<freemangordon>
oh, ok, I think I get your point
<freemangordon>
but, this already works, no?
<uvos>
no
<freemangordon>
modesetting+dri2
<freemangordon>
how's that?
<freemangordon>
iirc we patch xorg to even try glamor on ES2
<uvos>
so im pretty fuzzy on dri2 but it hooks into mesa x11 support code directly
<uvos>
and dosent work on just plain kms/drm/gbm driver
<uvos>
so no dice on pvr
<freemangordon>
yeah, it id dri3
<freemangordon>
*it is
<freemangordon>
so, your suggestion is to have dri3 without glamor working?
<uvos>
yes
<freemangordon>
no way
<freemangordon>
lemme explain:
<uvos>
look at what the nv driver dose
<uvos>
and omap5 dxx
<freemangordon>
wait
<freemangordon>
lemme explain
<uvos>
they use other hw blocks to copy the surfaces
<uvos>
for present
<uvos>
or rahter blit
<freemangordon>
you cannot mmap bo with pvr
<freemangordon>
so you simply cannot render on it without GL
<uvos>
well im sure pvr2d can grab surfaces from its mapped space
<freemangordon>
but we don;t know how
<uvos>
you could have a tiny accel module that uses pvr2d only to blit it
<uvos>
it = present surfaces
<uvos>
well yeah
<uvos>
sure we dont
<freemangordon>
uvos: so, your idea is to:
<uvos>
i dont see how we know how to implement a full pvr2d xorg ddx either
pere has quit [Ping timeout: 265 seconds]
<freemangordon>
use modesetting with dri3 to create BOs, then find a way to mmap those BOs so xorg code can render on that?
<freemangordon>
is this your idea?
<uvos>
that would work yeah
<freemangordon>
I don;t think we can mmap
<freemangordon>
BTW, there is anotehr way - using bufferclass
<uvos>
so how do wayland wms get cpu renerd surfaces into pvr
<uvos>
they just upload a texture no?
<freemangordon>
GL
<freemangordon>
texture + shader
<freemangordon>
I am not aware of any other way
<uvos>
so the BO backed textures wich are those
<uvos>
the core x renderd ones
<uvos>
?
<freemangordon>
no, BOs are created by gbm_create_surface() (or whatever the function was)
<freemangordon>
then you create a texture/fbo from that BO, and render on that FBO
<freemangordon>
(IIRC)
<freemangordon>
I guess WL does something similar
<uvos>
right but in wl it works somehow
<uvos>
so which are created like this?
<freemangordon>
uvos: keep in mind it makes lots of sense to disable mmap() for such surfaces
<freemangordon>
in terms of xorg - I think front and back buffers
<freemangordon>
in modesetting that is
<uvos>
right but why
<uvos>
x could just draw its 2d stuff using the cpu
<uvos>
upload it as a gl texture
<freemangordon>
that's what they do
<freemangordon>
but, fron/back buffers must be BOs to pass to dri
<uvos>
and then compose that + gl clients to the front buffer
<uvos>
ok
<uvos>
hmm
<freemangordon>
look at Linux_DRM_OpenGLES.c
<freemangordon>
it uses front buffer only, but API is the same
<freemangordon>
drmModePageFlip()
<freemangordon>
so, on mmap - it makes perfect sense to disable that, otherwise all the GPU caches/pipelines and optimizations are basically useless, as you have to flush the rendering on every access to mmap-ed memory
<freemangordon>
no?
<uvos>
yes
<freemangordon>
re 2d driver - I think I will be able to RE the one from older ddk, there are ones with debug symbols there
<uvos>
idk how mutch that helps us really
<uvos>
is accelerating exa
<freemangordon>
yes
<freemangordon>
and 3d is already accelerated
<freemangordon>
unless I miss something
<freemangordon>
dri3 does that for us, no?
<uvos>
dri3 dosent work without glamor in modesetting so we are back to where we started
<uvos>
you need to find a way to implement dri3/present without gl
<uvos>
not impossible
<freemangordon>
yes, but we can implement that simple 3d renderin
<uvos>
others have done it
<freemangordon>
no, why, I will do present with GL, there is no issue with it
<uvos>
yes you can use gl i ment without glamor
<freemangordon>
we have issue with 2D in glamor, not with present
<freemangordon>
mhm
<uvos>
ie just that bit of glamore that implements that
<freemangordon>
exactly
<freemangordon>
another option - what about XWayland?
<freemangordon>
this is supported upstream UUIC
<freemangordon>
*IIUC
xmn has joined #maemo-leste
<uvos>
my knowlage mostly deserts me here but xwayland renders it stuff via gl or sw, creates a buffer via gbm to shove that into and pases that to the wl wm
<uvos>
iiuc
<freemangordon>
and we are back in square one with glTexSubImage2D issue
<uvos>
yes
<freemangordon>
also, I still think perf-wise glamor will be next to useless even on d4
<Wizzup>
what about the omap5 driver that implements 2d for omap5s?
<Wizzup>
maybe there's usable stuff there
<uvos>
it implements everything (icl bliting buffers) on the ti 2d core
<uvos>
so its of limited use
<uvos>
as documentation how to implement sutch a ddx driver its usefull other wise not so mutch
<Wizzup>
ok
<Wizzup>
so adding another accel method based on glamor but using different 2d ops could potentially work?
<Wizzup>
(e.g. the 'old' ones we use now on n900)
<uvos>
Wizzup: maybe the probelm isent how to render the 2d elements per say
<uvos>
but how to get them to the display
inky_ has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
uvos has quit [Remote host closed the connection]
<freemangordon>
ok, we even have file names
inky has joined #maemo-leste
<freemangordon>
oh, 2d driver loads some code fragments into sgx (like blit)
inky_ has quit [Read error: Connection reset by peer]
_inky has quit [Read error: Connection reset by peer]
<freemangordon>
I guess I can RE that in 1-2 weeks
_inky has joined #maemo-leste
<Wizzup>
might be worth to check if it uses apis that are still available
xmn has quit [Ping timeout: 265 seconds]
<Wizzup>
(if not, REing makes a lot less sense)
<Wizzup>
still, if we can get glamor to go with not too much effort (even though we copy a lot) it might still be worth just for the milestone + working thing
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
<freemangordon>
Wizzup: I saw glamor semi-working on d4, takes a second to render xterm
<freemangordon>
this is without copying
<freemangordon>
copying it needed by firefox, for example
<freemangordon>
and it will slow-down already very heavy browser
<freemangordon>
libpvr2d is still there on 1.17, don;t know how much APIs match between Graphics_SDK_5_01_01_02 and this
<freemangordon>
but worths trying
uvos has joined #maemo-leste
<tmlind>
fyi, i think the pyra folks mentioned at some point that the neon functions were fastest for 2d, there's some xserver-neon or something
<tmlind>
i think xwayland suffers from the same glamor issues with gles2 as xorg meaning currently xwayland is not accelerated for sgx
<tmlind>
freemangordon: so did you try that pm34xx.c fix and verify it blocks off idle?
<tmlind>
hmm warm reset in off mode, how do you do that?
<tmlind>
i think only the macro boards had a reset button..
<freemangordon>
tmlind: well, fremantle kernel has that fix. no idea if it is needed or not, but judging by the fact Nokia created the patch, I would say yes
<freemangordon>
not sure I understand "did you try that pm34xx.c fix" part
pere has joined #maemo-leste
<tmlind>
i doubt that patch is needed, sounds like it's only for the macro boards
<tmlind>
but yeah, if off mode stops working after a warm reset in off mode, then sure we need it
<tmlind>
we can test that core off keeps working by decreasing the off idle mode time like i described earlier
_inky has quit [Ping timeout: 260 seconds]
<tmlind>
uvos: hmm so is your d4 consumes more in idle than bionic test case with the modem online?
<freemangordon>
tmlind: ok, if you say we don;t need that patch, I believe you :)
<freemangordon>
uvos: re armsoc - IIRC it uses the API that was before GBM, and mmap buffers
sixwheeledbeast has left #maemo-leste [#maemo-leste]
sixwheeledbeast has joined #maemo-leste
<kona>
freemangordon: is the platform gated on modest-providers in some way?
<kona>
i don't want to hold things up, but i haven't been able to give it any time
uvos has joined #maemo-leste
_inky has quit [Read error: Connection reset by peer]
Pali has joined #maemo-leste
Pali has quit [Ping timeout: 245 seconds]
Twiggy has quit [Ping timeout: 252 seconds]
<Wizzup>
uvos: btw I was on the croatian/bosnian border a few times and got quite a few smss on sphone about changing country - was nice
<Wizzup>
freemangordon: I wonder if our use case / problem is worth discussing with tomi or others who might know more
<uvos>
Wizzup: neat
<uvos>
Wizzup: well anyone who would listen how has more knowlage would be great, but ofc most will, rightly so, not be interested in pvr crap. tomi might ofc.
<Wizzup>
right
<uvos>
btw freedreno works really well with xorg
<uvos>
(on pmos)
<uvos>
i should really maybe port leste to xt1602
<Wizzup>
no keyboard though right?
<uvos>
no
<Wizzup>
still, would be cool
<uvos>
but otherwise its really well suported
<uvos>
even calls and stuff work
<uvos>
except that it has audio routing issues
<Wizzup>
right
<uvos>
like xt894
<Wizzup>
the more the merrier I guess, although I think we'd still want to solve the pvr stuff
<uvos>
sure ofc
<uvos>
i was just noteing
<Wizzup>
yeah good ideas
<uvos>
that freedreno works well while we have problems with pvr and mali too
<Wizzup>
yeah, I also bought a nexus 5 for leste at some point
<Wizzup>
I think parazyd has it
<Wizzup>
at the time I tried it we had some h-d bugs for rotation, but otherwise I already had 3d working
<Wizzup>
this was 2+ years ago
<uvos>
rotaion works fine
<uvos>
with xrandr
<Wizzup>
yeah, *now* :)
<uvos>
so is a solved issue or was hildon ackting up
<uvos>
i have to admit i dident even know that was valid c
pere has quit [Ping timeout: 252 seconds]
<Wizzup>
lol
<freemangordon>
kona: don;t worry, it is not important
<freemangordon>
still, good to have some day :p
<freemangordon>
Wizzup: what exactly to discuss with tomi? I'd say for the others xorg is dead and buried.
<freemangordon>
also, what we have here is low-end HW noone but us is interested in
<freemangordon>
n900 is simply not capable of supporting galmor, according to to what I was able to understand so far
<uvos>
well not the way its written, clearly you can draw with gles and compose everthing with gles to the screen from a hw perspective
<uvos>
since wayland wms do exactly that
<Wizzup>
freemangordon: I figured he might have some ideas, but it sounds like you mostly have a good sense of what ought to be done now
<Wizzup>
still, I'd take n900 with glamor (albeit slow) over 5.1 with old x ddx, but a path towards fast 2d is really nice (also for d4!)
<freemangordon>
right, but what is the point of wasting resource on something that we already know will be next to useless in terms of performance (glamor)
<Wizzup>
fair enough
<freemangordon>
either we find a zero-copy way or we waste cpu/gpu cycles and battery juice
<Wizzup>
right
<freemangordon>
see, maybe what I think shall be done is not the right thing to do
<freemangordon>
but as I see it none of use have the whole picture and until we try, we never know
<freemangordon>
well I tried glamor already and I am convinced this is not the correct thing for our usecase
<freemangordon>
on n900/d4 that is
<freemangordon>
for more powerful ES3 devices, it is another story
<freemangordon>
but for those who barely cover 2.1 we cannot use it and better look at TI already did back then
<freemangordon>
REing ~50KB lib is nothing compared to the time I already wasted on glamor/xorg without major success
<freemangordon>
I might be wrong as well, but...
<uvos>
well reing that lib is hardly sufficant
<freemangordon>
for 2D it should be
<Wizzup>
we still need to use the lib in the modesetting fork
<Wizzup>
and integrate that
<Wizzup>
but yeah
<uvos>
you still have to port omap ddx to dri3 and whatever changes come with the newer blobs
<Wizzup>
hm, why can't we use modesetting?
<freemangordon>
modesetting will be happy with dri2 EXA
<freemangordon>
if we dont; use glamor
<uvos>
except the iiuc dri2 path is not possible since you can shim it the same way
<uvos>
so how would 3d clients work...
<freemangordon>
yeah, I will have to think about that
<uvos>
in dri2 the server has to create the buffer and hand it to the client
<freemangordon>
uvos: but, honestly, do you think glamor is a viable option given it doe not support ES2?
<freemangordon>
*does not
<uvos>
i dont see how you gonna shim that
<uvos>
wdym? it supports es2 just fine
<uvos>
mostly
<uvos>
slightly out of spec maybe
<freemangordon>
BTW, if we are to implement video playback in glamor, we'll have something like 10fps for fullscreen
<freemangordon>
on n900 that is
<freemangordon>
SGX530 is simply not powerful enough for that
<uvos>
not sure how you come up with these numbers but ok
<Wizzup>
probably mem b/w?
<freemangordon>
because I played a lot with it back then when I was rtying to implement embedlite
<freemangordon>
back then mozilla switched to GL rendering for gecko
<freemangordon>
ecause of webgl
<freemangordon>
*because
<freemangordon>
so, videos were decoded to textures
Pali has joined #maemo-leste
<freemangordon>
I played "Big Buck Bunny" countless times trying to optimize to an acceptable performance
<freemangordon>
no dice
<freemangordon>
we have another option I don;t really like - bufferclass
<uvos>
im going to press x for doubt that sgx cant scale and transform a 1080p texture at 30 fps, and the ducati decoder works in the same memory so there is no copying needed
<Wizzup>
Why would it be 1080p?
<uvos>
decoder maximum
<Wizzup>
The n900 can't even decode 720p using the hw decoder
<freemangordon>
mhm
<uvos>
oh ok
<uvos>
well omap4 then
<freemangordon>
it can, but low profile only
<Wizzup>
in any case I think this is not super relevant
<uvos>
software /driver issues non withstanding the hardware can do this
<freemangordon>
yes, decoding was through DSP
<Wizzup>
Sure smooth video playback is nice for low res videos, but we can't make the hw better than it is, I think having smooth scrolling and such is imortant
<Wizzup>
having in-browser video playback ... eh
<freemangordon>
actually it is possible, and HW supports it
<uvos>
side not in-browser video plackbak works absoulty fine on d4 wayland
<uvos>
with gl surfaces
<Wizzup>
not arguing one way or another, just saying it's not that important to me personally
<Wizzup>
I really never play videos on my n900 fremantle much either, but having maps scroll smooth is important
<uvos>
dose sd @60 fps for youtube
<Wizzup>
e.g. maep on n900 is smoother now than on the d4 iirc
<uvos>
in ff
<Wizzup>
(on leste)
<freemangordon>
uvos: I was just givin an example
<freemangordon>
why I think about the numbers
<uvos>
and its more limited by the cpu than by sgx doing the presenting
<uvos>
*cpu decoding
<freemangordon>
not, it is limited by the memory bus
Pali has quit [Client Quit]
<freemangordon>
because you have to push every frame to a texture
<freemangordon>
and then use SGX to render that texture
<freemangordon>
this is not a zero-copy, sorry
<uvos>
no not atm in wayland its not zero-copy
<freemangordon>
we can have zero-copy with bufferclass
<uvos>
but its less copy
<uvos>
since the output dosent copy again
<uvos>
anyhow it works fine on d4
<uvos>
but its also faster ofc
<uvos>
than n900
<freemangordon>
uvos: ok, I don't get it - tmlind said WL has the same issues with SGX ddk as xorg
<freemangordon>
you say that it works fine
<uvos>
? wayland has allways worked fine
<uvos>
its very performant
<Wizzup>
I think uvos is not talking about sgx at all
<uvos>
yes ofc
<Wizzup>
in this instance
<uvos>
sgx output
<uvos>
im talking wlroots here
<uvos>
it renders via gles
<uvos>
its extreamly performant
<uvos>
fire up firefox and scroll around
<uvos>
or watch a video
<Wizzup>
maybe try it on the n900? would be interesting
<freemangordon>
could you try that on n900?
<freemangordon>
:)
<uvos>
if you provide me with a kernel that works
<uvos>
i guess i could also install pmos
<freemangordon>
which ddk? 1.17?
<uvos>
1.17
<freemangordon>
no problem, in 5 minutes
<sicelo>
I don't think we should discourage/stop fmg from RE'ing the 50kb binary if he feels there's some hope there. Just my 2 cents
<freemangordon>
sicelo: OTOH, if GL is performant enough, we should really consider it
<uvos>
sicelo: dont you use ddk1.17 on n900/wayland
<uvos>
or just d4
<freemangordon>
I doubt
<freemangordon>
as we have useful 1.17 on n900 since yesterday :)
<uvos>
well afaik it works in pmos i thought
<Wizzup>
I don't think so
<freemangordon>
with out working kernel?
<freemangordon>
I doubt too
<sicelo>
I was using 1.17 with no issues on debian. No one tried it on pmos
<uvos>
they use 5.7 or something
<uvos>
pmos has pacakges for jonathings mesa sgx
<uvos>
for omap4 at least
<freemangordon>
sicelo: with 2fps vbo I guess
<sicelo>
I used TI blobs with debian
mardy has quit [Quit: WeeChat 2.8]
<sicelo>
Mmm, i don't have it handy right now, and can't remember the actual benchmark scores. However sway worked reasonably okay