<jemk>
ssvb: have you tried turning off bank interleaving? if framebuffer and benchmark buffer are in different banks the overhead should vanish, therefor you'll lose seq. speed
notmart has joined #linux-sunxi
notmart has quit [Changing host]
notmart has joined #linux-sunxi
rm has joined #linux-sunxi
rm has quit [Changing host]
rm has joined #linux-sunxi
<mnemoc>
moin
<ssvb>
jemk: yes, I tried to remove the DRAM_DCR_MODE_INTERLEAVE bit as part of the experiments, but the device does not boot after that
acr has joined #linux-sunxi
acr is now known as MrFoo
MrFoo is now known as MrBar
<ssvb>
jemk: appears that the banks mapping configuration is more complicated than that
<ssvb>
jemk: additionally, disabling banks interleave completely is a very bad idea
Fusing3 has quit [Ping timeout: 252 seconds]
<jemk>
ssvb: yeah, sure, i only thought it could be a way to verify your theory
<jemk>
ssvb: but it's strage that it doesn't even boot, i thought i had tried that
<ssvb>
jemk: have you tried to reproduce the shaking screen problem yourself? even with a lower resolution monitor it is possible to downclock dram until i shows up
<MrBar>
who write backlight driver for FB_SUNXI_LCD ?
<ssvb>
jemk: also change "bus_width" from 32 to 16 and divide "size" by two if that's not enough
<jemk>
ssvb: my a10 is doing real work, so i can't do experiments there at the moment
<ssvb>
jemk: ok
<jemk>
ssvb: but one idea, it could be important to have correct density and io-widtg for non-interleaving to work
<ssvb>
jemk: the density and io width should be both correct
<MrBar>
why in disp_lcd.c realtime platform check performed?
<MrBar>
why drivers code looks like writen by monkeys?
<oliv3r>
MrBar: excellent questions, the pain of many of us
leviathanch has quit [Ping timeout: 255 seconds]
<MrBar>
it not linux
<MrBar>
it just android kernel
<MrBar>
why it called linux?
<MrBar>
it android quality code for low cost phones
<ssvb>
MrBar: did you come here to cry on somebody's shoulder? ;)
<MrBar>
:)
leviathanch has joined #linux-sunxi
<ssvb>
the drivers are being fixed, cleaned up and mainlined, but this process is somewhat slow
<ssvb>
jemk: the dram host ports configuration also has "0x240 APR arbiter period register" and "0x244 PLDTR priority level data threshold register"
<wens>
oliv3r: hi there!
<ssvb>
jemk: I tried to play with them a bit, but without much success
<ssvb>
jemk: if the arbiter could be configured to make DEBE behave better, that could be also a potential solution
<ssvb>
jemk: but I'm somewhat happy that at least DEFE seems to be problem-free now
cubear has joined #linux-sunxi
massifr has joined #linux-sunxi
<MrBar>
great code from drivers: if (sunxi_is_sun4i()) msleep(20);
<MrBar>
sun4i too fast
lioka has quit [Ping timeout: 252 seconds]
<massifr>
cubear: thanks for your answer last friday; I had not marked my absence and I did not answer you; I apologize for that. Anyway, I've ordered the serial cable from olimex
<cubear>
massifr: There is a UART0 port on your board, connect the serial cable to that (only connect GND, RX and TX, do not connect VCC), and see what debug info the board outputs
lioka has joined #linux-sunxi
<massifr>
in a few days I'll have the cable; I've tried with an Olimexino-32U4 (@3.3V) acting as a sort of "serial port repeater", but that did not work; the board seems dead, but let's see what I can get from UART0 with the right cable
rz2k has joined #linux-sunxi
tomboy65 has quit [Ping timeout: 272 seconds]
<MrBar>
nice programing challenge – WEEK #51 from olimex
<specing>
Why do I have a feeling they publish these challanges one week too late?
<MrBar>
:)
<Wizzup>
lol
lioka has quit [Ping timeout: 245 seconds]
<specing>
No seriously. It has only happened to me once that I saw their challenge before it was due
<specing>
and even then it was on a sunday ~3h from the deadline
wickwire has joined #linux-sunxi
<MrBar>
someone know quality level of linux drivers code for i.MX based boards?
<Wizzup>
It did seem like a nice challenge
antony11 has joined #linux-sunxi
lioka has joined #linux-sunxi
lioka has quit [Changing host]
lioka has joined #linux-sunxi
massifr has quit [Quit: Sto andando via]
MrBar has quit [Quit: Leaving]
orly_owl has quit [Ping timeout: 264 seconds]
atiti has quit [Ping timeout: 252 seconds]
deasy has joined #linux-sunxi
leviathanch has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
orly_owl has joined #linux-sunxi
mrsalomao635 has joined #linux-sunxi
<mrsalomao635>
ssvb: I tried disabling the ShadowFB option in the xorg.conf file, but the problem persists. I've made a new video just to clarify what my problem is to others who might be willing to help: https://www.youtube.com/watch?v=Jo8qbR5xG50&feature=em-upload_owner
mrsalomao635 has quit [Client Quit]
lioka has quit [Ping timeout: 252 seconds]
leviathanch has quit [Ping timeout: 240 seconds]
bgal has joined #linux-sunxi
leviathanch has joined #linux-sunxi
lioka has joined #linux-sunxi
lioka has quit [Client Quit]
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
leviathanch has quit [Ping timeout: 264 seconds]
libcg has joined #linux-sunxi
leviathanch has joined #linux-sunxi
nove has joined #linux-sunxi
deffrag has joined #linux-sunxi
bgal has quit [Ping timeout: 252 seconds]
<nove>
The correct message isn't been transmitted, and i don't know what wiki should have, other than more big red notices
<Turl>
specing: olimex published their challenges every friday, and they're due every sunday
Gerwin_J has joined #linux-sunxi
<Turl>
publishes*
<rellla>
nove: :)
<Turl>
nove: let them be, they're talking about odroid :)
<rellla>
nove: kind of a mixer in various forums, where sunxi/mali/cedarx is put together
shineworld has joined #linux-sunxi
<rellla>
and nobody is asking or reading about the facts. just making a statement to have posted something. kind of frustrating...
<nove>
did you also saw the linked mythtv thread
<rellla>
vdpau seems to sit on blob drivers. yeah kind of, libmali if you want to :)
<rellla>
don't waste your time, nove. it's more worthful!
leviathanch has quit [Ping timeout: 240 seconds]
<nove>
well is the expected, when a gpu is required to display pixels in a screen => wayland
<libv>
...
<libv>
nove: a gpu cares mostly about pushing pixels to some memory
<Turl>
it's just that the people are stuck in the x86 paradigm
<Turl>
where they buy "a GPU" that pushes the pixels, does the 3D and decodes their video
<libv>
which is not true
<libv>
it's just as modular on x86
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<libv>
but it does tend to fit on the same discrete graphics chip which is stuck on a separate graphics card
<libv>
the blocks on that chip are segmented similarly as they are on an ARM SoC
<libv>
the difference is that the same gpu, media, 2d and display engines tend to always occur as a set, and that the gpu does not tend to get paired with a completely different display engine
<libv>
unless you of course consider ati radeon r500
<libv>
where the display engine was completely written from scratch (and was a thing of beauty), whereas the gpu and 2d accel remained the same as from r300
<nove>
libv: i know, was only criticizing wayland, that is creating a requirement of a need for a gpu to have a working desktop environment
<libv>
nove: people have been trying to work to that requirement for a decade
<libv>
nove: and there was a time when people didn't even want to care about the display/modesetting side of things
<Turl>
"if it's there why not use it?"
<libv>
Turl: i didn't make many friends with statements like that
<libv>
another good one was "if it is separate in hardware, why can it not be separate in software?"
<Turl>
libv: I've seen such statements many times on discussion about using gpu for compositing and drawing all the things
<libv>
Turl: arguing for using only the gpu?
<libv>
that's just laziness
<nove>
but wayland is a nice plan, to force the blobs to follow FLOSS standards
<libv>
just like the current intel graphics driver stack doesn't want to care about synchronization of the different engines, outside of the gpus command queue
<libv>
nove: eh?
<libv>
nove: what floss standards are that?
<nove>
libv: i mean, to play well with kms, gallium and so
<libv>
nove: so what about the rpi support?
leviathanch has joined #linux-sunxi
<nove>
libv: yes that is different, but i think is not feature complete
<libv>
so not much forcing there
<nove>
libv: i am speaking of i don't know, so if wayland can be implement without a gpu great, but wasn't designed to fit the way modern gpu work
<libv>
nove: i caused a minor stirr two years ago when i went to try to find out whether it worked on plain fb with software rendering
<libv>
nove: seems no-one thought of implementing the absolute basic set of requirements, not even to be able to verify tests against
<libv>
wayland is for intel, and from time to time, radeon and nouveau were also allowed to play, to the extent that they had to just implement what intel was doing
<libv>
but this changed now that they have the rpi support
<libv>
wayland is not a big political plan to get more open source support
<juanfont>
nove, not yet. I've been pretty busy :(
<nove>
juanfont: ok, it up to you if you do it
<nove>
juanfont: i will go with a wrapper, as you see above, this blobs have artificial software limits in it
<juanfont>
I know. But I'm not very sure if it would be very interesting. I mean... the encoder expects a very particular format (probably from a camera). Having something like this http://www.raspberrypi.org/forums/viewtopic.php?f=70&t=25022 could be really difficult
<nove>
juanfont: hardware decoder => hardware encoder, is possible without conversion
<juanfont>
is the hardware capable of handling that?
<nove>
juanfont: but software decode => hardware encoder, in this case conversion is need
bbrezillon has joined #linux-sunxi
<nove>
the hardware encoder use a subengine isp but even doesn't accept normal rgb as input
<nove>
juanfont: if what you want to transcode can be decoded by hardware, yes
<nove>
juanfont: new versions of cedar hardware, can even do tasks of decode/encode simultaneous (must be verified)
xinj has quit [Read error: Connection reset by peer]
rz2k has quit []
<juanfont>
where did you get that info? Are we sure old hardware is not capable of doing that?
<nove>
juanfont: old version can be done, by interleaving decode1 => encode1 => decode2 => encode2
<nove>
juanfont: new can decode1 => decode2/encode1 => decode3/encode2
<juanfont>
that shouldn't be imposible to implement :)
<jemk>
juanfont: i'm trying to write a v4l codec driver, but i'm not sure wether that will work
<juanfont>
i didn't even know that existed
HeHoPMaJIeH has quit [Remote host closed the connection]
<nove>
jemk: lets do how wingrime said, before writing source code, lets go step by step check each v4l controls and what hardware must do
<jemk>
i'm not worried about that, it fits pretty good. but normally firmware handles all the hard stuff (header decoding, reference picture handling...), we would have to do that in kernel space and i don't know if that is acceptable
<mrsalomao>
ssvb: I tried disabling the ShadowFB option in the xorg.conf file, but the problem persists. I've made a new video just to clarify what my problem is to others who might be willing to help: https://www.youtube.com/watch?v=Jo8qbR5xG50&feature=em-upload_owner
<mrsalomao>
ssvb: sorry for double posting this, just want to make sure my message doesn't get buried :P
<Wizzup>
I have small Q about fex; I have enabled uart0 and uart2 (port 0 and 2 respectively, set with uart_port)
<ssvb>
mrsalomao: can you check the cpu usage when running es2gears? is it 100% or less than that?
<Wizzup>
when booted (after generating script.bin), it seems that /dev/ttyS{0,1} are both "working"
<Wizzup>
where working really means, cat doesn't give an error
<Wizzup>
I'd expect ttyS{0,2} to be the working ones
<Wizzup>
(there are not others enabled, except for the uart_port=0 and uart_port=2
<Wizzup>
no others*
<mrsalomao>
ssvb: gonna check, brb
<Wizzup>
nevermind: [ 1.144590] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 3) is a U6_16550A
hansg has quit [Quit: Leaving]
<blsd>
hey guys did anyone try weston on cubietruck?
discopig has quit [Ping timeout: 245 seconds]
<jemk>
ssvb: it looks like bwdsp100 has a very similar memory controller, they have [13:12] trnkrtr and [15:14] trnkwtw
<jemk>
ssvb: and i don't have any problem with setting ram to sequential (on a20), it boots and tinymembench reports lower bandwidth
<ssvb>
jemk: hmm, maybe I need to try it again with sequential, on both a20 and a10
shineworld has left #linux-sunxi [#linux-sunxi]
discopig has joined #linux-sunxi
<ssvb>
jemk: do you have a link to this bwdsp100 memory controller information?
<mrsalomao>
ssvb: Indeed, CPU usage is very high, at 100%
<mrsalomao>
ssvb: What do you think could be causing this? I did the same benchmarking with a QT4 application I developed myself and the same happened. Notice I didn't even implement mouse handling callbacks, so it must be something prior the the application layer, I think.
<ssvb>
jemk: google does not return anything usable for me when asked "bwdsp100 trnkrtr"
<ssvb>
mrsalomao: apparently you don't have "fb0_framebuffer_num = 3" in your fex file
<ssvb>
mrsalomao: but in any case, it is partially a cubiuntu configuration issue
<mrsalomao>
Hmm, I remember that value was '4' by default in cubiuntu
<ssvb>
mrsalomao: is it still set to 4? anything biggger than 2 should be fine
<mrsalomao>
ssvb: Hmmm
<mrsalomao>
ssvb: yes. :/
<ssvb>
mrsalomao: can you pastebin your /var/log/Xorg.0.log somewhere?
<mrsalomao>
ok
<jemk>
ssvb: does google really produce different results for me? the first and only result is exactly what i have used (yes, its chinese)
mrsalomao2 has joined #linux-sunxi
<ssvb>
jemk: should I load this flash crap from this link?
bgal has joined #linux-sunxi
<jemk>
ssvb: i guess so, i think to download it one has to pay
<ssvb>
jemk: heh, I have flash blocked in my browser
<jemk>
i didn't find anything else, but the information is pretty valuable once you figure out what it means
<ssvb>
jemk: did you pay them yourself or something?
<jemk>
ssvb: i used the flash thing
<mrsalomao2>
ssvb: that was my Xorg.0.log. This is is my .fex, in case you are interested too: http://pastebin.com/LKM1Czzg
<mrsalomao2>
ssvb: In case there's anything else you need, just tell me, I'm sending this from my cb2, now
Gerwin_J has quit [Quit: Gerwin_J]
FR^2 has quit [Quit: Connection reset by peer]
<ssvb>
jemk: sorry if I'm bothering you with this trivia stuff, but could you please google translate what they say about [13:12] trnkrtr and [15:14] trnkwtw there?
<jemk>
ssvb: that's the problem, you can't copy paste it...
<ssvb>
jemk: heh, maybe wens can help?
<ssvb>
jemk: based just on the name, sounds like something read-to-read and write-to-write truncate?
<ssvb>
mrsalomao: does it look more like 70-80% and not 100%?
<ssvb>
mrsalomao: also you have two cores, so I'm not sure how to interpret this indicator
<jemk>
ssvb: the first two characters mean different and then there is rank in latin characters, so i guess its some timing when switching ranks (which we don't use on any board i know of)
<ssvb>
mrsalomao: can you run 'htop' in a separate terminal and check what it says?
<jemk>
ssvb: but more i don't understand
<ssvb>
jemk: ok, thanks :) I guess we can safely ignore these bit fields, and maybe just run some tests with setting them to all 0 and all 1
<ssvb>
jemk: about the other bit fields, are they in the same place with the same names in bwdsp100?
<jemk>
ssvb: yes, i think all i checked till now are exactly the same, but the controller is for ddr1/ddr2, so there is some difference
<jemk>
ssvb: and for refresh timing there is this magic subtract 200 I removed in our u-boot because i thought its some allwinner added stuff
<ssvb>
jemk: I guess either way is fine, that's the interval between refreshes, it is temperature dependent and probably still has a lot of safety margin
<jemk>
ssvb: yeah, for normal temperatures it should be no problem, lets hope nobody wants to run it at 80C
<ssvb>
jemk: but tRFC (the duration of the refresh itself) is 260ns for the MEMPHIS dram chips in A10-Lime, while JEDEC suggests to have it as 300ns for density 4096
<ssvb>
jemk: we can shave off the whole 40ns :)
<ssvb>
mrsalomao2: and what happens if you don't move the mouse around?
<jemk>
ssvb: uh, i really didn't mention that. [22]:16] reserved, [26:23] XCL, [30:27] XWR, [31] TP, the reserved matches exactly to what happens when writing ~1 to tpr1
<mrsalomao2>
Thats without moving the mouse
<jemk>
s/~1/-1/
<jemk>
ssvb: but don't ask me what those mean again ;)
<ssvb>
mrsalomao2: based on the screenshots, everything looks normal, there is nothing to fix
<ssvb>
mrsalomao2: in the graphics drivers setup at least
<mrsalomao2>
ssvb: so what could explain a 50fps drop for moving the mouse around?
<ssvb>
mrsalomao2: well, maybe because you are moving the mouse around and disturbing it by doing this?
<mrsalomao2>
ssvb: yea, I expected this to cause a performance hit. But not such a big one
<mrsalomao2>
ssvb: but maybe thats the price we pay for having HWCursor (?)
<ssvb>
mrsalomao2: what is your cpufreq governor?
<ssvb>
mrsalomao2: does it work better with the software cursor?
<mrsalomao2>
ssvb: idk, how can I see that?
<ssvb>
mrsalomao: run 'cpufreq-info' in the terminal
<mrsalomao2>
ssvb: nope, HWCursor is way better, overall
<mrsalomao2>
cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: sunxi CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 2.00 ms. hardware limits: 60.0 MHz - 1.01 GHz available cpufreq governors: userspace, interactive, performance current policy: freq
<ssvb>
what does it say about the current governor? and please use pastebin for large logs
<Turl>
mrsalomao2: maybe you can try the newer one that uses the 2 mali thingies
<Turl>
ssvb?
<mrsalomao2>
Turl: the new mali blobs?
<Turl>
there's a newer set of blobs to use the two PPs I think (or what are they called?)
<Turl>
but you need to upgrade the kernel driver as well
<Turl>
ssvb should be able to explain :)
<mrsalomao2>
Turl: I'm not quite sure if I'd be able to accomplish that ahahhaha. I'm a poor Ubuntu user mortal
<ssvb>
jemk: tried DRAM_DCR_MODE_SEQ on the cubieboard2 and the cubieboard1, the former boots and the latter does not
<ssvb>
jemk: sigh, and we really want to test this specifically on Allwinner A10 (cubieboard1)
smotocel69 has quit [Remote host closed the connection]
_massi_ has quit [Remote host closed the connection]
<ssvb>
mrsalomao2: well, it looks like es2gears just sucks and uses too much cpu for whatever reason
<ssvb>
mrsalomao2: try some other gles app :)
<mrsalomao2>
ssvb: I tested it with a simple opengles application I did too, using QT
notmart has quit [Quit: notmart terminated!]
<mrsalomao2>
ssvb: all it did was display a rotating cube. Nothing else. Didn't even receive mouse events.
<ssvb>
mrsalomao2: there is always a rotating horse, aka glmark2-es2
<jemk>
ssvb: ok, then a10 is really different
<jemk>
ssvb: i've updated tpr registers in wiki
<jemk>
ssvb: i'm pretty sure this is correct, all sources i found till now and compared to writeable bits
<mrsalomao2>
Ok, just tested it. First 2 sub-benchmarks in glmark-es2 (NOT MOVING THE MOUSE) -> [build] use-vbo=false: FPS: 243 FrameTime: 4.115 ms [build] use-vbo=true: FPS: 330 FrameTime: 3.030 ms
<ssvb>
jemk: thanks!
<mrsalomao2>
Now moving the mouse -> [build] use-vbo=false: FPS: 88 FrameTime: 11.364 ms [build] use-vbo=true: FPS: 54 FrameTime: 18.519 ms
<mrsalomao2>
From 243 FPS to 88 FPS
<mrsalomao2>
From 330 FPS to 54 FPS
<mrsalomao2>
Btw, I noticed that if I use a Wacom tablet I have laying around here, the performance impact is much smaller
diego_r has quit [Ping timeout: 252 seconds]
<mrsalomao2>
glmark-es2, moving the mouse around with a Wacom tablet:
<mrsalomao2>
[build] use-vbo=false: FPS: 215 FrameTime: 4.651 ms [build] use-vbo=true: FPS: 267 FrameTime: 3.745 ms
<ssvb>
jemk: actually the cb1 is not completely dead, I get a nicely colored garbage on the monitor before it dies, so it at least tries to initialize disp
pseudomind has joined #linux-sunxi
<ssvb>
jemk: but it's in a nice plastic box and I'm reluctant to unscrew it to connect the serial console :)
<mrsalomao2>
Sorry, ignore the last mouse moving benchmark, it was that bad because there was another console window on top of it. Here's an unbiased one:
<mrsalomao2>
[build] use-vbo=false: FPS: 210 FrameTime: 4.762 ms [build] use-vbo=true: FPS: 248 FrameTime: 4.032 ms
smotocel69 has joined #linux-sunxi
<mrsalomao2>
Interesting fact: moving the mouse inside the opengl window causes a noticeable smaller framerate impact
<mrsalomao2>
instead of falling from 350 fps to 260, it falls to about 300