<pirea>
hglm i have the same problem with cubian(debian)
<hglm>
pirea: I think it is up to mplayer to blend the subtitles -- maybe there is an option or work-around in mplayer to show subtitles.
<pirea>
hglm mplayer
<hglm>
pirea: Which video player?
<hglm>
I think the decode layer before xv (for example gstreamer) blends the subtitles into the YUV data, then xv converts the YUV to RGB (hardware disp layer).
<pirea>
hglm but with another vo like xv it's working
<hglm>
pirea: I would assume libvdpau doesn't directly deal with subtitles.
<pirea>
hglm tnx
<hglm>
pirea: I think subtitle may be fairly complicated, because it involves something beyond the raw video buffer,
<hglm>
Well I fixed an issue with gcc 4.8.2 that I had with a C++ class that involved reinterpret_cast -- not sure if the code is actually wrong or it is a compiler bug. At least it didn't show up on earlier gcc versions like 4.7.
<hglm>
popolon: So current linux-sunxi kernel does not work when compiled with gcc 4.8.2?
<hglm>
I know for sure the gcc 4.8.2 on current Debian unstable is BROKEN because it fails with -O2 on some floating-point intensive C++ code...(works OK with -O).
<hglm>
popolon: gcc-4.8 worked for me sunxi a few months ago (after a kernel memset patch was appplied), but haven't tried 4.8 for the kernel recently (only 4.7).
2013-11-26
<hglm>
I have played mainly with gstreamer with xv backend (which is accelerate YUV conversion with fbturbo driver) and it's usable on an A20, because chip has reasonable horsepower to decode video up to a reasonable sizde.
<hglm>
tomee: I haven't tried video decoding on Allwinner yet, only disp layer color conversion backends, but it does sound interesting...does VDPAU work OK?
<hglm>
My tablet was rooted, and I can easily the change the governor, but if it is not "fantasys" the kernel keeps spewing "Governor is not fantasys" warnings...
<hglm>
tomee: In Anroid I think the fantasys governor's main task is to maximize the CPU speed when a benchmark (such as Antutu) is detected...my tablet had a completely broken Android chip configuration, runs at 720 MHz but when Antutu runs (and only then) it goes to 1008 MHz...
<tomee^>
hglm: btw I took the liberty of editing some of the wiki pages you edited recently
<tomee^>
hglm: maybe a stupid hack to circumvent all those "cpu tweakers" for android? no idea, didn't look into the code.
<hglm>
On the subject of performance, I am not quite sure what the point is of Allwinner's fantasy (fantasys on Android) CPU speed governor...all it does is pretend the CPU keeps running at 912 MHz, but actually slows down every 10 seconds or so (which is not reported in the /sys fs). I get the impression it was an ugly hack to combat ill-perceived hardware problems, but in my experience is completely unnecessary...for example a tweaked ondemand
<hglm>
It would be fun to try DRAM at 480 MHz (which is very good for performance) while keeping MBUS lower at about 400 MHz -- if that's stable that would be nice.
<hglm>
Sound good.
<Turl>
hglm: I'll send a series of patches for uboot in a bit
<hglm>
I was also able to reduce the CAS timing for the DRAM from 9 to 6 cycles (u-boot DRAM configuration), at 432 MHz -- gives another small boost in performance.
<hglm>
So dcdc3 is basically the DRAM voltage?
<hglm>
Ah OK
<Turl>
hglm: no, dvfs is done on dcdc2 iirc
<hglm>
Turl, I guess that voltage bump is not too dramatic...does the CPU voltage scaling in the kernel affect dcdc3?
<Turl>
hglm: dcdc3, 1.25v->1.3v
<hglm>
Turl: voltage bump of CPU?
<hglm>
Turl: Yeah but tht was at 480 Mhz which is high...I guess MBUS need to be clocked lower.
<Turl>
hglm: we got confirmation from aw that 400MHz should be stable though with a small voltage bump
<Turl>
hglm: higher mbus caused problems with the mmc controller during ssvb's tests though
<hglm>
..and increasing MBUS speed to DRAM speed gives a nice performance boost, as does raising DRAM clock from 408 to 432 MHz. I guess it could help to to make MBUS more configurable in u-boot.
<hglm>
I have A20 device that didn't run stable with 432 MHz DRAM clock (only 408) and default MBUS (memory controller) clock but it is perfectly stable after bumping up MBUS speed to the DRAM speed (using the patch on the mailing list)...
2013-11-24
<hglm>
tomee: Mali works fine me at 1280x720 (also faster even with same window size when compared to driving the monitor at 1080p). If you want to see more effect of the two pixel processors with the latest mali driver it should show up with a higher window resoluton -- for example running glmark2-es2 with the --size argument (default is 800x600).
<tomee^>
hglm: My TV has a native res of 1280x720 so I can't say about 1080p
<hglm>
Well, not tearing within the Mali window, but just waviness/oscillation over the whole screen because the chip can't read memory fast enough for video output (HDMI).
<hglm>
tomee: Did you encounter any "wavy screen" issues when running Mali in X? Looks like a DRAM contention issue with the disp layer interface. It only shows when the HDMI resolution is set to 1920x1080.
<hglm>
However when I just inserted a USB stick the kernel/USB driver crashed...USB didn't work anymore.
<hglm>
I have A20 kernel with Inventra sunxi-musb (OTG) enabled (sunxi-3.4 branch). If driver is not enabled, USB has no power.
<techn__>
hglm: oh.. It's disabled in default a20 defconfig
<techn__>
hglm: I tried A20 OTG port.. looks like it doesnt work
<hglm>
Hmm, haven't tried USB stick yet...only mouse/keyboard with mini-hub (non-powered). Will try now.
<techn__>
hglm: usb works with stick rom?
<hglm>
OK. usbc1 is type 1 though (usbc2 is WiFi on my device).
<techn__>
hglm: then patch should have on effect
<hglm>
usb_port_type = 2
<techn__>
hglm: usb_port_type on usb0
<hglm>
techn: Yes, I edited already (fixed WiFi and memory clock), what should I look for?
<techn__>
hglm: fex file somewhere?
<hglm>
techn: OK, I have a A20 tablet.
<techn__>
hglm: which device you got?
<techn__>
hglm: should apply on both?
<hglm>
techn__: Is the patch for suni-3.4 or stage/sunxi-3.4 branch?
<hglm>
arokux2: I don't have a Hackberry...I only have an A20 tablet (and a A10)...the USB power problem seems to occur with many tablets as well.
<arokux2>
hglm: can you please test?
<arokux2>
techn__: hglm has hackberry.
<hglm>
buZz: I also started with a 100% software renderer -- then rewrote for OpenGL 3.0.
<hglm>
buZz: It isn't public atm, but I though about it. Unity seems to OK judging from some Android games using it with good results.
<buZz>
hglm: cool, now make it as popular as unity!
<hglm>
buZZ: I have written a 3D engine (developed on PC OpenGL) that works pretty well on GLES2 with the same code base and shaders (and some #ifdefs). And Mali is reasonably fast as long as you don't do per pixel lighting for the whole scene.
<mickoo>
hglm: ok.. i'll try to compile it.. where can i find source?
<hglm>
mickoo: Yes, there are other GLES2 apps but not many. glmark2-es2 is nice but can be hard to compile.
<mickoo>
hglm: okk thanks.. so if sunxi-mali "test" triangle is shown then it should be allright..
<hglm>
mickoo: the message doesn't mean anything, Mali GLES2 should work...try test/test.
<mickoo>
hglm: is that wrong?
<buZz>
hglm: sure, its just that nearly nobody is putting in that effort
<hglm>
bUZz: Even though OpenGL ES2.0 is pretty close API-wise to modern use somewhere between OpenGL 2.0 and 3.0 -- so a GLES2 back-end is often possible given some effort.
<mickoo>
hglm: Yes, sunxi mali compiled after libdri2
<hglm>
mickoo: I also get the AIGLX error in my X server logs, but Mali GLES2 works. AIGLX refers to regular OpenGL drivers which are not supported with hardware acceleration.
<hglm>
mickoo: Did you compile sunxi-mali after first installing the seperate libdri2?
<hglm>
arokux: I noticed you changed my USB power problem reference in linux-sunxi.org/USB to refer to Hackberry only, but it happens on my A20 tablet as well and I think it happens on most tablets even with A10...
2013-11-23
<hglm>
tomee: Not sure, I think the Mali integration in fbturbo uses the "disp" layer interface, not g2d (which is 2D graphics bitblt acceleration).
<tomee^>
hglm: would probably be even better if I managed to transplant g2d into that kernel
<hglm>
tomee: Some of those subtest benchmark scores are much higher than what I got with my A20. For example the jellyfish benchmark I think was 40fps and your result shows 126 fps. The actual real-world performance increase may be larger than indicated by the "glmark2 Score".
<hglm>
libv: Regarding Mali drivers in framebuffer mode, I do see some tearing or region copy effect (some screen areas seems to be updated earlier than other parts), it doesn't seem to be doing tear-free page-flipping). Is that correct?
<hglm>
OK
<libv>
hglm: what do you want to find out with this?
<hglm>
I mean PC class like nvidia/AMD opengl drivers.
<libv>
hglm: "regular openGL shaders"? means what?
<libv>
hglm: ?
<hglm>
libv: Does the shader compiler in the Mali driver optimize to the extent that regular OpenGL shader compilers do? Or does it need more tuned shaders?
<hglm>
Yeah so triangle rate is unchanged from MP1 to MP4 at a given clock speed, but fillrate is basically quadrupled.
<hglm>
I have tested some of the my own GLSL shaders/3D engine and it doesn't do badly but slows down on more complex shaders (e.g. normal mapping not implemented in the most optimal way) that work fine on PC-class hardware.
<hglm>
tomee: That could well be the case. Performance on the A20 seems to be too low compared to A10 given the two cores in the Mali400MP2.
<tomee^>
hglm: but aside from the blob, I need a kernel module first ;-)
<tomee^>
hglm: someone said the improvement would be ~2x. r3p0 only uses 1 core if I am not mistaken?
<hglm>
tomee: Yeah, there might be some improvements in more recent Mali blobs. Theoretically it may also be possible to tweak Mali GPU speed on the A20.
<tomee^>
hglm: I wonder what it would be if I managed to build an r3p2 kernel module...
<tomee^>
hglm: yeah, exactly, my score is 152.
<hglm>
tomee: Regarding those glmark2-es2 benchmarks I think it is probably an A10 with the vsync locked at 60 Hz. I don't think the Mali in the A20 is that much faster than the one the A10 (A20 has low Mali clock speed) but I got something like 150 fps final score running glmark2-es2 on my A20 device with vsync unlocked and fb0_framebuffer_num set to 3 in script.bin.
<oliv3r>
hglm memory speeds from script.bin do not influence u-boot nor the kernel; so that shouldn't make a diference :)
<ncrmnt>
hglm: Hm... Good that's not become a tradition. In rockchip kernel they are doing ddr freq/voltage scaling in runtime with a super-special buggy kernel hack.
<hglm>
ncrmnt: Don't know but in linux-sunxi tinkering with memory timings is only done in the bootloader (not kernel), although the kernel does support CPU voltage and frequency scaling.
<hglm>
Clock for clock single threaded performance seems to be quite a bit faster (about 80%) on the A20 than the A10 at the same clock speed (probably due to Cortex A7 vs A8 and better caches/memory interface).
<hglm>
Also the ondemand governor works very well but the default threshold settings are awful -- change them and you get a very fast/responsive system that still revs down to low speed when idle (unlikely the erratic behaviour of the default fantasy governor).
<hglm>
OK, I will.
<plaes>
hglm: please add to wiki
<hglm>
The memory clock was set to 432 MHz in script.bin which is totally unstable on this device! Changed it to 408 MHz and now everything is rock-solid so far...
<hglm>
I am surprised how well/fast this A20 tablet is running after being configured properly -- the default script.bin file provided was totally screwed up and Android was unbelievably crippled (lockups, low speed, power-grabbing governor, but completely avoidable it seems).
2013-11-21
<tomee^>
hglm: point taken. I've tinkered around Mesa, OpenGL (when it was SGI-proprietary), x86 and AVR assembly, but I can't possibly comprehend all of those nuances of Axx SoCs in a week...
<hglm>
tomee: glesmark is GLES but isn´t 100% compatible with sunxi´s Mali setup out of the box and has an awkard build system
<hglm>
I must say my A20 has been very unstable (CPU-related) when doing intensive tasks -- however I have found cpufreq setting that seems to be relatively stable (underclocking severely but L2 cache and memory speed seem to be preserved).
<hglm>
You mean file access is slow? I did notice a programmed I/O vs. DMA option in the Inventra (MUSB) driver -- the default is PIO which is likely to be slow but I don´t whether DMA can work (not tested it).
<hglm>
Disabling power saving on my rtl8188 chip doesn´t seem to be necessary.
<hglm>
fb_mem_reserve?
<hglm>
OK I am a little rusty :)
<arokux2>
hglm: i think it is enough to see it in ip a s
<hglm>
Yeah that info helped. Finally I had to fight a little with udev to get it recognized, /dev/wlan0 or wlan1 still doesn´t show up but I can run wpa_supplicant which recognizes it.
<arokux2>
hglm: there is info about 8188eu at that page
<hglm>
I also disabled USB suspend in the driver with a module load option, not sure it´s necessary.
<hglm>
Second problem was that the RTL8188EU in my device has a newer USB device ID that the 8188eu driver doesn´t recognize, I found a kernel patch on the net but I think you can also update it with the sys file system.
<arokux2>
hglm: hm.. ok
<hglm>
(usb_host_init_state in the usbc2 section of the fex file)
<hglm>
My fex file had the WLAN USB disabled on boot, I had to change the host_init value for usbc2 to 1 (it was 0). Then the device showed up on lsusb.
<hglm>
OK as I said I am running sunxi-3.4 with the Inventra USB driver enabled (Allwinner glue layer)
<arokux2>
hglm: oh! so tell the world what you did!
<hglm>
I got wifi running but it was a bit messy :)
<hglm>
arokux2:
<hglm>
This did not work with stage/sunxi-3.4
<hglm>
wezza: Using regular branch sunxi-3.4 I could restore USB power by enabling the "Inventra Highspeed Dual Role USB controller" with the Allwinner option.
<hglm>
OK, I will try the other kernel Allwinner USB OTG driver also, I will report my progress
<arokux>
hglm: if you want me to look at it. and please provide it in the form of an e-mail to ML
<hglm>
Yep, regular sunxi-3.4, but I have enabled the Inventra dual-role USB driver -- maybe that makes a difference
<arokux>
hglm: now it could be pure usb problem. are you using the branch where usb host works?
<hglm>
arokux: 8188eu.ko now loads correctly but /dev/wlan0 doesn´t show up and lsusb doesn´t list it.
<arokux>
hglm: did it work?
<hglm>
Yeah I will change it
<arokux>
hglm: it should be usb_wifi_para
<hglm>
OK, the parameters are also different (wifi_used=1 not usb_wifi_used=1 etc)
<arokux>
hglm: the kernel expects usb_wifi_para, so rename it and do not forget to run fex2bin
<hglm>
The section is called wifi_para not usb_wifi_para.
<arokux>
hglm: what?
<hglm>
OK there is a wifi_para section though in my fxex.
<hglm>
There is nho usb _wifi_para section in my fex/script.bin, but usbc1 and usbc2 are both set to usb_used = 1
<arokux>
hglm: but then if USB host isn't working it can be a cause why wifi isn't working, since wlan adapter is connected through usb.
<hglm>
checking
<arokux>
hglm: ^^^^
<arokux>
hglm: yes it is. all the allwinner based devices are the same.
<hglm>
It´s an internal tablet wlan chip -- I think it is connected with USB but not sure.
<arokux>
hglm: this is not related to "cannot allocate memory", but first you should make sure you are powering the usb that wlan adapter is connected too.
<arokux>
hglm: o_O
<hglm>
arokux: I think I have an rtl8188eu (on USB), but lsbusb doesn´t show it. Inserting 8188eu gives an "cannot allocate memory" error.
<arokux>
hglm: what is with WIFi? it can depend on usb btw :)
<arokux>
hglm: alright
<hglm>
arokux: OK I will ping when I am ready to try to dissect the USB problem
<arokux>
hglm: so you need to test 3 or 4 kernels and we know what is the problem then.
<arokux>
hglm: it is about 10 commits difference.
<arokux>
hglm: ok, once you have time for this, please ping me it should be easily solvable since there isn't much between stage/sunxi-3.4 and last sunxi-3.4
<hglm>
arokux: I will see if I can find something, first trying to get wlan going on my device
<arokux>
hglm: I can give you some how-to
<arokux>
hglm: can you do bisect?
<arokux>
hglm: alright
<hglm>
arokux: It´s the current ones as of today
<arokux>
hglm: can you give me a git hash of sunxi-3.4 and stage/sunxi-3.4 you are trying?
<arokux>
hglm: that is strange, it wasn't like this for Hackberry.
<hglm>
No, I haven´t tried power hub (don´t have one lying around), but the regular sunxi-3.4 (as opposed to stage/sunxi-3.4) works fine.
<arokux>
hglm: so powered hub solves the problem?
<hglm>
Yes
<arokux>
hglm: still there?
<hglm>
I can confirm that stage/sunxi-3.4 USB seems to broken (no USB power) for an A20 tablet. In linux-sunxi.org/USB, this issue with current stage/sunxi-3.4 is also reported for an A10-based Hackberry, so I guess this applies to many devices. However sunxi-3.4 branch works fine (I have enabled the Inventra dual-role USB driver with Allwinner option, didn´t try other drivers.
<hglm>
arokux: Thanks for the suggestion, I might try that.
<arokux>
hglm: connect a powered usb hub and then a device to it to check if this is a power problem
<hglm>
I have been able to get a A20-based tablet to boot stage/sunxi-3.4, but there seems to be a problem with USB...no power? I tried enabling the Sunxi dual-role USB 2.0 driver but didn´t help. Any hints?
<arokux>
hglm: first get wifi working with cubie/sunxi-3.4, then figure out how to cherry pick.
<hglm>
I noticed there are about four different drivers for BCM4330 (maybe BCM4329 also) in the stage/sunxi-branch currently, which are all enabled in the sun7i_defconfig, causing at least one conflict when compiling. I think it is better to just enable one of them...there might be one that works for CT (?)
2013-11-20
<arokux2>
hglm: I think so :)
<hglm>
arokux2: OK maybe I confused you with a different nick :)
<arokux2>
hglm: I do not understand what are you talking about
<arokux2>
hglm: what?? :)
<hglm>
arokux2: I noticed in the logs you were involved with the defunct fabless multimedia chip design company ESS? It´s funny because I used to follow it as an investor a long time ago.
<hglm>
Wh: Is that the framebuffer screensaver kicking in and blanking the display while X is running?
<hglm>
I am just imagining that the frames is related to buffer size (latency) and periods is the number of buffers...
<hglm>
I don´t really know what frames/periods really means, but have you tried fixing frames to 64 but increasing periods to a high number?
<hglm>
AutoStatic: Does the device work with such a small buffer?
<AutoStatic>
hglm: that's an option, especially given the information mnemoc just provided
<hglm>
AutoStatic: I can imagine there´s some kind of buffer for audio data used by the kernel codec driver, and the IO delay depends on how full the buffer is...maybe related to the way the Allwinner codec driver is designed. Maybe it could be worth trying to avoid the codec driver and use another type of I/O such as USB...
<hglm>
Probably something related to the kernel. I don´t have much experience with real-time though, did you see more consistent results on other platforms?
<hglm>
Is the IO delay mostly small but seeing delays regularly, or just all over the place?
<hglm>
AutoStatic: In that case the CPU speed should fixed on high so there must be a different cause...have you also changed the kernel scheduler (I think there exists a real-time setting)?
<AutoStatic>
Hi hglm, CPU governor is already set to performance
<hglm>
AutoStatic: Could be related to cpu scaling (cpu revving down to low speed such as 60 MHz). You could change the scaling governor to peroformance or increase the min speed.
<hglm>
slapin: I will double check the script.bin.
<slapin>
hglm: try with proper script.bin, it should boot. If not, solder serial port and look (but check tha there is no incompatible settings in your script.bin, or you will get lockups).
<slapin>
hglm: also mine had some rape done to power chip, which made me to put resistor on 5VDC to prevent heat during charge
<hglm>
slapin: I tried linux-sunxi on it a few months ago but didn´t work, I did run Linux (Debian) in a chroot environment on it. I can try again and tweak some kernel settings.
<slapin>
hglm: all different hardware is different, anyway
<slapin>
hglm: but it was running off smaller MHZ values. Check what prevents it from sleeping, like interrupt counters
<slapin>
hglm: mine was totally broken, could not live more than 40 minutes on battery and was very hot, but it is some cheap, like $56 or something.
<slapin>
hglm: dunno, mine was ok regarding power, but yours seems to have RAM problems, hence bus speed reduced.
<hglm>
slapin: Thanks, I did notice that Allwinners "fantasys" governor in Android rarely revs down from 720 MHz which isn´t good for battery.
<slapin>
hglm: btw, check that script.bin has no errors, too, mine had one pin set as output which led to fast battery discharge
<hglm>
slapin: It was not the cheapest tablet, has an IPS screen, and build quality not too bad at first glance. I am thinking it needs something drastic like disabling L2 cache.
<slapin>
hglm: $50-tablet? I had some like this, it is quite unstable
<hglm>
slapin: Good to hear, I guess it could be depend on the board as well as chip stepping etc. But at least in this Android tablet the chip seems to be crippled (runs at 720 MHz, locks up randomly, very low android 2D speed, screen refresh limited to 14fps for some reason). And it is not suprising that the A20 has failed commercially in the chinatab market.
<rz2k>
hglm: there was a topic somewhere around ML about hard lockups happening from time to time
<slapin>
hglm: and hardware quality varies.
<slapin>
hglm: /me, but I use A20 as headless appliance
<hglm>
Based on my limited experience with the A20 chip (Android tablet) I have some concerns about it (hardware side). Is anyone using the A20 without experiencing random unexplained hardware lockups? Is it adressable/has it been addressed with kernel changes such as config/CPU handling/governor/speed? I guess it is possible that certain hardware bugs may not be possible to work around...correct me if I am wrong.
<hglm>
libv: Yeah, I noticed the tablet has lower 3D benchmark throughput than older RK3188 devices with more aggressive firmware.
<hglm>
libv: I have the impression that Rockhip has lowered their clock rates in recent firmware -- for example I have a tablet that only runs at about 420 MHz for Mali (1.4 GHz CPU) -- the tech ref for the 3188 from Rockchip on the Radxa site also mentions 1.4 GHz as max CPu.
<hglm>
libv: Yes, I understand..also the memory paths/bandwidth is a lot higher in the RK3188.
<libv>
hglm: no, the frequency at which the chip is able to operate
<hglm>
libv: you mean threads?
<libv>
hglm: 2x of that is process based
<hglm>
The Mali400MP4 on the RK3188 is pretty fast..old GPU core but at 28nm fillrate is 8x that of A10.
<hglm>
zeRez: Not very, but kernel sources seem to be available now
<zeRez>
hglm yeah i read it...but from rockchip i know nothing, how linuxfriendly are there chips?
<hglm>
There is also an upcoming rockchip board (fast) from Cubie...google radxa
2013-08-28
<hglm>
Yeah it has 1G RAM, CPU at 912 Mhz, memory speed reported as 432 by script.bin.
<oliv3r>
hglm: a20 tablet, nice; 1G
<hglm>
BTW Has been any report of a A20-based tablet working (as opposed to dev boards)? I acquired one but didn't work on first try (have to be careful with new u-boot-sunxi though).
<hglm>
It seems to be related to the first commit of Tuesday (2b47db1501cfbe148dc7e722683eb0c910dca3d4).
<hglm>
It gives a compile error in the mali driver.
<oliv3r>
hglm: does it fail to compile or fail to run'
<hglm>
It looks like one of yesterday's commits into stage/sunxi-3.4 breaks compilation for sun4i. sun7i does compile. After backing out the last 5 commits, it compiles and works fine on sun4i.
2013-07-20
<hglm>
BTW: The new Realtek WLAN drivers in the latest branches appear to be significantly faster than the old ones, it looks like.
<hglm>
ssvb: I've delved into the kernel details but I have the impressions that these are 100% vendor-supplied drivers like Realtek 8192CU.
<hglm>
Yeah, there's something definitely wrong with NFS.
<hglm>
I don't, but I may look at acquiring one.
<hglm>
ssvb: Nope wlan
<ssvb>
hglm: are you also using wemac ethernet?
<hglm>
Correct me if I'm wrong but I had the impression from ssvb's comments that the performance problem is largely related to time-outs in the NFS driver, which makes things very slow, and which may be caused by the ethernet driver in one way or another. I am mentioning this because with NFS I have been time-outs when copying large file (on recent kernels, but also on sunxi-3.4 stable).
2013-07-19
<PiyushVerma>
that you every body very much to make it working ssvb hglm libv thank you
<hglm>
ssvb: Perhaps, it suspect may have to do with USB not being properly configured when I compiled stage/sunxi-3.4 with the default config.
<ssvb>
hglm: not sure if anyone really cares about this stuff, but it would be interesting to bisect to identify when it your wlan broke and when it got fixed again
<hglm>
Regarding stage/sunxi-3.4 stability, I couldn't get wlan to work on that branch, while it works with hansg's latest for-amery branch.
<hglm>
Piyush: You should use the linux-sunxi repo for Mali, ssvb for sunxifb.
<hglm>
I had to install the seperate DRI2 lib though as described on the wiki.
<PiyushVerma>
hglm: are u using ssvb repo of linux-sunxi ?
<hglm>
Piyush: Yep, test/test works.
<PiyushVerma>
hglm: ok so it's working ur side u able to render ?
<hglm>
PiyushVerma: Make sure you rerun autoreconf -vi and configure
<hglm>
I just installed sunxi-mali on my recent debian install, only problem I encountered was a dependency on XNextEvent in test/test from the sunxi-mali repository. I added -lX11 to fix it.
<PiyushVerma>
hglm: already did that going to do again
<hglm>
You probably have to reconfigure/recompile/reinstall sunxifb with the userspace X11 mali libs installed.
<PiyushVerma>
libv: as mention by hglm there there is 2 different binary one for fb and other for x11. when I build for fb then it works when build for x11 then error failed to open x display
<hglm>
PiyushVerma: Should be documented in the README.
<PiyushVerma>
hglm: ok checking option in make file
<hglm>
PiyushVerma: It's in the instructions for the userspace mali libs, it autodetects but you can add a commandline options to make.
<PiyushVerma>
hglm: thanks to point it out . any idea how to configure for x ?
<hglm>
only be intalled for either fb on X, not both at the same time.
<hglm>
PiyushVerma: AFAIK the userspace mali libs can onlt
2013-07-18
<ssvb>
hglm: good, thanks for testing
<hglm>
ssvb: I tried the tearing test videos, although not 100% smooth (which may be related to my LCD), there is no tearing apparent, while there is tearing when not using XV for video output. The sunxi_disp_vsync_demo also, while not 100% smooth, doens't seem to be showing tearing.
<hglm>
ssvb: Yeah that was in the console, it didn't quite look right (tearing). I'll test that again.
<ssvb>
hglm: but I remember you said something about sunxi_disp_vsync_demo not working properly some time ago
<ssvb>
hglm: indeed, looks like there are no problems with tearing in scaler mode
<hglm>
ssvb: Looks smooth to me on my A10, no tearing with limited testing and scaler mode is enabled on the screen.
<ssvb>
hglm: also I believe scaler mode has some problems with tearing (will try to verify it now)
<ssvb>
hglm: A13 has only one scaler, so the scaler mode should be a big problem there (no scaler available to the actual video layer)
<hglm>
ssvb: I have been trying the new sunxifb, it seems to work pretty well with mp4 playback in vlc, but I am running my screen in scaler mode, wasn't that supposed to be a problem or is that only devices like A13?
<hglm>
oliv3r: well, the defconfig by default selects host-only and that also doesn't compile.
<hglm>
Yeah the default config should be fixed so that usb0 is OTG (host + device)
<hglm>
ssvb: See the thread on the mailing list. You have to set the USB config precisely in the right way.
<hglm>
oliv3r: It may a little more complicated if the USB driver has been unified (from being completely seperate for sun4i, sun5i etc before).
<hglm>
Talking to myself there :)
<hglm>
hglm: That's true, it needs to be fixed properly.
<hglm>
oliv3r: I didn't try that patch, the branch compiles cleanly with the right USB options.
<hglm>
The sunxi-3.4-for-amery branch seems to run OK on my A10 and also fixes the wlan not working problem I had with the current stage/sunxi-3.4.
<hglm>
oliv3r: I don't know. Which patch do you mean?
<oliv3r>
hglm: the patch that's supposedly lingering on the mailing list; doe sit fix that?
<hglm>
drivers -> USB -> SUNXI USB2.0 Dual Role Controller support -> USB0 Controller Support -> otg support
<hglm>
drivers -> USB -> USB Gadget Support -> USB Peripheral Controller (X)) -> SoftWinner SUNXI USB Peripheral Controller (X)
<hglm>
You have to select:
<hglm>
wingrime: I don't know the exact status of the A20 support.
<wingrime>
hglm: witch hw work/not work?
<hglm>
oliv3r: I got the hansg's latest branch (sunxi-3.4-for-amery) to compile with USB support, by selecting the right USB options (not as modules) in the right order.
<oliv3r>
hglm: yeah disable USB is easiest fix :p
<hglm>
AFAIK jwrdegoede/sunxi-3.4-for-amery is more up to date then jwrdegoede/sunxi-3.4-a20-wip, but there might be configuration issue with USB that prevents a clean compile
<hglm>
libv: I see, it was just that in my experience with multi-pass rendering with Mali400 (with additive blending) it was slow.
<PiyushVerma>
hglm : sorry typo
<libv>
hglm: things are slightly different with 4 fragment shaders clocked twice as fast.
<libv>
hglm: mali400 on a10(s)/a10 just has a a single slow fragment shader
<hglm>
PiyushVerma: But in any case I have distinct impression that Mali400 was never designed to do compositing or blending well. In a 3D rendering engine anything related to brending/transparency is extremely slow on Mali400.
<hglm>
PiysuhVerma: Could be, maybe the framebuffer/configurations details that Qt5 wants are not available in the Mali driver.
<PiyushVerma>
hglm: ok
<hglm>
PiyushVerma: I am not very familiar with qt5, does it use compositing with GLES?
<hglm>
PiyushVerma: Is hellogl_es2 a qt5 application? Does the "test" program from the sunxi-mali repository work?
2013-07-17
<hglm>
pacopad: You may need to disable some drivers/stuff in the 3.4 wip kernel for A20...maybe there are some release notes/instructions you can find
<wingrime>
hglm: but perhaps, our PoC will work
<wingrime>
hglm: it need new blob as cedar blob check SoC version
<hglm>
pacopad: I doubt cedarx would work on A20 though out-of-the-box. Probably different version of cedarx in A20.
<hglm>
pacopad: I guess it's work-in-progress with not all devices supported. The more complete kernels right now for Cubieboard2 seem to be the cubie 3.3-based kernels.
<hglm>
pacopad: Which source tree are you using (sunxi-3.4, stage/sunxi-3.4, other) and which device?
<ssvb>
hglm: yes
<hglm>
ssvb: OK then it should just be hooked into the driver I guess.
<ssvb>
hglm: the NEON code to do the actual work already exists