http://www.modaco.com/index.php?s=&showtopic=291735&view=findpost&p=1064 803
Post number 15 has a download link !
uses the same processor, so it ships with the same three GLES driver files! Headers, Libs, Sources - everything is there...
http://www.modaco.com/index.php?s=&showtopic=291735&view=findpost&p=1064 803
Post number 15 has a download link !
uses the same processor, so it ships with the same three GLES driver files! Headers, Libs, Sources - everything is there...
Last edited by antibyte; 07-05-2010 at 10:53 PM.
AFAIK g3d/s3c_fimg3d.c is only used to make the kernel load the proprietary implementation of opengl
the opengl implementation's source is: FIMG_3D_source.zip
Thank you for your work!
I found this 이솝 지식in (질문/답변) - Hi,Dear sir!
The 3d drivers suck no matter what the platform..
IMO the devs should try to improve upon the existing drivers, it's very difficult to start from scratch with stuff like this.3d is possible but comes with limits and can easily fail. there are a lot of problems there to clear up. it's also not immensely efficient and there is no x suport for 2d unless you write your own
Here are some examples (taken from modaco.com, probably does not apply to android) (omniaII@modaco):
- eglGetDisplay(0) fails. It should work with a zero argument, by standard, but it fails.
- Calling glGetString() before eglInitialize(), crashes.
- eglGetConfigs with config_size = 4096 crashes.
- glBindBuffer generates GL_OUT_OF_MEMORY if buffer number is above 100 (it is an actual limit hard-wired into libGLESv2, I had to re-implement the whole buffer management by myself). And, Xtrakt needs 102 buffers...
- glGetIntegerv(GL_MAX_TEXTURE_UNITS) returns 0 instead of 2. This one totally breaks NFS.
- glGetIntegerv(GL_MAX_TEXTURE_SIZE) returns 2048. In reality, every texture larger than 512x512 is going to be ignored at all, with some allocaton errors in debugger output. It may be used with S3TC, but it's DXT1 only, not even DXT5. And, somehow, with a GL_RGBA_S3TC_OES format, an alpha bit is ignored at all.
- And don't forget to create mipmaps, or GL_*_MIPMAP_* won't draw anything at all (it should just use the only level available)!
- glAlphaFuncEXP is not iplemented in libGLESv2 (though the hardware DOES have this available), had to do a hack for this to work.
- glViewport works wrong after all. If the parameters, e.g. X and Width have a larger sum than the width of the window surface, then the resulting width is clamped, which results in scaled down rendering.
- eglCreateWindowSurface is a fail: it doesn't track window size change at all, so if you create a surface and change window size, your output will be of an inadequate size (e.g., in Opera 9.7 going from Widowed mode to Fullscreen, or in anything else when going from Landscape to Portrait mode).
- eglSwapBuffers is slow as hell (probably because of plain BitBlt it uses), it takes about 10 ms, which limits fps to about 100 and reduces the speed of everything else (e.g., you'll get 16 fps where you could have 20, only because of this functon).
- All textures have an offset by half-texel. This is probably done for mapping to the nearest texel (like, round(u + 0.5)), but it breaks everything that is drawn, for example, with glOrtho (like Opera 9.7). Well, not exactly breaks, but akes everything look "smoothed out".
Go tom3Q!
I'm sure Spica users all over the world will appreciate your help. I have to buy a new phone soon, and whether it'll be Spica will depend on whether you can write working 3d drivers for it.
Thanks for all your help.![]()
I think Samsung not developed a 3D driver, because if there was one, then this phone would be "too good", I mean 800MHz and proper 3D for this price? Nobody would buy any other Samsung Android phone.
Btw keep up the good work, and maybe you could ask for a little help in OpenGL at the noveau or the radeon opensource driver team. Your driver should be a lot simpler than those, because you shouldn't have to write for many GPUs, just one.
You might be right, because Spica is incredibly cheap considering that it has the same or better hardware than let's say iPhone 3G, which costs way more. Also there are another examples of wasted hardware like unused proximity/light sensor or disabled multitouch (precisely, two finger touch, which is supported by the hardware).
I guess it should be even easier, because OpenGL ES is a bit less complex than standard OpenGL and also the hardware is way simpler than the GPUs you quoted.
So any updates on the driver?
I have decided to make the driver native for Froyo instead of trying to make it compatible with 2.1, so it will take me a bit more time, as I have to rewrite the 2D driver almost from scratch (which I'm finishing right now).
Also, I'm thinking about delaying the driver a bit more and helping with other things currently not working in 2.2, as the 3D driver isn't as needed to have a completely working phone, because UI can be rendered using software OpenGL implementation with 2D hardware as a back-end, which is even a bit faster than the hardware OpenGL in 2.1...
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks