Nah, I'm good thanks. There's not really that much code so far (about 5.5k lines) but it is pretty fiddly and all the tasks are quite serial. I also program in a team by day so it's nice to not have to work with others!hdante wrote:Simon, do you need/want to offload part of the code development ?
lol wutAnd yes, raspberry pies coming with software rendering fbdevs are retarded (think about the above analogy).
I remember using Sun running X 25 years ago, and they were certainly fast enough, and their CPU's were slower than the Raspi's. An A8 will be at most twice as fast for most tasks, so not that much improvement.stagefright1989 wrote:if only we had a better cpu like cortex a8 armv7 then this accelerated fbdev driver could have resolved this i think. also are these the similar to directfb project . they also have binaries . please clarify this later part
In the areas where NEON would improve things, the Videocore GPU would improve it even further - it has a 16 way vector core running at 250Mhz, plus dedicated HW for lots of stuff. As Simon says, small stuff should be done by the CPU, big stuff handed off to the GPU (once the speed increase offsets the setup cost)lb wrote:Cortex-A8 has NEON SIMD, though, which greatly speeds up most important operations (copy, composite). It's possible to achieve 4-5x speedups of typical alpha blending operations (compared to scalar code), as long as memory bandwidth allows it.
Exactly. However since a lot of X work is actually a large series of small operations with frequent CPU synchronisation, a large chunk of pixel painting is best done with the CPU. Places were the GPU is best used appear to be large composite operations where you draw a big alpha'd selection box over the icons on your desktop. Like 200x200+.jamesh wrote:In the areas where NEON would improve things, the Videocore GPU would improve it even further - it has a 16 way vector core running at 250Mhz, plus dedicated HW for lots of stuff. As Simon says, small stuff should be done by the CPU, big stuff handed off to the GPU (once the speed increase offsets the setup cost)
No matter what happens there will be people on both sides. What should hurt is those that have been waiting and appreciate the work but don't get a chance to have at it. Anything right now that can speed up X should be appreciated.teh_orph wrote:However what gives me The Fear is that if I release this driver "with most work being done by the CPU" plenty of people will turn their noses up at it saying "I'll wait for a proper driver that uses the GPU/GLES/VG". I'll then cry!
Yes. But I think you are misunderstanding what X acceleration gives you. What it means is that desktop type operations - window drawing/compositing, moving etc will become faster, and reduce load on the CPU. If you want fast 2D and 3D you STILL NEED to use the acceleration libraries for those - libVG, libOGES etc. Just having X acceleration doesn't mean your 2D/3D apps get miraculously faster.stagefright1989 wrote:Dont apps have to b spacially written in openvglibs for 2D acceleration when it comes to rpi
+1!jamesh wrote:Also, can you please stop using txt spk. It makes posts fantastically difficult to read.
Like the Android compositor example, this again is quite different to the X problem.stagefright1989 wrote:also what abt that the directfb project ? they have some binaries for rpi.
Lolstufty wrote:No, then you'll write a proper driver that uses the GPU, and then you'll get flamed for not being open enough.teh_orph wrote: I'll then cry!
Sorry for the lack of news, proper busy on this end. I still need more feedback from my testers btw...Kalimar wrote:Any progress on this? Please keep us posted!