Database Users

Ati Imageon 3200 Development

Hi there!
The XDA II has the new super-duper Ati Imageon 3200 graphics accelerator integrated.
Anyone informations about the API or any way to access it's special
functions?
Especially I am interested in the gourad shading feature, which
leads me to the conclusion, that you could use it to accelerate
3D graphics with this chip...
I found literally no(!) usable information via google or via the
site search feature at ati.com.
If this is possible the open source klimt(softgl) implementation of
opengl ES could be enhanced for better support of 3D-Shooters or, and that`s even better, it could be used to accelerate the augmeted reality application for kanji learning of the technical university of vienna(http://www.ims.tuwien.ac.at/research/handheld_ar/kanji.php).
greetz
farbgeist

[THE] New version of Panels SDK available with open GL ES support

latest news from xperiancers
http://xperiancers.com/2009/02/24/new-version-of-panels-sdk-available-with-open-gl-support/
...The new beta includes Open GL ES support and allows you to access the internal hardware graphics acceleration on the X1...
These words sound some kinda optimistic, isn't it? ))

Doh...!!! too late... http://forum.xda-developers.com/showthread.php?t=486288

Render-To-Texture with HTC Diamond 2

Hi everyone,
I have a small technical problem to solve and hopefully someone knows an answer for it. Someone gave me a HTC Diamond 2 (very nice toy I think). I don’t know which hardware is exactly inside the phone but I assume it’s an ATI ImageOn 2300 which fully supports OpenGL ES 1.0 + Extension Pack (that’s what GL_EXTENSION is saying). And all of these extensions are doing fine. As everyone knows HTC is not providing a D3D driver for their phones and all other drivers I have seen are just a wrapper around OpenGL ES. So using D3D is currently not an option.
I have to write an application which requires some render-to-texture functionality in realtime and here my problems are starting to grow.
[1] glCopyTexImage2D:
I recognized that glCopyTexImage2D() is very slow. My framerate is dropping dramatically from >100 frames down to ~20 frames. Somehow this is done in software by the driver and not hardware- accelerated. glCopyTexSubImage2D() is even more slow (down to ~10 frames per second), but both functions are working. I tried to move it into a different thread, but the driver is not supporting shared contexts. Also it’s not supporting two bound contexts at the same time with two different windows and threads. So this can’t be improved or I’m doing something wrong.
[2]PBuffers:
PBuffer are working fine. But PBuffers which can be bound to a texture are not supported by OpenGL ES 1.0. And that’s what happens also on this ATI card.
[3]GL_OES_framebuffer_object:
This was my preferred choice. But framebuffers are not officially supported by the installed OpenGL driver. But the libgles_cm.dll on the HTC is exporting these functions so I tried them and recognized that they are not working correctly. Somehow the vertex pipeline is allowing only triangles in the center of the viewport. All others will be discarded. When I turn it off it renders correct. Using glDrawTexiOES() will be ignored while using framebuffers. I assume that either the current implementation of the framebuffers is just waste of some development guys or the functionality is locked in some way.
[4]D3D:
Normally D3DM is supporting to switch between different rendertargets. But we are all know the D3D problem. I tested some other D3D drivers but they are not usable. Also I can’t imagine how render-to-texture will be implemented in these drivers while it’s not working in OpenGL.
I’m wondering what TouchFlow3D is using internally, whether they are using render-to-texture or not. The only thing I know is that they are using OpenGL ES and some extensions. But Manila.exe is querying the functions of libgles_cm.dll during runtime. So I have to write a few proxy dlls first and need to hook into the system to track what they are doing. And I don’t want to spend time on this.
Does someone knows an alternative to do some render-to-texture on the ATI or knows some secrets of the libgles_cm.dll which I don’t know? There are a lot of private functions inside but can’t find some documentation about it. Also ATI and Qualcomm are not very helpful to me.
Thanks.

Maybe, glReadPixels and then glTexSubImage2D (what probably glCopyTexImage2D is doing)?
(I know that this goes two times over the graphics bus, but you never know...)
What kind of scene (number of triangles, lights, textures) are you rendering with > 100fps?

glReadPixels() + glTexImage2D() is even more slow than glCopyTexImage2D...
Also this can't be parallized. I thought using AHI2DATI.dll instead to do the same thing, but I don't know how to get a surface handle from a OpenGL texture id.
>>>What kind of scene?
A very simple scene yet. Only a few depth sorted + material sorted objects (via VBO) with some textures (backed lighting) on it. Textures are compressed. Currently no lighting, no skinning or other things. While the render thread is waiting for glFinish() to return, a second thread prepares the next frame. Also the rendering thread is not redrawing the entire viewport each time.

The OpenGL texture id is the handle. There's nothing more you can do with it. PBuffers or framebuffer objects are the only way I know for doing performant render to texture in OpenGL.

No...I mean the surface handle of the AHI2DATI library. Here you have access to the raw data of the surface. Somehow the libgles_cm.dll uses these surfaces for it own buffers and/or textures or not?!
But this is not really useful unless someone tells us whats going on inside libgles_cm.dll.
See:http://greengalaxy.wordpress.com/2009/04/18/ati-direct-access-to-hardware/

Hi jeansmsixer, I don't think there is no efficient way to do it. Have you tried eglCopyBuffers?
Aren't all textures stored in system memory? - they surely have to be because the device reports no available video mem.
Even if you get a pointer to the color buffer, it's impossible to wrap the memory in a HBITMAP to select onto a HDC and use GDI fonts for instance. (which is what I need to do).
If you do write the proxy dll like you were suggesting, can you please let me know what TF3D does for fonts? Are they textures or have they somehow mixed 3D with GDI?

Hi jeansmsixer, something else you could try is what is described here:
http://brewforums.qualcomm.com/showthread.php?t=10668
Looking on glbenchmark.com it looks like HTC devices support the extension. You should be able to get a pointer directly to the color buffer (which I presume is in normal system memory) so you could copy off pixels fairly efficiently with your own memcpy(). However, you will need to eglWaitGL() etc to ensure 3d stuff is complete before attempting to access it.
I love the irony of the only helpful information for WM opengl being found on a brew site for symbian. If WM7 is as terrible as the current mess, then I'm moving to iPhone.

OpenGL ES insanity - implementations

I'm a PC developer looking to get into development for OpenGL ES devices.
In the PC world, I used Direct3D. For Direct3D, there is a single SDK that you download from Microsoft and you develop your application against that SDK. Users can then take my Direct3D program and run it on any Direct3D-compliant hardware, and get hardware accelerated graphics - it doesn't matter whether their hardware is from ATI, Nvidia, Intel, etc. It "just works" on all hardware.
From what I have seen, this is not the case for OpenGL ES (I'm looking primarily at Windows Mobile, but I don't suppose it would be different for other platforms). That is, there doesn't seem to be a single, unified, OpenGL ES implementation anywhere. For example, PowerVR provides an implementation which only works on their hardware. Qualcomm provides another implementation which only works on their hardware. And so on. Considering the wide variety of hardware available which is OpenGL ES compliant, this seems like pure insanity.
Doesn't this mean that I will have to compile many, many different versions of my application? Or, at the very least, perform a runtime check to load the correct implementation depending on the hardware my program is running on?
On the PC, a Direct3D application can be hardware-agnostic. That is, it doesn't care what it's running on - Direct3D will forward your API calls to the driver and the driver deals with it (sends it to hardware for processing, or whatever). Why doesn't OpenGL ES work this way? Or am I misunderstanding the way OpenGL ES implementations work?

Need original Toshiba Core Player!!!

I am using custom rom 6.5.5 and core player is missing, I tried the new version but it still don`t support hardware acceleration, can any one kind enough to extract it from the Toshiba rom and make it in a cab? Thank you

