Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Distinguished Ambassadors
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Graphics, Gaming, and VR forum
Many Issue with Mali 400 on A10 (Linux)
Jump...
Cancel
Locked
Locked
Replies
16 replies
Subscribers
136 subscribers
Views
18293 views
Users
0 members are here
OpenGL ES
Mali-GPU
Mali-400
Options
Share
More actions
Cancel
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
Many Issue with Mali 400 on A10 (Linux)
Piyush Verma
over 11 years ago
Note: This was originally posted on 17th August 2012 at
http://forums.arm.com
Hi,
I am facing many problems with Mali 400. One of the big issue is lib is close source so can't change anything.
I am in advance stage of product development but stuck with many issues.
Point 1.
I was using Ericsson Texture Compression Mipmap Example and trying to work with normal RGBA texture.
Here is my load texture code.
/* Load just base level texture data. */
GL_CHECK(glGenTextures(1, &textureID));
GL_CHECK(glBindTexture(GL_TEXTURE_2D, textureID));
unsigned char *textureData = NULL;
Texture::loadData(texturePath.c_str(), &textureData);
GL_CHECK(glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 256, 256, 0, GL_RGBA, GL_UNSIGNED_BYTE, textureData));
Here it just render a black area.
Just by referring RotoZoom program and with hit and try I fogure out it work if I add.
/* Set texture mode. */
GL_CHECK(glGenerateMipmap(GL_TEXTURE_2D));
after glTexImage2D.
Is glGenerateMipmap must to use texture ?
besides there is not any sample program which load basic rgba texture.
Point 2.
Besides with 2 or 3 test system give sigmentation fault continuously. Even is workable program.
Same program which was working before not work now and can work again on system restart.
Point 3.
EGLSwapbuffer is consuming 50% CPU. & I can't find any way to render directly to frame-buffer. Mali document say it's platform specific.
I can't understand FB interface is fix in all linux how come it could be platform specific ?.
Every body no most of vendor not support for anything like this.
Point 4.
http://www.arm.com/products/multimedia/mali-graphics-hardware/mali-400-mp.php
here mention 30M tri/s and up to 1.1G pix/s at 275MHz.
Correct me if I am wrong 1.1G Pix is filling pixels of screen with color or texture.
1.1 * 1000 *1000 *1000 / 1920 / 1080 / 60 = 8.84 Layers
if means if I render full hd @ 60 FPS I should be able to render full screen 8.84 times.
I am using a simple triangle program which is filling the screen and rendering 8 times in one round. then performance is dropping to 14fps.
Means 4 times slower than speq. where other points gpu is running on 320 Mhz not on 275 Mhz.
Point 5.
A very simple triangle program is not working in GLES1 so I am bound to use only GLES2.
As many places internet mention GLES1 is faster than GLES2.
There is not any sample program for GLES1. and document talk about gles1 simulator but there is not any gles1 simulator on mali website.
Point 6.
What is the process to get Mali 400 DDK Source.
Is it possible to get even after spending some money ?
Any clarification in above points can help us.
Thanks in Advance.
Regards
Piyush Verma
Parents
Pete
over 11 years ago
Note: This was originally posted on 17th August 2012 at
http://forums.arm.com
So as conclusion even if I don't need mipmap I need to call glGenerateMipmap() right ?
Not quite - if you don't want to use mipmaps, you can use glTexParameteri() to set GL_TEXTURE_MIN_FILTER to either GL_NEAREST (no filtering at all, will look low visxual quality but be fast) or GL_LINEAR (no mipmap levels, but 4 texels will be sampled and averaged, so higher visual quality).
However, typically using mipmaps is advisable - they mean the GPU can make better use of the limited amount of texture cache available. When a large texture is drawn on a small triangle, only sparse points on the texture will be sampled even though the cache brings in blocks of adjacent texels - so the cache will be filled with data which won't be used again, defeating the point of the cache. When using mipmaps, the GPU selects the most appropriate mipmap level to use, and the texels sampled will be much more likely to be adjacent - leading to cache hits and improved performance, memory bandwidth usage and power consumption.
HTH, Pete
Cancel
Up
0
Down
Cancel
Reply
Pete
over 11 years ago
Note: This was originally posted on 17th August 2012 at
http://forums.arm.com
So as conclusion even if I don't need mipmap I need to call glGenerateMipmap() right ?
Not quite - if you don't want to use mipmaps, you can use glTexParameteri() to set GL_TEXTURE_MIN_FILTER to either GL_NEAREST (no filtering at all, will look low visxual quality but be fast) or GL_LINEAR (no mipmap levels, but 4 texels will be sampled and averaged, so higher visual quality).
However, typically using mipmaps is advisable - they mean the GPU can make better use of the limited amount of texture cache available. When a large texture is drawn on a small triangle, only sparse points on the texture will be sampled even though the cache brings in blocks of adjacent texels - so the cache will be filled with data which won't be used again, defeating the point of the cache. When using mipmaps, the GPU selects the most appropriate mipmap level to use, and the texels sampled will be much more likely to be adjacent - leading to cache hits and improved performance, memory bandwidth usage and power consumption.
HTH, Pete
Cancel
Up
0
Down
Cancel
Children
No data