[Q] 关于i500扩展ram 已经1080p硬解码
中国有个人研究出来 但是他没有共享 所以我们用不上了
在此我原文转发一下他帖子的内容 希望xda的大师们能研究出来
*Galaxy S盖世一代 超级内存再生技术 和 1080p视频硬解。
超级内存再生技术利用Galaxy S中最高速的RAM，等效约3.0GB/s的带宽，内存速度和性能0损失，目前实际系统可识别440MB（未来有望达450+M），加上内存分享技术，在Galaxy S设备上实现与768M内存机器（可识别550M左右）无差别的体验。
1080P视频硬解技术，也是一项在Galaxy S设备实现的重要突破。能硬解1080p相当于硬解性能与手机高端CPU无异（山寨RK的寨板不在手机范围内）
蜂鸟处理器在一些机器，如P1000,i997,Epic4G，均无压力1080P硬解。但对于标准的Galaxy S设备，如i9000/i897/t959/i500/i400等均无法1080p硬解。
私人优化，盖世一代的硬解已经能达ref=16，而普通P1000只能ref=6。ref指视频参考帧，测试视频性能时重要指标。
经过个多月的研究，已经基本稳定，无聊放出图赏。
图赏开始。
1.开机剩余可用内存，245MB，
2.关于系统
3.爆开豌豆，QQ，拉手，淘宝，酷狗，PPS，Apollo播放器，地图等，随着程序增多，单个程序占用会越来越小（内存共享技术）
4.1080p硬解。测试软件为DicePlayer，左上角HW表示硬解(HardWare decode)，SW表示软解(SoftWare Decode)
ref=1 1080p小试牛刀
[I
20121220_brokencity_60sectrailer_4000.mp4 某电影预告。
ref=16 1080P 完爆目前大部分高端手机
[
以上为原帖地址以及原文作者的思路
希望xda的大师们也能研究出来 让我们都能用得上
人比黄瓜瘦 said:
中国有个人研究出来 但是他没有共享 所以我们用不上了
Click to expand...
Click to collapse
Wish i could read Japanese...
I can tell it has to with that newly mentioned bigmem 1080 playback kernel...
In English
hhp_211 said:
Wish i could read Japanese...
I can tell it has to with that newly mentioned bigmem 1080 playback kernel...
Click to expand...
Click to collapse
[Q] ram has been extended on i500 hardware decoding 1080p
China has a personal research but he did not come out so we do not have access a shared
Here I forward the original content of the post about his hopes xda gurus can study out
* Galaxy S guise generation of super-regeneration technology and 1080p video memory hardware solution.
Super Memory renewable technology utilizes Galaxy S is the most high-speed RAM, the equivalent of about 3.0GB / s of bandwidth, memory speed and performance 0 losses, the actual system can identify 440MB (future is expected to reach 450 + M), plus the memory sharing technology In Galaxy S device to achieve with 768M memory machines (about identifiable 550M) undifferentiated experience.
1080P video hardware decode technology, but also the one in the Galaxy S devices to achieve an important breakthrough. 1080p capable hardware solution is equivalent to high-end hardware solutions and mobile phone CPU performance is no different (RK cottage Walled board is not within the scope of mobile phone)
Hummingbird processor on some machines, such as P1000, i997, Epic4G, no pressure 1080P hardware solution. But for the standard Ga laxy S devices, such as i9000/i897/t959/i500/i400 etc unable 1080p hardware solution.
Private optimization, unrivaled generation hardware solutions have been able to reach ref = 16, while the ordinary P1000 only ref = 6. ref refers to video reference frame, an important indicator when testing video performance.
After months of research, has been basically stable, boring release tushang.
Figure tour begins.
1 boot remaining available memory, 245MB,
2 About System
3 burst open peas, QQ, handle, Taobao, cool dog, PPS, Apollo player, maps, etc., as the program increased, occupy a single program will become increasingly smaller (memory sharing technology)
4.1080p hardware solution. Test software for the DicePlayer, HW represents the upper left corner hardware solution (HardWare decode), SW represents soft solution (SoftWare Decode)
ref = 1 1080p small test chopper
[I
20121220_brokencity_60sectrailer_4000.mp4 a movie trailer.
ref = 16 1080P after blasting Currently, most high-end phones
[
Above original post address and original author's ideas
Hope xda gurus also finding out so we can lingua franca
马甲飘过，黄瓜你妹，无图说个jb。。
马甲飘过，黄瓜你妹，无图说个jb。。
Related
Hi all,
I have been developing a small android app which is sort of a reader for results coming from a desktop application. Some of these results are in the shape of a 3-dimensional structure made of a number of basic geometries, which I have been generating using a library which I coded in C++ using OpenSceneGraph and compiled with NDK. I have tested my app on both my HTC 3D EVO (before on stock rom, then on a few gingerbread custom ROMS and finally on a few ICS roms too) and also on a crappy 7'' chinese tablet which I bought really cheap a while ago. This tablet has a pretty basic AllWinnerTech A10 single core 1GHz processor, 512 Mb RAM and a Mali 400 GPU. So nothing fancy at all. However in all my tests I get about 2 to 3 times as many FPS from the tablet compared to the EVO. The structure can be moved, zoomed in and out much more smoothly. Remarkably so!
Am I missing something obvious here? Is there a "turn on graphics acceleration, you idiot!" button which I have not found yet? I mean, just in terms of specs I would have expected the EVO to run circles around that tablet.
Has anyone got any idea?
Cheers.
Have you tried forcing HW acceleration threw your build prop to see if makes a difference on your setup??
#Root-Hack_Mod*Always\
debug.sf.hw = 1 already. anything else in the build.prop file that may improve this? Could it be a drivers issue, or is it just me expecting more that I should from this phone?
Are you hitting the frame limit cap ?
what would the value of this cap be? I barely go above 15-20fps on the smallest structures. anyway, don't get me wrong: I can live with it.
It was just curiosity, because I expected much better performance from the EVO. and so I was wondering where/what is the bottle neck
From what I understand HTC shipped the EVO 3D with terrible drivers, I think that they fixed this problem with the ICS update. With these drivers the Adreno 220 is able to surpass the Mali 400 mp4 (galaxy s2 version) in some situations.
I'm looking for hardware device on what compact device to hook up to my HDTV for turning it into a media center primarily and a light PC otherwise.
I'm interested in something like the RK3066 because it seems to have decent performance compared to the older single core devices.
Things it needs to do:
- run XBMC, stream media from fileserver via wifi
- stream another display to it in 1080p
So.. basically run Android or Linux effectively enough. This one supports bluetooth which seems useful for peripherals.
Things I might do with it:
- put linux and steam on it
- light browsing ans basic gaming
- hook a webcam to it
I've built full HTPCs before and I don't think I can do a compact one for anywhere near this price, even though it would be way more powerful. I also don't want a single purpose 'streaming box' solution that I can't replace the OS on. I see this as a cheaper way of doing 99% of what I want and I can still choose to replace it at anytime without feeling bad about it.
Any better performing options at this price, or similar options at lower price? Alternative hardware that I should be looking at?
Soldier Blue said:
I'm looking for hardware device on what compact device to hook up to my HDTV for turning it into a media center primarily and a light PC otherwise.
I'm interested in something like the RK3066 because it seems to have decent performance compared to the older single core devices.
Any better performing options at this price, or similar options at lower price? Alternative hardware that I should be looking at?
Click to expand...
Click to collapse
if you have a bit of patience a few new ones based on rk3188 are launching that are a lot better, not only they are way faster (quad core, faster gpu, 2gb ram - around 18k antutu just as reference) , they solved the overheating and EM interferences that plagues rk3066 ones.
NixZero said:
if you have a bit of patience a few new ones based on rk3188 are launching that are a lot better, not only they are way faster (quad core, faster gpu, 2gb ram - around 18k antutu just as reference) , they solved the overheating and EM interferences that plagues rk3066 ones.
Click to expand...
Click to collapse
That's exactly what I wanted to know, since I'm not normally following the latest for this type of hardware. Do you know when these might be available?
Last summer, I decided to buy a Nexus 7 for using it mainly as an ebook reader. It's perfect for that with its very sharp 1280x800 screen. It was my first Android device and I love this little tablet.
I'm a fan of retro gaming and I installed emulators on every device I have: Pocket PC, Xbox, PSP Go, iPhone, iPad3, PS3. So I discovered that the Android platform was one of the most active community for emulation fans like me and I bought many of them, and all those made by Robert Broglia (.EMU series). They were running great on the N7 but I found that 16GB was too small, as was the screen.
I waited and waited until the 32 GB Nexus 10 became available here in Canada and bought it soon after (10 days ago). With its A15 cores, I was expecting the N10 to be a great device for emulation but I am now a little disapointed. When buying the N10, I expected everything to run faster than on the N7 by a noticeable margin.
Many emulators run slower on the N10 than on the N7. MAME4Ddroid and MAME4Droid reloaded are no longer completely smooth with more demanding ROMs, Omega 500, Colleen, UAE4droid and SToid are slower and some others needed much more tweaking than on the N7. I'm a little extreme on accuracy of emulation and I like everything to be as close to the real thing as possible. A solid 60 fps for me is a must (or 50 fps for PAL machines).
On the other side, there are other emus that ran very well: the .EMU series and RetroArch for example. These emulators are much more polished than the average quick port and they run without a flaw. They're great on the 10-inch screen and I enjoy them very much. The CPU intensive emulators (Mupen64Plus AE and FPSE) gained some speed but less that I anticipated.
So is this because of the monster Nexus 10's 2560x1600 resolution? Or is it because of limited memory bandwith? Maybe some emulators are not tweaked for the N10 yet. I wish some emulators had the option to set a lower resolution for rendering and then upscale the output. I think that many Android apps just try to push the frames to the native resolution without checking first if there is a faster way.
The N7 has a lower clocked 4 core CPU but has only 1/4 the resolution. I think that it's a more balanced device that the N10 which may have a faster dual core CPU but too much pixels to push. It's much like the iPad3 who was twice as fast as the iPad2 but had a 4x increase in resolution.
I am now considering going for a custom ROM on the N10 but I wonder if I will see an increase in emulation speed. Maybe those of you who did the jump can tell me. I'm thinking about AOKP maybe.
Any suggestion on that would be appreciated, thanks!
The emulators just need to be tweaked a bit to better perform on the completely different processor architecture. Really our processor is far more powerful than the Nexus 7 so the emulators should run faster. I too am a fan of the old games, and I play Super Nintendo and Game Boy Advance (and some Color) games quite often. I find performance to be perfect with no issues at all, but then again those arent exactly "demanding" emulators.
We do not have any sort of memory bandwidth limitation on the Nexus 10. The tablet has been designed to give the full needed 12.8 GB/s of memory bandwidth that is required for 2560x1600 resolution.
EniGmA1987 said:
The emulators just need to be tweaked a bit to better perform on the completely different processor architecture. Really our processor is far more powerful than the Nexus 7 so the emulators should run faster. I too am a fan of the old games, and I play Super Nintendo and Game Boy Advance (and some Color) games quite often. I find performance to be perfect with no issues at all, but then again those arent exactly "demanding" emulators.
We do not have any sort of memory bandwidth limitation on the Nexus 10. The tablet has been designed to give the full needed 12.8 GB/s of memory bandwidth that is required for 2560x1600 resolution.
Click to expand...
Click to collapse
Hmm, if no memory bandwidth limitation exists on the N10, wouldn't I be able to run GTA 3 at 100% screen resolution and not have significantly lower FPS, as compared to 50% resolution?
Even Beat Hazard Ultra seems to be a bit laggy on the N10. When I inquired about it to the developer, he said:
Having to render to that size of screen [2560x1600] will slow the game down. It’s called being ‘fill rate bound’. Even for a good processor it's a lot of work as the game uses quite a lot of overdraw.
The solution is to draw everything to a smaller screen (say half at 1280x800) and then stretch the final image to fill the screen.
Click to expand...
Click to collapse
A sad true my nexus 10 get dam hot and i have to play games at 1.4 or 1.2 that sux
Sent from my XT925 using xda app-developers app
espionage724 said:
Hmm, if no memory bandwidth limitation exists on the N10, wouldn't I be able to run GTA 3 at 100% screen resolution and not have significantly lower FPS, as compared to 50% resolution?
Even Beat Hazard Ultra seems to be a bit laggy on the N10. When I inquired about it to the developer, he said:
Click to expand...
Click to collapse
But fillrate isnt memory bandwidth. We need both more MHz and more raster operations to get higher fill rate of pixels per second. We can overclock the GPU to get the MHz, and that will help, but we have to find a way to solve the higher heat output too from that. More ROP's are impossible as it is a hardware design for how many we have. If we ever get to overclock up to around 750 MHz then we should see a 30-40% improvement in fill rate. At that point we may have memory bandwidth problems, but we wont know for sure until we get there. But the 12.8GB/s of bandwidth that we currently have is enough to support 2560x1600 resolution at our current GPU power. Our Nexus 10 also has the highest fillrate of any Android phone or tablet to date, about 1.4 Mtexel/s. And if we have memory bandwidth limitations, then we would see no improvement at all from the current overclock we do have up to 612-620MHz because the speed wouldnt be where the bottleneck is. Yet we can clearly see in benchmarks and real gaming that we get FPS increases with higher MHz, thus our current problem is the fillrate and not the memory bandwidth.
Also, the solution is not to render the game at half the resolution as that is a band-aid on the real problem. If the developer of a game would code the game properly we wouldnt have this problem, or if they dont feel like doing that then they should at least stop trying to put more into the game than their un-optimized, lazy project is capable of running nicely.
espionage724 said:
Hmm, if no memory bandwidth limitation exists on the N10, wouldn't I be able to run GTA 3 at 100% screen resolution and not have significantly lower FPS, as compared to 50% resolution?
Even Beat Hazard Ultra seems to be a bit laggy on the N10. When I inquired about it to the developer, he said:
Click to expand...
Click to collapse
With that logic you could buy any video card for a PC and it would run any game at the resolution the video card supports. That isn't the case because rendering involves more than just memory fill rate. There are textures, polygons, multiple rendering passes, filtering, it goes on and on. As EniGmA1987 mentioned nothing has been optimized to take advantage of this hardware yet, developers were literally crossing their fingers hoping their games would run 'as is'. thankfully the A15 cpu cores in the exynos will be used in the tegra 4 as well so we can look forward to the CPU optimizations soon which will definitely help.
Emulators are more cpu intensive than anything else, give it a little time and you won't have any problems with your old school games. Run the new 3DMark bench to see what this tablet can do, it runs native resolution and its not even fully optimized for this architecture yet.
2560*1600*4*60/1024/1024 = 937,3 MB/s for a 60 fps game at 32-bit depth. Most emulators don't use 3D functions so fillrate, rendering, overdraw won't be a factor. Most emulators are single-threaded (correct me if I'm wrong) and the A15 should shine in this particular situation and even more so in multi-threaded scenarios. With its out-of-order pipeline and greatly enhanced efficiency it should be perfectly suited for the job.
We have the fillrate, we have enough CPU power and I'm still wondering why simple app like emulators aren't much faster than that. Is it Android? Is it the Dalvik VM? Or is it because some emulators need to be written in native code instead of using Java VM? I'm not a developer and I have only minimal knowledge in this department. I can only speculate but I'm curious enough about it that I started googling around to find why.
Lodovik said:
2560*1600*4*60/1024/1024 = 937,3 MB/s for a 60 fps game at 32-bit depth
Click to expand...
Click to collapse
Just curious but what is that calculation supposed to be? total bandwidth needed? Cause I don't see your bit depth in there, unless the 4 is supposed to be that? If that is true than you are calculating on 4-bit color depth?
And then the result would just be bandwidth required for pixel data to memory wouldnt it? It wouldnt include texture data in and out of memory and other special functions like post processing.
2560*1600 = number of pixels on the screen
4 = bytes / pixels for 32-bits depth
60 = frames / second
/1024/1024 = divide twice to get the result in MB
Actually, I made a typo the result is 937,5 MB/s or 0.92 GB/s. This is just a rough estimate to get an idea of what is needed at this resolution just to push the all pixels on the screen in flat 2D at 60 fps, assuming that emulators don't use accelerated functions.
My point was that with 12.8 GB/s of memory bandwith, we should have more than enough even if this estimate isn't very accurate.
Thanks for the explanation
If there really were a memory bandwidth limitation the newer Trinity kernels and newest KTManta should help. In addition to the higher GPU speed they both allow (KTManta up to 720MHz) both ROM's have increased memory speeds which increase memory bandwidth to 13.8GB/s, up from 12.8 on stock.
Thanks for the info. There's so many configuration options available for the Nexus 10. I really enjoy having all those possibilities.
EniGmA1987 said:
If there really were a memory bandwidth limitation the newer Trinity kernels and newest KTManta should help. In addition to the higher GPU speed they both allow (KTManta up to 720MHz) both ROM's have increased memory speeds which increase memory bandwidth to 13.8GB/s, up from 12.8 on stock.
Click to expand...
Click to collapse
=Lodovik;40030*1600*4*60/1024/1024 = 937,3 MB/s for a 60 fps game at 32-bit depth. Most emulators don't use 3D functions so fillrate, rendering, overdraw won't be a factor. Most emulators are single-threaded (correct me if I'm wrong) and the A15 should shine in this particular situation and even more so in multi-threaded scenarios. With its out-of-order pipeline and greatly enhanced efficiency it should be perfectly suited for the job.
We have the fillrate, we have enough CPU power and I'm still wondering why simple app like emulators aren't much faster than that. Is it Android? Is it the Dalvik VM? Or is it because some emulators need to be written in native code instead of using Java VM? I'm not a developer and I have only minimal knowledge in this department. I can only speculate but I'm curious enough about it that I started googling around to find why.
Click to expand...
Click to collapse
You are taking what I said out of context. I was responding to someone else, thus the "quote" above my post.
Since you posted I loaded up some Super Nintendo, N64, and PlayStation games on my n10 without any issues. It may just be your setup. There are a lot of tweaks out there that could easily increase performance. One great and very simple one is enabling 2D GPU rendering which is in developer options. Just do some searching. GPU Overclocking won't help much, as you said above your games are only 2D. I am sure you can get them running just fine.
First of all, I'd like to thank everyone involved in this site. The experience has been very enriching so far.
I have a Cherry Mobile Razor which I bought here in the Philippines. Specs are as follows:
- Mediatek MT6589 Quad-core Cortex A7 Processor
- PowerVR SGX 544MP
- 1GB LPDDR2
- 540x960 qHD IPS LCD Screen
- 4GB Internal Storage
-16 GB SDcard/ External Storage
- Android Jellybean 4.2.1
- 1750mAh Battery
Now, it is a sweet device for it's price point. Catch is, the screen refresh rate is locked to a snail-pace 22Hz. That's right, 22Hz. The big difference between the amount of frames the device can process and the rate it can spit images out on the screen is so big it shows as a laggy platform for a myriad of 2D applications. You can even feel the "display latency" when typing on the on-screen keyboard. The animations are fluid, but laggy response can be felt.
The question:
I wish to edit the refresh rate setting on the device and set it to about 60Hz. I am rooted and read somewhere that settings are located in the kernel. I am thinking of editing the boot.img in my device, either the manual way via ADB or through a kernel kitchen. But before I do any sort of unpacking, editing, then repacking - am I looking at this correctly?
Are there other things I need to consider and know like LCD screen specs, etc.,... ????
Hello,
i just got my Z5C yesterday and so far i´m more than happy. But there is one issue:
I use the AOSP Full disk encryption on the phone but it seems like the native Qualcomm hardware cryptographic engine doesn´t work well - i benchmarked the internal storage before and after, here are the results:
Before: read ~ 200 MB/s write: ~ 120 MB/s
After: read ~ 120 MB/s write: ~ 120 MB/s
(Benchmarked by A1 SD Bench)
I´m using a FDE on my windows 10 Notebook with an e-drive resulting in like 5% performance loss. The decrease in read-speed on the Z5C is noticable. What do you think, is there something wrong or is this a normal behaviour?
Cheers
I don't know if this helps, but it seems that the Nexus 5X and 6P won't use hardware encryption according to this:
DB> Encryption is software accelerated. Specifically the ARMv8 as part of 64-bit support has a number of instructions that provides better performance than the AES hardware options on the SoC.
Click to expand...
Click to collapse
Source: The Nexus 5X And 6P Have Software-Accelerated Encryption, But The Nexus Team Says It's Better Than Hardware Encryption
So maybe, Sony is following the same path...
Sadly they don't, it seems like the write-speed decrease is just on the same level as the N6 back then. Let's hope that they include the bibs in the kernel by the marshmellow update.
Why would they use Qualcomms own crappy crypto engine, if the standard Cortex-A57 is really fast with AES thanks to NEON and possibly additional, newer optimizations/instructions? AFAIK the latter are supported in newer Linux kernels per default, so there's no need to use additional libraries to enable support or the Qualcomm crypto stuff.
But it would be nice, if someone with actual insight and detailed knowledge about this could say a few words for clarification.
Neither i got insight nor big knowledge, but i benchmarked the system and like 60% loss in reading speed doesn't feels like a optimized kernel either :/
Qualcomm is a no go. On android plaform, only Exynos 7420(not sure about 5xxx series) real get used h/w encry and decry engine and no speed down.
TheEndHK said:
Qualcomm is a no go. On android plaform, only Exynos 7420(not sure about 5xxx series) real get used h/w encry and decry engine and no speed down.
Click to expand...
Click to collapse
That's not only off topic, it's also wrong. The Exynos SoCs don't have a substantially different crypto engine or "better"/"faster" crypto/hashing acceleration via the ARM cores. If anything, the Samsung guys are smart enough to optimize their software so it makes use of the good hardware. This seems to be missing here, but for no obvious reason.
xaps said:
That's not only off topic, it's also wrong. The Exynos SoCs don't have a substantially different crypto engine or "better"/"faster" crypto/hashing acceleration via the ARM cores. If anything, the Samsung guys are smart enough to optimize their software so it makes use of the good hardware. This seems to be missing here, but for no obvious reason.
Click to expand...
Click to collapse
I agreed all ARMv8-A cpu support hardware AES and SHA. Both Exynos 7420 and S810 should also got that ability but it turns out doesn't work on Z5c now which is a fact. I'm sure S6 got it working but not sure about on other S810 phones or might be Qualcomm missing driver support.
TheEndHK said:
Both Exynos 7420 and S810 should also got that ability but it turns out doesn't work on Z5c now which is a fact.
Click to expand...
Click to collapse
Please show us the kernel source code proving that fact.
What you call "fact" is the result of a simple before and after comparison done with a flash memory benchmark app run by one person on one device. To draw the conclusion that the only reason for the shown result is that the Z5(c) can't do HW acceleration of AES or SHA is a bit far-fetched, don't you think?
xaps said:
Please show us the kernel source code proving that fact.
What you call "fact" is the result of a simple before and after comparison done with a flash memory benchmark app run by one person on one device. To draw the conclusion that the only reason for the shown result is that the Z5(c) can't do HW acceleration of AES or SHA is a bit far-fetched, don't you think?
Click to expand...
Click to collapse
I've got a S6 and no slower after encry/decry and we had a thread discussing about it on S6 board.
I don't own a Z5c now bcoz my living place HK not yet started to sell it(I come to here bcoz considering to sell my S6 and Z1c and swap to Z5c later) so I can't test it but according to OP, there is a substantial slow down.
All ARMv8-A should support hardware AES/SHA, it is not just a cached benchmark result on S6. That's real.
A few things to ponder...
This is confusing. I was always under the impression that decryption (reads) are usually a tad bit faster then encryption writes. This at least seems true for TrueCrypt benchmarks. But that may be comparing apples and oranges.
A few thoughts...
In some other thread it was mentioned that the Z5C optimizes RAM usage by doing internal on the fly compression / decompression to make very efficient usage of the RAM. As cryptotext usually is incompressible could this be a source of the slowdown on flash R/W. Could this be a source of the problem (either by actual slowdown or confusing the measurement of the benchmarking tool?)
These days the SSD flash controllers also do transparent compression of data before writing to reduce wear on the flash. If you send a huge ASCII plaintext file into the write queue the write speed will be ridiculously high, if you send incompressible data like video the write speed rate goes way down. This happens on hardware level, not taking any cryptop/decrypto operations on the OS level into account.
Is there maybe a similar function in todays smartphone flash controllers?
Can I ask the OP, in what situations do you notice the slower read rate on the crypted device? Not so long ago when spinning rust disks were still the norm in desktop and laptop computers read rates of 120 MB were totally out of reach. What kind of usage do you have on your smartphone that you actually notice the lag? Is it when loading huge games or PDF files or something similar?