elder T said:
I am using custom rom 6.5.5 and core player is missing, I tried the new version but it still don`t support hardware acceleration, can any one kind enough to extract it from the Toshiba rom and make it in a cab? Thank you.
Click to expand...
Click to collapse
@elder T.... can you clarify what hardware acceleration you are looking for ? I have used both versions and can't immediately see any different settings between them; I am aware however that there were a number of bug fixes, etc. in the later (paid) version.

The Toshiba Core Player has a feature that uses the SnapDragon`s hardware to do some job like what DXVA does in Microsoft Windows. Its alot smoother when rendering high bit rates encoded videos.

elder T said:
The Toshiba Core Player has a feature that uses the SnapDragon`s hardware to do some job like what DXVA does in Microsoft Windows. Its alot smoother when rendering high bit rates encoded videos.
Click to expand...
Click to collapse
Where does this show up in the menus please ? I hadn't spotted any non-standard items anywhere, but may just be being a bit dim

http://boardreader.com/thread/TG01_version_of_CorePlayer_anyone_tried_a6svXd59n.html
More discussion about It.

elder T said:
http://boardreader.com/thread/TG01_version_of_CorePlayer_anyone_tried_a6svXd59n.html
.
Click to expand...
Click to collapse
Many thanks - have just had a quick browse, but don't see a definitive clarification - mostly seems to be supposition; there is however one comment by BetaBoy (Core Player developer) which states "On speed differences.... There may be some speed improvements as the TG01 version of CorePlayer has some of our v2.0 improvements." I understood that some of this had also been incorporated into v1.3.6 (which superseeded 1.1.3) also - but in any event, seems to be very dependent on the video format/codec/size concerned.

Erm... I tested it with a `H.264 Video` `AAC Audio` MP4 file, CPU setting is at low and it drop less frames than any other version of coreplayer I used so far.
"It's presumably able to make use of the Snapdragon GPU in the same sort of way as WMP and HTCAlbum can. The normal version runs only on the CPU. I guess it may not be the GPU it's using, but in some way it is specifically tuned to the Snapdragon chipset and able to use parts of it for processing which are not accessible unless you license the ability to use them from Qualcomm."
Shasarak's comment might be true.
I got the Toshiba version now and very happy.

if your desperate for the .cab, re flash the original orange version and the coreplayer.cab is sitting in the windows directory, along with the other ones like maps etc