Feed for discussion OpenGL ES in project Graphics.Posts for OpenGL ESpost117040: Re: QNX SDK Apps and Media 1.1 supports Intel HD4400 GPU?Gao Zhining(deleted)http://community.qnx.com/sf/go/post1170402016-11-01T03:17:06Z2016-11-01T03:17:06ZYes, The QNX for Apps and Media 1.1 supports Intel HD4400 GPU.Gao Zhining(deleted)2016-11-01T03:17:06Zpost116981: QNX SDK Apps and Media 1.1 supports Intel HD4400 GPU?Gao Zhining(deleted)http://community.qnx.com/sf/go/post1169812016-10-18T02:49:19Z2016-10-18T02:49:19ZThe QNX SDK Apps and Media 1.1 supports Intel HD4400 GPU?
In work my IPC is an Advantech AIMB-784_DS(Chipset : Q87), CPU is Intel 4170T(HD4400).
Thank you for your answer.Gao Zhining(deleted)2016-10-18T02:49:19Zpost116384: I can't get access to sources repositoryEvgenii Startcev(deleted)http://community.qnx.com/sf/go/post1163842016-06-06T11:38:45Z2016-06-06T11:38:45ZI am read http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.composition_manager_dev_guide%2Ftutorials.html. I am interested to get sources of gles1-gears/gles2-gears, but when i followed the link to source tree, i got error message "You do not have permission to view this page.". What's wrong?Evgenii Startcev(deleted)2016-06-06T11:38:45Zpost110781: Re: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915Bettina Kurz-Kalweit(deleted)http://community.qnx.com/sf/go/post1107812014-06-20T11:17:23Z2014-06-20T11:17:23ZIt seems to be the drm server is not included either in qnx 6.6 sdk or in the generic x86 bsp. What is it's concrete name?
I only know about Linux driver "drm-intel"... But where can I get qnx drm server?
Best regards!
BettinaBettina Kurz-Kalweit(deleted)2014-06-20T11:17:23Zpost110763: Re: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915Leo Xuhttp://community.qnx.com/sf/go/post1107632014-06-19T14:28:01Z2014-06-19T14:28:01ZYou should run drm server (drm-intel) first before running screen.Leo Xu2014-06-19T14:28:01Zpost110745: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915Bettina Kurz-Kalweit(deleted)http://community.qnx.com/sf/go/post1107452014-06-18T12:50:44Z2014-06-18T12:50:44ZHello to All!
I'm trying to run gles2-gears example on a generic x86 desktop pc with intel i915 graphics card.
My base is the x86 BSP for qnx 660 - bios version. In build file I added env vars SCREEN-DIR, GRAPHICS_ROOT and LD_LIBRARY_PATH. Then I start screen command and the gles2-gears example.
Furthermore I added the original target specific files e.g. graphics.conf, libs, ... to the file system. In graphics.conf in winmgr section I only changed in framebuffer classes "usage" from "gles2" to "gles2blt" (see release notes http://www.qnx.com/developers/articles/rel_5849_7.html).
I also checked all dependencies for all shared libs, it seems to be not the problem!
Running screen still fails with a segmentation fault!
sloginfo says:
....
Jun 18 14:12:02 5 8 300 screen: starting up...
Jun 18 14:12:02 5 8 300 screen: connected to powman...
Jun 18 14:12:02 6 8 200 wfd_init_driver
Jun 18 14:12:02 7 8 200 init_driver_locked ok
Jun 18 14:12:02 7 8 200 deref_device_handle: bad device handle 0
Jun 18 14:12:02 2 8 200 open_drm_dev failed: No such file or directory
Jun 18 14:12:02 6 8 200 create_internal_device failed, err=2
Jun 18 14:12:02 6 8 200 wfd_deinit_driver starting
Jun 18 14:12:02 7 8 200 wfd_deinit_driver complete
Jun 18 14:12:02 2 8 300 screen: win_enumerate_displays: could not create display device 1
Jun 18 14:12:02 2 8 300 screen: invalid display id:
>>> begin display 2
Jun 18 14:12:02 2 8 300 screen: invalid display id:
>>> begin display 3
Jun 18 14:12:02 5 8 300 screen: loading EGL display 1...
Jun 18 14:12:02 5 8 300 screen: loading blit module gles2blt...
Jun 18 14:12:02 2 8 300 screen-gles2blt: eglInitialize: EGL is not initialized, or could not be initialized, for the specified display
Jun 18 14:12:02 2 8 300 screen: win_blit_module_init: could not create a blitting context
I hope anybody of you understand what I did wrong!?
Thanks & RegardsBettina Kurz-Kalweit(deleted)2014-06-18T12:50:44Zpost110271: qnx car 2.1 opengles 2Rohit Nandan(deleted)http://community.qnx.com/sf/go/post1102712014-05-12T11:57:10Z2014-05-12T11:57:10ZI was wondering that if opengles 1.x apps doesnot work correctly on qnx
platform then why they posted tutorial for es 1.1 apps.
There is no turorial for opengles 2.0 . Why ? "Is is not supported" ?
Then why can someone miss this. Opengles 1.x is nothing.
Even searching long for some tutorial I could not find any.
Please if anyobne ever ran somes es2 code on qnx then please mail me.
It frustating when what is expected is not there.
Whoose's grandfather is learning es 1.x so for whom tutrial was.Or qnx
never ran es 2.0.
Whatever its worst commercial skeptical attitude toward knowledge sharing.Rohit Nandan(deleted)2014-05-12T11:57:10Zpost109855: RE: Screen on Kontron nanoETXexpress-TTJoel Pilon(deleted)http://community.qnx.com/sf/go/post1098552014-04-08T17:35:55Z2014-04-08T17:35:55ZThe tunnel creek has IMG graphics not Intel, you should be using the SGX and tunnelcreek WFD drivers.
-Joel
________________________________________
From: Alexander Lipin [community-noreply@qnx.com]
Sent: Tuesday, April 08, 2014 8:59 AM
To: opengles-graphics
Subject: Screen on Kontron nanoETXexpress-TT
Hi, All!
Please, help me run screen on nanoETXexpress-TT board on 6.6.0!
This board based on Atom E6xx (Tunnel Creek).
http://www.qnx.com/developers/articles/rel_5849_13.html - QNX 6.6 support Tunnel Creek chipset.
In attachment my graphics.conf. When I try to start screen, I got message: "Memory fault (core dumped)".
/usr/lib/graphics/intel-drm is added to LD_LIBRARY_PATH and GRAPHICS_ROOT.
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post109847
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2014-04-08T17:35:55Zpost109847: Screen on Kontron nanoETXexpress-TTAlexander Lipin(deleted)http://community.qnx.com/sf/go/post1098472014-04-08T12:59:50Z2014-04-08T12:59:50ZHi, All!
Please, help me run screen on nanoETXexpress-TT board on 6.6.0!
This board based on Atom E6xx (Tunnel Creek).
http://www.qnx.com/developers/articles/rel_5849_13.html - QNX 6.6 support Tunnel Creek chipset.
In attachment my graphics.conf. When I try to start screen, I got message: "Memory fault (core dumped)".
/usr/lib/graphics/intel-drm is added to LD_LIBRARY_PATH and GRAPHICS_ROOT.Alexander Lipin(deleted)2014-04-08T12:59:50Zpost109838: OpenGL ES 2.0 performance issues on 6.6.0Alexander Lipin(deleted)http://community.qnx.com/sf/go/post1098382014-04-08T07:07:52Z2014-04-08T07:07:52ZHi, All!
I have Freescale i.MX 6 Sabre SD and try to run gles2-gears with different settings.
I updated BSP for my board from 6.5.0 to 6.6.0, adjust screen.
My statistic:
# gles2-gears -interval=0 -size=100x100
1245 frames in 5.002 seconds = 248.900 FPS
1244 frames in 5.002 seconds = 248.701 FPS
# gles2-gears -interval=0 -size=200x200
1444 frames in 5.001 seconds = 288.742 FPS
1450 frames in 5.000 seconds = 290.000 FPS
1462 frames in 5.000 seconds = 292.400 FPS
# gles2-gears -interval=0 -size=400x400
1620 frames in 5.002 seconds = 323.870 FPS
1605 frames in 5.002 seconds = 320.872 FPS
1624 frames in 5.000 seconds = 324.800 FPS
# gles2-gears -interval=0 -size=600x600
1170 frames in 5.001 seconds = 233.953 FPS
1167 frames in 5.003 seconds = 233.260 FPS
1168 frames in 5.002 seconds = 233.507 FPS
# gles2-gears -interval=0 -size=1024x768
878 frames in 5.007 seconds = 175.355 FPS
877 frames in 5.003 seconds = 175.295 FPS
877 frames in 5.003 seconds = 175.295 FPS
At the same time, I have the results of similar tests on Accelerator Kit based i.MX6Q Saber Lite:
# gles2-gears -interval=0 -size=100x100
3990 frames in 5.001 seconds = 797.841 FPS
4151 frames in 5.001 seconds = 830.035 FPS
4243 frames in 5.001 seconds = 848.431 FPS
# gles2-gears -interval=0 -size=200x200
6715 frames in 5.001 seconds = 1342.733 FPS
6783 frames in 5.001 seconds = 1356.330 FPS
6731 frames in 5.001 seconds = 1345.932 FPS
# gles2-gears -interval=0 -size=400x400
4484 frames in 5.001 seconds = 896.622 FPS
4490 frames in 5.001 seconds = 897.821 FPS
5611 frames in 5.001 seconds = 1121.977 FPS
# gles2-gears -interval=0 -size=600x600
2397 frames in 5.001 seconds = 479.305 FPS
2407 frames in 5.002 seconds = 481.208 FPS
2397 frames in 5.002 seconds = 479.209 FPS
# gles2-gears -interval=0 -size=1024x768
1275 frames in 5.004 seconds = 254.796 FPS
1271 frames in 5.001 seconds = 254.149 FPS
1275 frames in 5.002 seconds = 254.898 FPS
Processors on our boards are the same, why the performance is so different??
In attachment, graphics.conf that I used.Alexander Lipin(deleted)2014-04-08T07:07:52Zpost109668: RE: Multy display opengl es 660Joel Pilon(deleted)http://community.qnx.com/sf/go/post1096682014-03-28T15:01:01Z2014-03-28T15:01:01ZThe naming in the EGL specification is misleading, an EGL display does not actually correspond to physical display output, it corresponds to an EGL driver. Typically a platform will only have one EGL display and could have X number of physical displays (e.g. LCD, HDMI etc..). The same EGL display can be used regardless of which physical display a screen window is on.
So to do multi-display with a GLES based applications, you can just create a screen window, query the displays with screen, then set the display property on the window at which point you can create your EGL window surface using your screen window like you normally would.
The following link provides an example of doing multi-display with screen:
http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.screen%2Ftopic%2Fmanual%2Fcscreen_displays_complete_sample.html
The same hold true for GLES regardless of whether or not the screen window is backing an EGL window surface or the physical display of the window:
-Joel
________________________________________
From: Eugene Strizhov [community-noreply@qnx.com]
Sent: Friday, March 28, 2014 3:08 AM
To: opengles-graphics
Subject: Multy display opengl es 660
now, how to use eglGetDisply if you want to make a conclusion on two monitors? Or is it now all depends on where I will create a window? As previously method eglGetDisply was used for the GF, there is not a more detailed documentation on this link?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post109657
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2014-03-28T15:01:01Zpost109657: Multy display opengl es 660Eugene Strizhov(deleted)http://community.qnx.com/sf/go/post1096572014-03-28T07:08:45Z2014-03-28T07:08:45Znow, how to use eglGetDisply if you want to make a conclusion on two monitors? Or is it now all depends on where I will create a window? As previously method eglGetDisply was used for the GF, there is not a more detailed documentation on this link?Eugene Strizhov(deleted)2014-03-28T07:08:45Zpost106088: Intel GMA 3150/devg-i830/OpenGL ES supportJim Douglashttp://community.qnx.com/sf/go/post1060882013-10-21T10:24:44Z2013-10-21T10:24:44ZHi,
Can anyone confirm that the devg-i830 driver, when used with the GMA 3150 (device id = a001/2), has hardware accelerated support for OpenGL ES?
This chip is incorporated into the Pineview D510/D525 Atom processors.
JimJim Douglas2013-10-21T10:24:44Zpost104914: eglCreateWindowSurface returns EGL_BAD_MATCH - GLESv2denis demidovhttp://community.qnx.com/sf/go/post1049142013-09-07T12:10:35Z2013-09-07T12:10:35Ztarget: x86 neutrino 6.5.0
host: linux
Linking with GLESv2, EGL(1.2), gf libraries.
I'm trying to create surface with API: eglCreateWindowSurface and got errors EGL_BAD_MATCH. Attributes I'm using for eglConfig:
EGLint attribs[] = {
EGL_NATIVE_VISUAL_ID, 0,
EGL_RED_SIZE, 5,
EGL_GREEN_SIZE, 5,
EGL_BLUE_SIZE, 5,
EGL_DEPTH_SIZE, 16,
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_LEVEL, layer_index,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT,
EGL_NONE
};
Full source code in attachment.
On my setup egl-gears works perfectly, but I need to link my application with libGLESv2 version.
Let me know if you need build logs for this.
Where can I download egl-gears with GLESv2, to validate my setup? Even binaries would be great.denis demidov2013-09-07T12:10:35Zpost104103: pbuffer on OpenGL ES 2.0Philip Endayahttp://community.qnx.com/sf/go/post1041032013-08-12T13:01:54Z2013-08-12T13:01:54ZHello,
I have a couple of programs using pbuffer, their only difference is that one is using Open GL ES1 while the other is 2.0. However, I got a EGL_BAD_ACCESS when binding the RBO when using OpenGL ES2.0.
[test_thread:327] eglBindTexImage eglGetError = 0x3002
I tested this in Pandaboard and iMX6 running QNX CAR2. GPU is PowerVR SGX 540 and Vivante respectively. I know that pbuffer has been superseded by FBO but i is it really not possible to use pbuffer on OpenGL ES2.0? Or it depends on the platform?
BR,
PhilipPhilip Endaya2013-08-12T13:01:54Zpost103415: RE: RE: Open GL ES 1.4Derek Leachhttp://community.qnx.com/sf/go/post1034152013-07-22T13:50:57Z2013-07-22T13:50:57ZPlease contact your customer service representative, and they will direct you to the appropriate packages to apply.
I do not have the exact details of what is required for you to install.
Regards.
-----Original Message-----
From: sankari G [mailto:community-noreply@qnx.com]
Sent: July-22-13 9:49 AM
To: opengles-graphics
Subject: Re: RE: Open GL ES 1.4
We are running io-display and io-gpumgr.
But I don't know the significance of io-winmgr. I took the winmgr binary from below link.
But this didn't help.
http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.imx51_gpu_driver.20101109
Can I get io-winmgr for IMX51 EVk on QNX 6.5.0 SP1
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post103414
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comDerek Leach2013-07-22T13:50:57Zpost103414: Re: RE: Open GL ES 1.4sankari G(deleted)http://community.qnx.com/sf/go/post1034142013-07-22T13:49:24Z2013-07-22T13:49:24ZWe are running io-display and io-gpumgr.
But I don't know the significance of io-winmgr. I took the winmgr binary from below link.
But this didn't help.
http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.imx51_gpu_driver.20101109
Can I get io-winmgr for IMX51 EVk on QNX 6.5.0 SP1sankari G(deleted)2013-07-22T13:49:24Zpost103410: RE: Open GL ES 1.4Derek Leachhttp://community.qnx.com/sf/go/post1034102013-07-22T13:12:15Z2013-07-22T13:12:15ZAre you running the io-winmgr and the io-display servers?
-----Original Message-----
From: sankari G [mailto:community-noreply@qnx.com]
Sent: July-20-13 3:23 AM
To: opengles-graphics
Subject: Open GL ES 1.4
We are facing problem with OpenGL ES on iMx51 Board for Ford project.
We have downloaded the BSP for Freescale iMx51 for 6.5.0 SP1 qnx from QNX website. But it didn’t contain the graphic libraries needed.
But we downloaded the package for graphics as mentioned in http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.opengl_es.topc20406?pageSize=-1#post_post86729.
Yet after making those changes as mentioned, the egl API’s were not working. We got error in the first step of getting the display id i.e eglGetDisplay(). But after making changes to graphics.conf file (made the begin display section to begin egl display 1), the error got surpassed and we got error in eglCreateContext(). This has been mentioned in the below logs. We are struck here and unable to proceed further.
For further info, display id returned by eglGetDisplay was “2” and egl configuration value returned was “11”. These two info are passed as parameter to eglCreateContext(), along with other config attributes.
Error we are facing now:
libs: init: libiow.so.1 obj->refcount: 1
libs: init: libgf.so.1 obj->refcount: 1
libs: init: libEGL_iMX5X.so obj->refcount: 1
libs: dlopen("devg-imx51.so",0)
Mode:
libs: Neither RTLD_GROUP nor RTLD_WORLD specified, assuming RTLD_GROUP | RTLD_WORLD
libs: load_object: attempt load of devg-imx51.so
libs: /fs/mp/usr/lib/devg-imx51.so: found; real path:/fs/mp/usr/lib/devg-imx51.so
libs: load_elf32: loaded lib at addr 799a8000(text) 799b3c38(data)
libs: object devg-imx51.so loaded; real soname: devg-imx51.so loaded from: /fs/mp/usr/lib/devg-imx51.so
libs: load_object: attempt load of libffb.so.2
libs: /proc/boot/libffb.so.2: found; real path:/proc/boot/libffb.so.2
libs: load_elf32: loaded lib at addr 799c0000(text) 799e5ee8(data)
libs: object libffb.so.2 loaded; real soname: libffb.so.2 loaded from: /proc/boot/libffb.so.2
libs: init: libffb.so.2 obj->refcount: 1
libs: init: devg-imx51.so obj->refcount: 1
eglCreateContext: failed to allocate resources for the requested operation
libs: dlclose(0x156240, 0)
libs: fini: devg-imx51.so obj->refcount: 0
libs: fini: libffb.so.2 obj->refcount: 0
eglGetdisplay:2egl_conf=11
libs: fini: libnavclient.so obj->refcount: 4
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post103385
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comDerek Leach2013-07-22T13:12:15Zpost103385: Open GL ES 1.4sankari G(deleted)http://community.qnx.com/sf/go/post1033852013-07-20T07:22:58Z2013-07-20T07:22:58ZWe are facing problem with OpenGL ES on iMx51 Board for Ford project.
We have downloaded the BSP for Freescale iMx51 for 6.5.0 SP1 qnx from QNX website. But it didn’t contain the graphic libraries needed.
But we downloaded the package for graphics as mentioned in http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.opengl_es.topc20406?pageSize=-1#post_post86729.
Yet after making those changes as mentioned, the egl API’s were not working. We got error in the first step of getting the display id i.e eglGetDisplay(). But after making changes to graphics.conf file (made the begin display section to begin egl display 1), the error got surpassed and we got error in eglCreateContext(). This has been mentioned in the below logs. We are struck here and unable to proceed further.
For further info, display id returned by eglGetDisplay was “2” and egl configuration value returned was “11”. These two info are passed as parameter to eglCreateContext(), along with other config attributes.
Error we are facing now:
libs: init: libiow.so.1 obj->refcount: 1
libs: init: libgf.so.1 obj->refcount: 1
libs: init: libEGL_iMX5X.so obj->refcount: 1
libs: dlopen("devg-imx51.so",0)
Mode:
libs: Neither RTLD_GROUP nor RTLD_WORLD specified, assuming RTLD_GROUP | RTLD_WORLD
libs: load_object: attempt load of devg-imx51.so
libs: /fs/mp/usr/lib/devg-imx51.so: found; real path:/fs/mp/usr/lib/devg-imx51.so
libs: load_elf32: loaded lib at addr 799a8000(text) 799b3c38(data)
libs: object devg-imx51.so loaded; real soname: devg-imx51.so loaded from: /fs/mp/usr/lib/devg-imx51.so
libs: load_object: attempt load of libffb.so.2
libs: /proc/boot/libffb.so.2: found; real path:/proc/boot/libffb.so.2
libs: load_elf32: loaded lib at addr 799c0000(text) 799e5ee8(data)
libs: object libffb.so.2 loaded; real soname: libffb.so.2 loaded from: /proc/boot/libffb.so.2
libs: init: libffb.so.2 obj->refcount: 1
libs: init: devg-imx51.so obj->refcount: 1
eglCreateContext: failed to allocate resources for the requested operation
libs: dlclose(0x156240, 0)
libs: fini: devg-imx51.so obj->refcount: 0
libs: fini: libffb.so.2 obj->refcount: 0
eglGetdisplay:2egl_conf=11
libs: fini: libnavclient.so obj->refcount: 4sankari G(deleted)2013-07-20T07:22:58Zpost103166: Graphics driver for Freescale IM51 EVKsankari G(deleted)http://community.qnx.com/sf/go/post1031662013-07-13T12:10:30Z2013-07-13T12:10:30ZHello all,
we are able to successfully run egl-gears application using IMX51 Board on WVGA LCD Display.
Further when we tried to run our own app using EGL API's got error in eglGetDisplay call and could not proceed further. EGL_DEFAULT_DISPLAY is passed as parameter. EGL_NO_DISPLAY (0) is returned.
Pls provide inputs for the same. The same app was running using Panda Board(OMAP)
(Also IMX 51 BSP does not provide any special graphics files as in OMAP(SS_BSP\prebuilt\armle-v7\usr\lib\graphics\
omap5430ES2_0)).sankari G(deleted)2013-07-13T12:10:30Zpost102930: opengl ES based on screen and screen high cpu lordZhan Chunhuanhttp://community.qnx.com/sf/go/post1029302013-07-05T02:28:59Z2013-07-05T02:28:59ZHello,
Now I'm using Opengl es2.0 based on screen.
When there is an animation , the render thread cpu lord is 10%, however the screen cpu lord can up to 20%,
I wander what the screen does when the render thread runs.
In my opinion, only the swapbuffer needs the screen, besides this ,screen doesn't do any thing.
Thanks & RegardsZhan Chunhuan2013-07-05T02:28:59Zpost102727: Re: OpenGL es2.0 questionEtienne Belanger(deleted)http://community.qnx.com/sf/go/post1027272013-06-27T15:58:24Z2013-06-27T15:58:24ZYou can have multiple independent contexts within a process at any time.
That's not a problem. You can only use one context in one thread at once,
though.
Normally, drivers will ref count resources that are shared between
contexts so that if you destroy a context that shares resources with
another, things should work just fine on the other context. That is not a
high runner use cases, however, so there is a lot less testing of these
scenarios than more traditional rendering set-ups.Etienne Belanger(deleted)2013-06-27T15:58:24Zpost102685: Re: OpenGL es2.0 questionShawn Zhang(deleted)http://community.qnx.com/sf/go/post1026852013-06-26T14:06:59Z2013-06-26T14:06:59ZHi Etienne, thanks for the reply and the sharing context solved my problem. Now both instances of maps are rendered on screen.
Here comes the second question, if the first instance of the render engine is destroyed( so is the egl context associated with it) and the second EGL context that depends on the first becomes a dangling context? How to deal with this situation?
What is the best way to deal with it? It looks to me that if I don’t use singletons in my render engine, then both EGL context and shader program will be independent from each other (though co-exist in the same app process), would that work?
Again your help is greatly appreciated.
ShawnShawn Zhang(deleted)2013-06-26T14:06:59Zpost102457: Re: OpenGL es2.0 questionEtienne Belanger(deleted)http://community.qnx.com/sf/go/post1024572013-06-19T21:53:14Z2013-06-19T21:53:14ZYou have to request sharing explicitly when calling eglCreateContext. There is a share_context argument.
Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Shawn Zhang
Sent: Wednesday, June 19, 2013 19:57
To: opengles-graphics
Reply To: opengles-graphics@community.qnx.com
Subject: OpenGL es2.0 question
I am having issue running an OGL v2 render engine in different threads. The use case is that an app would generate two instances of my render engine (for bb maps). The render engine itself has a couple of singletons serving OpenGL thread running and providing shader programs for different views.
The problem occurs (error# 1281, invalid value) when SECOND render thread tries to use the same shader program object (served by a singleton) by calling glUseProgram().
So my question is, how does OGL v2.0 work with different render threads in the same app process space? Do I have to create seperate shader programs for different render thread?
Any help is greatly appreciated.
Shawn
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post102449
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comEtienne Belanger(deleted)2013-06-19T21:53:14Zpost102449: OpenGL es2.0 questionShawn Zhang(deleted)http://community.qnx.com/sf/go/post1024492013-06-19T17:56:58Z2013-06-19T17:56:58ZI am having issue running an OGL v2 render engine in different threads. The use case is that an app would generate two instances of my render engine (for bb maps). The render engine itself has a couple of singletons serving OpenGL thread running and providing shader programs for different views.
The problem occurs (error# 1281, invalid value) when SECOND render thread tries to use the same shader program object (served by a singleton) by calling glUseProgram().
So my question is, how does OGL v2.0 work with different render threads in the same app process space? Do I have to create seperate shader programs for different render thread?
Any help is greatly appreciated.
ShawnShawn Zhang(deleted)2013-06-19T17:56:58Zpost96334: Re: OMAP3730 / OpenGL ESgao yuan(deleted)http://community.qnx.com/sf/go/post963342012-10-15T15:39:41Z2012-10-15T15:39:41ZI think the graphics_root is wrong.
maybe is
GRAPHICS_ROOT=/usr/lib/graphics/devg/omap3530gao yuan(deleted)2012-10-15T15:39:41Zpost96333: Re: OMAP3730 / OpenGL ESgao yuan(deleted)http://community.qnx.com/sf/go/post963332012-10-15T15:37:46Z2012-10-15T15:37:46ZI run the example successed in beagleboard.gao yuan(deleted)2012-10-15T15:37:46Zpost95832: Re: RE: RE: Doesn't compile demos of GF 3D for a PhotonVadim Vhttp://community.qnx.com/sf/go/post958322012-09-26T12:07:43Z2012-09-26T12:07:43ZJust it needed some extra libraries. Sorry.Vadim V2012-09-26T12:07:43Zpost95579: Re: RE: RE: Doesn't compile demos of GF 3D for a PhotonVadim Vhttp://community.qnx.com/sf/go/post955792012-09-14T07:57:16Z2012-09-14T07:57:16ZI suppose that it needs some header file, but what is? Standart Neutrino's GF,GLES and GLUES is all included, it is must be some header file from extra library, I guess?Vadim V2012-09-14T07:57:16Zpost95527: Re: RE: RE: Doesn't compile demos of GF 3D for a PhotonVadim Vhttp://community.qnx.com/sf/go/post955272012-09-12T14:09:52Z2012-09-12T14:09:52ZOK. Now I try to remake Linux glx-gears.c for compiling on QNX. Current error is "GLAPI does not name a type" in glues.h and glu.h . May I to fix this bug?
Best regards...Vadim V2012-09-12T14:09:52Zpost95354: RE: RE: Doesn't compile demos of GF 3D for a PhotonDerek Leachhttp://community.qnx.com/sf/go/post953542012-09-04T13:11:55Z2012-09-04T13:11:55ZNo, it is not possible to directly compile Mesa demos, the QNX stack is not based on Mesa.
Regards.
-----Original Message-----
From: Vadim V [mailto:community-noreply@qnx.com]
Sent: September-03-12 3:38 AM
To: opengles-graphics
Subject: Re: RE: Doesn't compile demos of GF 3D for a Photon
> You must compile with PhAB (Photon App Builder), there is no 'main()'
> in gears .c, it is a PhAB project.
>
OK, is this possible to compile(and to run) any Mesa demos on QNX650?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post95329
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comDerek Leach2012-09-04T13:11:55Zpost95329: Re: RE: Doesn't compile demos of GF 3D for a PhotonVadim Vhttp://community.qnx.com/sf/go/post953292012-09-03T07:38:05Z2012-09-03T07:38:05Z> You must compile with PhAB (Photon App Builder), there is no 'main()' in gears
> .c, it is a PhAB project.
>
OK, is this possible to compile(and to run) any Mesa demos on QNX650?Vadim V2012-09-03T07:38:05Zpost95015: RE: Doesn't compile demos of GF 3D for a PhotonDerek Leachhttp://community.qnx.com/sf/go/post950152012-08-22T12:39:06Z2012-08-22T12:39:06ZYou must compile with PhAB (Photon App Builder), there is no 'main()' in gears.c, it is a PhAB project.
-----Original Message-----
From: Vadim V [mailto:community-noreply@qnx.com]
Sent: August-22-12 3:58 AM
To: opengles-graphics
Subject: Doesn't compile demos of GF 3D for a Photon
Good time. I've downloaded Photon OpenGL ES demos demonstrating use of GF 2D/3D from http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.photon.gf_ph_2d,
and I tried to compile gears.c source under QNX650-host by:
#qcc -V gcc_ntox86 gears.c -lgf -lGLES_CM
But it generates error like:
.../crt1.o (text+0x04) Undefined reference to 'main'
.../crt1.o (text+0x86) In function _start:
Undefined reference to 'main'
This source of demo seems simple enough, but...
Please advise me how to compile OpenGL ES gears.c .
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post95009
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comDerek Leach2012-08-22T12:39:06Zpost95009: Doesn't compile demos of GF 3D for a PhotonVadim Vhttp://community.qnx.com/sf/go/post950092012-08-22T07:58:18Z2012-08-22T07:58:18ZGood time. I've downloaded Photon OpenGL ES demos demonstrating use of GF 2D/3D from http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.photon.gf_ph_2d,
and I tried to compile gears.c source under QNX650-host by:
#qcc -V gcc_ntox86 gears.c -lgf -lGLES_CM
But it generates error like:
.../crt1.o (text+0x04) Undefined reference to 'main'
.../crt1.o (text+0x86) In function _start:
Undefined reference to 'main'
This source of demo seems simple enough, but...
Please advise me how to compile OpenGL ES gears.c .Vadim V2012-08-22T07:58:18Zpost94278: QT with OpenGL ES on Beagle boarddang trihttp://community.qnx.com/sf/go/post942782012-07-17T07:03:58Z2012-07-17T07:03:58ZHello everybody,
I'm working on porting QT framework to QNX and I have some problem that I'm stuck at.
I've build QT for QNX and can make it work on Beagle board (armv7 + qnx) except that QtOpenGLES apps can not run. I means, such QT apps that contain no QTOpenGL code like collidingmice run well while the ones that contain QtOpenGL code like hellogl_es can not - they just show their window whithout opengl content inside when running.
I've tried QT 4.7.1 as well as 4.8.2 and the result are the same.
I've already install Composition Manager patch.
SGX already run and I can run gles1-gears, gles2-gears, ...
Any help please? Attached is my build file for Beagle board.
Thanks and regards,
DQTdang tri2012-07-17T07:03:58Zpost93222: Re: FBO flushingJoel Pilon(deleted)http://community.qnx.com/sf/go/post932222012-05-20T01:55:17Z2012-05-20T01:55:17ZThat should be fine, just don't re-use the same object in multiple renders in the same frame.
----- Original Message -----
From: Chris Keating [mailto:community-noreply@qnx.com]
Sent: Saturday, May 19, 2012 08:20 PM
To: opengles-graphics <opengles-graphics@community.qnx.com>
Subject: Re: FBO flushing
That's what I need to do though -- render to an offscreen, which gets rendered to another offscreen? How can this be accomplished without upgrading the driver?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post93221
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-20T01:55:17Zpost93221: Re: FBO flushingChris Keating(deleted)http://community.qnx.com/sf/go/post932212012-05-20T00:20:17Z2012-05-20T00:20:17ZThat's what I need to do though -- render to an offscreen, which gets rendered to another offscreen? How can this be accomplished without upgrading the driver?Chris Keating(deleted)2012-05-20T00:20:17Zpost93220: Re: FBO flushingJoel Pilon(deleted)http://community.qnx.com/sf/go/post932202012-05-19T23:53:49Z2012-05-19T23:53:49ZThat's should be fine. Just don't render to a texture and use it again to render to fbo0 or another texture.
----- Original Message -----
From: Chris Keating [mailto:community-noreply@qnx.com]
Sent: Saturday, May 19, 2012 07:03 PM
To: opengles-graphics <opengles-graphics@community.qnx.com>
Subject: Re: FBO flushing
To workaround this at the application level, do I just create extra render-buffers/textures? Do I need to render the same content to the extra render-buffer/FBO? Or can I do something like this:
Create FBO-A
Create FBO-B (create 2 textures of dim. WxH, call glFrameBufferTexture2d on both)
Draw FBO-B to FBO-A
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post93219
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-19T23:53:49Zpost93219: Re: FBO flushingChris Keating(deleted)http://community.qnx.com/sf/go/post932192012-05-19T23:03:28Z2012-05-19T23:03:28ZTo workaround this at the application level, do I just create extra render-buffers/textures? Do I need to render the same content to the extra render-buffer/FBO? Or can I do something like this:
Create FBO-A
Create FBO-B (create 2 textures of dim. WxH, call glFrameBufferTexture2d on both)
Draw FBO-B to FBO-AChris Keating(deleted)2012-05-19T23:03:28Zpost93142: Unable to run gf-egl-vsync Sample on QNX 6.5.0 on VmWareArun Krishnan Padmakumar(deleted)http://community.qnx.com/sf/go/post931422012-05-16T20:18:24Z2012-05-16T20:18:24ZI am trying to run the tutorial gf-egl-vsync sample on QNX 6.5.0 running on VMWare. When I am trying to run the sample I am getting the following error on eglCreateWindowSurface Function
“an EGLNativeWindowType argument does not refer to a valid native window”
What should be the possible cause of this error and does it have any resolution ?
Thanks,
Arun KrishnanArun Krishnan Padmakumar(deleted)2012-05-16T20:18:24Zpost93141: Unable to run gf-egl-vsync SampleArun Krishnan Padmakumar(deleted)http://community.qnx.com/sf/go/post931412012-05-16T20:17:48Z2012-05-16T20:17:48ZI am trying to run the tutorial gf-egl-vsync sample on QNX 6.5.0 running on VMWare. When I am trying to run the sample I am getting the following error on eglCreateWindowSurface Function
"an EGLNativeWindowType argument does not refer to a valid native window"
What should be the possible cause of this error and does it have any resolution ?
Thanks,
Arun KrishnanArun Krishnan Padmakumar(deleted)2012-05-16T20:17:48Zpost93060: Re: glScissor and tiling memory on SGXJoel Pilon(deleted)http://community.qnx.com/sf/go/post930602012-05-14T18:00:50Z2012-05-14T18:00:50ZKeep in mind, you should try to cache as many rects/masks in the 8 bit
stencil buffer. Multiple rects can be stored on each plane of the
stencil. Rendering the rects/mask is more expensive then the actual
stencil test. The stencil test is extremely cheap on PVR compared to
other architectures.
-Joel
On 12-05-14 01:17 PM, Chris Keating wrote:
> Deric: Not screen per se. Just GL stack in general.
>
> Thanks Joel. I'll have to play with that some more. I initially was using
> the stencil buffer but actually noticed a performance decrease at the time
> and so I went back to using the scissor.
>
> Chris Keating
> Crank Software Inc.
> Office: 613-595-1999 x515, Cell: 613-314-6136
> Online: www.cranksoftware.com
> Check out: Crank Software's Blog
> There is a better way to build user interfaces for embedded devices.
> Download a 30 day evaluation of Crank Storyboard Suite today!
>
> -----Original Message-----
> From: Joel Pilon [mailto:community-noreply@qnx.com]
> Sent: May-14-12 10:10 AM
> To: opengles-graphics@community.qnx.com
> Cc: Chris Keating; Chris Keating
> Subject: Re: glScissor and tiling memory on SGX
>
> Some of our older SGX drivers had issues with non-fullscreen glScissor
> rects. However, glScissor performs badly on the SGX, and we recommend using
> the stencil buffer to clip content.
>
> -Joel
>
> On 12-05-14 09:41 AM, Chris Keating wrote:
>> Are full-screen and partial-screen glScissor calls handled differently?
>>
>> I ran into an issue where a lot of partial-screen glScissor calls where
> being made and the end result was that a lot of stuff ended up missing from
> the end rasterization. Just setting the glScissor params to (0,0,800,478)
> instead of (0,0,800,480) was enough to show this issue.
>>
>> It kind of looks like some 64x64 macro-tiles are flat out getting dropped
> on the final render. Is it possible that the partial-screen glScissor calls
> are handled differently than full-screen ones, and are causing the SGX to
> run out of internal memory for its tiling lists in this case?
>>
>> Have you seen cases where tiles/macro-tiles have been dropped altogether?
>>
>>
>>
>> _______________________________________________
>>
>> OpenGL ES
>> http://community.qnx.com/sf/go/post93044
>> To cancel your subscription to this discussion, please e-mail
>> opengles-graphics-unsubscribe@community.qnx.com
>
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post93049
> To cancel your subscription to this discussion, please e-mail
> opengles-graphics-unsubscribe@community.qnx.com
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2171 / Virus Database: 2425/4998 - Release Date: 05/14/12
>
>
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post93056
> To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-14T18:00:50Zpost93056: RE: glScissor and tiling memory on SGXChris Keating(deleted)http://community.qnx.com/sf/go/post930562012-05-14T17:34:42Z2012-05-14T17:34:42ZDeric: Not screen per se. Just GL stack in general.
Thanks Joel. I'll have to play with that some more. I initially was using
the stencil buffer but actually noticed a performance decrease at the time
and so I went back to using the scissor.
Chris Keating
Crank Software Inc.
Office: 613-595-1999 x515, Cell: 613-314-6136
Online: www.cranksoftware.com
Check out: Crank Software's Blog
There is a better way to build user interfaces for embedded devices.
Download a 30 day evaluation of Crank Storyboard Suite today!
-----Original Message-----
From: Joel Pilon [mailto:community-noreply@qnx.com]
Sent: May-14-12 10:10 AM
To: opengles-graphics@community.qnx.com
Cc: Chris Keating; Chris Keating
Subject: Re: glScissor and tiling memory on SGX
Some of our older SGX drivers had issues with non-fullscreen glScissor
rects. However, glScissor performs badly on the SGX, and we recommend using
the stencil buffer to clip content.
-Joel
On 12-05-14 09:41 AM, Chris Keating wrote:
> Are full-screen and partial-screen glScissor calls handled differently?
>
> I ran into an issue where a lot of partial-screen glScissor calls where
being made and the end result was that a lot of stuff ended up missing from
the end rasterization. Just setting the glScissor params to (0,0,800,478)
instead of (0,0,800,480) was enough to show this issue.
>
> It kind of looks like some 64x64 macro-tiles are flat out getting dropped
on the final render. Is it possible that the partial-screen glScissor calls
are handled differently than full-screen ones, and are causing the SGX to
run out of internal memory for its tiling lists in this case?
>
> Have you seen cases where tiles/macro-tiles have been dropped altogether?
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post93044
> To cancel your subscription to this discussion, please e-mail
> opengles-graphics-unsubscribe@community.qnx.com
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post93049
To cancel your subscription to this discussion, please e-mail
opengles-graphics-unsubscribe@community.qnx.com
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2171 / Virus Database: 2425/4998 - Release Date: 05/14/12Chris Keating(deleted)2012-05-14T17:34:42Zpost93049: Re: glScissor and tiling memory on SGXJoel Pilon(deleted)http://community.qnx.com/sf/go/post930492012-05-14T14:18:24Z2012-05-14T14:18:24ZSome of our older SGX drivers had issues with non-fullscreen glScissor
rects. However, glScissor performs badly on the SGX, and we recommend
using the stencil buffer to clip content.
-Joel
On 12-05-14 09:41 AM, Chris Keating wrote:
> Are full-screen and partial-screen glScissor calls handled differently?
>
> I ran into an issue where a lot of partial-screen glScissor calls where being made and the end result was that a lot of stuff ended up missing from the end rasterization. Just setting the glScissor params to (0,0,800,478) instead of (0,0,800,480) was enough to show this issue.
>
> It kind of looks like some 64x64 macro-tiles are flat out getting dropped on the final render. Is it possible that the partial-screen glScissor calls are handled differently than full-screen ones, and are causing the SGX to run out of internal memory for its tiling lists in this case?
>
> Have you seen cases where tiles/macro-tiles have been dropped altogether?
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post93044
> To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-14T14:18:24Zpost93046: RE: glScissor and tiling memory on SGXDerek Leachhttp://community.qnx.com/sf/go/post930462012-05-14T13:52:47Z2012-05-14T13:52:47ZYou are talking about screen graphics stack I assume, just to be clear?
-----Original Message-----
From: Chris Keating [mailto:community-noreply@qnx.com]
Sent: May 14, 2012 9:41 AM
To: opengles-graphics
Subject: glScissor and tiling memory on SGX
Are full-screen and partial-screen glScissor calls handled differently?
I ran into an issue where a lot of partial-screen glScissor calls where being made and the end result was that a lot of stuff ended up missing from the end rasterization. Just setting the glScissor params to (0,0,800,478) instead of (0,0,800,480) was enough to show this issue.
It kind of looks like some 64x64 macro-tiles are flat out getting dropped on the final render. Is it possible that the partial-screen glScissor calls are handled differently than full-screen ones, and are causing the SGX to run out of internal memory for its tiling lists in this case?
Have you seen cases where tiles/macro-tiles have been dropped altogether?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post93044
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comDerek Leach2012-05-14T13:52:47Zpost93044: glScissor and tiling memory on SGXChris Keating(deleted)http://community.qnx.com/sf/go/post930442012-05-14T13:41:10Z2012-05-14T13:41:10ZAre full-screen and partial-screen glScissor calls handled differently?
I ran into an issue where a lot of partial-screen glScissor calls where being made and the end result was that a lot of stuff ended up missing from the end rasterization. Just setting the glScissor params to (0,0,800,478) instead of (0,0,800,480) was enough to show this issue.
It kind of looks like some 64x64 macro-tiles are flat out getting dropped on the final render. Is it possible that the partial-screen glScissor calls are handled differently than full-screen ones, and are causing the SGX to run out of internal memory for its tiling lists in this case?
Have you seen cases where tiles/macro-tiles have been dropped altogether?Chris Keating(deleted)2012-05-14T13:41:10Zpost92999: Re: imx53 Quickstart GLES failureAlberto Fontanhttp://community.qnx.com/sf/go/post929992012-05-10T13:54:15Z2012-05-10T13:54:15ZHello,
I get run gles2-egl-gears (OpenGL) in inx53QSB and I get 196 FPS. I have heared that it could be run at 300FPS, but i have the same problem as you when i try run egl-**** "Unresolved Symbol eglGetDisplay" Doy you get solve the problem?
If you want i tell you as i have done to run gles2-egl-gears
Best Regards,Alberto Fontan2012-05-10T13:54:15Zpost92930: Re: FBO flushingJoel Pilon(deleted)http://community.qnx.com/sf/go/post929302012-05-08T18:48:44Z2012-05-08T18:48:44ZI'm not sure what's been released or to who. You would need a 1.7 driver. The egl strings tell you which major version of the driver you're using.
However note the fix is to ghost (make addition copies) of render buffers. So if you were running out of memory using additional fbos, its quite likely you'll have the same issue with the newer driver. This kind of rendering really doesn't play well with deferred rendering tile based architectures.
-Joel
----- Original Message -----
From: Brian Edmond [mailto:community-noreply@qnx.com]
Sent: Tuesday, May 08, 2012 09:52 AM
To: opengles-graphics <opengles-graphics@community.qnx.com>
Subject: Re: FBO flushing
So do you know if that was ever released? Or when the fix was done?
Also any comment on my other question about releasing the memory, is that a known issue also?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post92929
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-08T18:48:44Zpost92929: Re: FBO flushingBrian Edmond(deleted)http://community.qnx.com/sf/go/post929292012-05-08T13:52:04Z2012-05-08T13:52:04ZSo do you know if that was ever released? Or when the fix was done?
Also any comment on my other question about releasing the memory, is that a known issue also?Brian Edmond(deleted)2012-05-08T13:52:04Zpost92928: Re: FBO flushingJoel Pilon(deleted)http://community.qnx.com/sf/go/post929282012-05-06T20:28:29Z2012-05-06T20:28:29ZI'm not aware of the omap bsp roadmap. Someone else will have to comment.
----- Original Message -----
From: Brian Edmond [mailto:community-noreply@qnx.com]
Sent: Sunday, May 06, 2012 01:25 PM
To: opengles-graphics <opengles-graphics@community.qnx.com>
Subject: Re: FBO flushing
Can you point me to a patch which addresses this? I would like to check the version of my driver as it was provided by a customer.
I tried using more FBO's but I ran into another issue. If I do the following:
Create FBO to render to
Create FBO
render content to FBO
Render FBO as a texture
Release FBO
Create FBO
render content to FBO
Render FBO as a texture
Release FBO
-- and so on many times
Swap Buffers
I will eveentually run out of memory, or crash in a glClear (I assume out of memory as the system is low). I assume the Release of the FBO is not freeing the memory because it is referenced somewhere and not released until the SwapBuffers?
Brian
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post92927
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-06T20:28:29Zpost92927: Re: FBO flushingBrian Edmond(deleted)http://community.qnx.com/sf/go/post929272012-05-06T17:25:29Z2012-05-06T17:25:29ZCan you point me to a patch which addresses this? I would like to check the version of my driver as it was provided by a customer.
I tried using more FBO's but I ran into another issue. If I do the following:
Create FBO to render to
Create FBO
render content to FBO
Render FBO as a texture
Release FBO
Create FBO
render content to FBO
Render FBO as a texture
Release FBO
-- and so on many times
Swap Buffers
I will eveentually run out of memory, or crash in a glClear (I assume out of memory as the system is low). I assume the Release of the FBO is not freeing the memory because it is referenced somewhere and not released until the SwapBuffers?
BrianBrian Edmond(deleted)2012-05-06T17:25:29Zpost92926: Re: FBO flushingJoel Pilon(deleted)http://community.qnx.com/sf/go/post929262012-05-06T16:47:37Z2012-05-06T16:47:37ZThis is fixed in newer drivers, the work around is to use more fbos.
----- Original Message -----
From: Brian Edmond [mailto:community-noreply@qnx.com]
Sent: Sunday, May 06, 2012 12:33 PM
To: opengles-graphics <opengles-graphics@community.qnx.com>
Subject: FBO flushing
I am using QNX 6.5 on a Beagleboard (PowerVR) and see issues when using a FBO as a scratch buffer. I have this senerio:
Main Window Surface
Create a FBO to render to (FBO1)
Create a second FBO to render to (FBO2)
Render content1 to FBO2
Render FBO2 to FBO1 as a texture
Clear and Render content2 to FBO2
Render FBO2 to FBO1 as a texture
Render FBO1 to Window surface as a texture
SwapBuffers
What I see is that only "content2" is visible. It seems that if I reuse the same FBO in a render cycle that the last thing I rendered gets displayed. This is true even if I call glFlush or glFinish after I render the FBO texture.
Is there something in the driver which does not execute the texture operations until the flush or should this work?
Brian
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post92925
To cancel your subscription to this discussion, please e-mail opengles-graphics-unsubscribe@community.qnx.comJoel Pilon(deleted)2012-05-06T16:47:37Zpost92925: FBO flushingBrian Edmond(deleted)http://community.qnx.com/sf/go/post929252012-05-06T16:33:02Z2012-05-06T16:33:02ZI am using QNX 6.5 on a Beagleboard (PowerVR) and see issues when using a FBO as a scratch buffer. I have this senerio:
Main Window Surface
Create a FBO to render to (FBO1)
Create a second FBO to render to (FBO2)
Render content1 to FBO2
Render FBO2 to FBO1 as a texture
Clear and Render content2 to FBO2
Render FBO2 to FBO1 as a texture
Render FBO1 to Window surface as a texture
SwapBuffers
What I see is that only "content2" is visible. It seems that if I reuse the same FBO in a render cycle that the last thing I rendered gets displayed. This is true even if I call glFlush or glFinish after I render the FBO texture.
Is there something in the driver which does not execute the texture operations until the flush or should this work?
BrianBrian Edmond(deleted)2012-05-06T16:33:02Zpost92692: run egl-configs: both gles1 and gles 2 are 0peng liu(deleted)http://community.qnx.com/sf/go/post926922012-04-23T08:39:28Z2012-04-23T08:39:28ZI am new on egl and qnx.
I run egl-configs on my QNX 632 on my hardware. All config's gles1 and gles 2 are 0.
Do than mean it do not support opengl es hardware acceleration?
thanks ahead.peng liu(deleted)2012-04-23T08:39:28Zpost91825: OMAP3730 / OpenGL ESAlex Pavloffhttp://community.qnx.com/sf/go/post918252012-02-27T22:48:28Z2012-02-27T22:48:28ZUsing 6.5.0, with the composition manager patch installed.
I was able to run gles1-egl-gears on an OMAP3530 board (Beagle).
I am now running on an OMAP3730, but it's not the BeagleXM.
I am running the devg-omap35xx from the 3730 BSP, as well as all of the prebuilt lib\graphics\omap3730 binaries.
My startup script has:
export GRAPHICS_ROOT=/usr/lib/graphics/devg
io-display -v -dvid=0,did=0
waitfor /dev/io-display 10
/usr/lib/graphics/devg/pvrsrvd
The business line of omap35xx.conf is:
hsw=0x3,hfp=143,hbp=169,vsw=1,vfp=28,vbp=1,ivs=1,ihs=1,ipc=1,ieo=0x0,acb=0,acbi=0,pcd=0x5,ppl=640,lpp=480,irq=25,disptype=0,lcdfmt=0x3,dpowerg70=1,verbose=5
Display.conf is:
device {
drivername=omap35xx
vid=0
did=0
modeopts=/etc/system/config/omap35xx.conf
display {
xres=640
yres=480
refresh=60
pixel_format=rgb888
}
}
graphics.conf is unchanged from the stock. With the verbose=5, I get all kinds of fun stuff in the slog about the driver initializing.
However, when I try to run gles1-egl-gears, I get:
# gles1-egl-gears
eglInitialize: EGL is not initialized, or could not be initialized, for the specified display
Any thoughts on how I'd track this down and figure out why EGL isn't initializing?Alex Pavloff2012-02-27T22:48:28Zpost91387: imx53 Quickstart GLES failureBrian Edmond(deleted)http://community.qnx.com/sf/go/post913872012-02-07T18:56:55Z2012-02-07T18:56:55ZI have an imx53 quickstart board and am trying to run OpenGL ES 2.0 on it. However eglGetDisplay fails for all apps including the gles2-egl-gears app that I downloaded from the QNX website. I am running with the imx gpu mgr patch and have GRAPHICS_ROOT set and am running io-gpumgr. I tried to pass NULL and a gf_dev_t handle into eglGetDisplay but both failed. Has anyone gotten this board to work with OpenGL ES 2.0?
Here is my sloginfo after running an app incase that helps:
Jan 01 03:22:01 5 10721 0 gpu_i.MX51: starting up...
Jan 01 03:22:02 5 10721 0 gpu_i.MX51: running
Jan 01 03:22:14 6 8 0 get_config_data(): xres=800 yres=480 refresh=60 output_fmt=24 di_sel=0 board=1 display_type=0 yuv_layer=1
Jan 01 03:22:14 6 8 0 HDMI: SiI9022A Tx
BrianBrian Edmond(deleted)2012-02-07T18:56:55Zpost91285: glBindFramebuffer blocked on pvrsrvdBrian Edmond(deleted)http://community.qnx.com/sf/go/post912852012-02-01T21:34:59Z2012-02-01T21:34:59ZI am using a Beagleboard XM with QNX 6.5. In my application I render some content offscreen to a FBO and then render it back to the main window surface before calling eglSwapBuffers. What I have found is that the call to glBindFramebuffer() is taking 70 msec. By doing a kernel trace I can see that my application is reply blocked on pvrsrvd for almost that entire time. I am wondering what pvrsrvd is doing during this time and why it takes so long?
BrianBrian Edmond(deleted)2012-02-01T21:34:59Zpost90887: FBO issue on SGXBrian Edmond(deleted)http://community.qnx.com/sf/go/post908872012-01-10T15:13:41Z2012-01-10T15:13:41ZHi,
I am having a problem with creating and binding framebuffer objects using the beagleboard. The application seems to run for a while and then hang. Once the app is restarted it again hangs trying to bind a Framebuffer object. The application is Reply blocked on pvrsrvd. I then saw this note in the SGX release notes:
* There are issues with framebuffer objects in the OpenGL ES 2.0 implementation
What are these issues you are refering to? Have you seen this Hang before?
BrianBrian Edmond(deleted)2012-01-10T15:13:41Zpost89514: eglChooseConfig unable to find compatible frame buffer configurationTony Mahieu(deleted)http://community.qnx.com/sf/go/post895142011-10-20T19:53:51Z2011-10-20T19:53:51ZI'm trying to get a "Hello World" OpenGL ES app working for the first time. I've tried following the help, but it's grossly lacking in examples. With the help in Momentics,
I do the following:
gf_dev_attach();
eglGetDisplay();
gf_display_attach();
gf_layer_attach();
These all work without issue. I run into problems when looping through each layer format, and calling eglChooseConfig with each format. It never finds a compatible format.
I'm running this on the Texas Instruments AM3517 EVM w/ QNX 6.5.0.
Anyone able to help? I'd really appreciate it.Tony Mahieu(deleted)2011-10-20T19:53:51Zpost89006: Re: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.Felipe Santanahttp://community.qnx.com/sf/go/post890062011-09-21T15:54:38Z2011-09-21T15:54:38ZHi,
Did you solve that problem, about libGLES and libEGL?
I am facing it right now, and just dont know what to do anymore.
Thx!Felipe Santana2011-09-21T15:54:38Zpost88836: Re: Performace on i.MX53 using OpenGL ES 1.1John Edwardshttp://community.qnx.com/sf/go/post888362011-09-15T02:05:10Z2011-09-15T02:05:10ZThanks for the reply. You are correct, I forgot about swap interval set to 1. Tomorrow I will re-run the benchmarks with it set to 0 to see if there is any difference.
What concerns me more than the FPS achieved is the amount of CPU being used by the demos. It seems abnormally elevated for this part (almost high enough to seem using a software rendered fallback or something). Especially the 90% in the OpenVG demo.
I will also try running the OpenVG tiger demo on the i.MX35 tomorrow to see what the performance characteristics are with FPS and CPU load.
Again, thanks for the reply. I would definitely like to keep following up on this issue, as hardware accelerated graphics (especially of the OpenVG variant) are imperative for our current application.
--johnJohn Edwards2011-09-15T02:05:10Zpost88835: Re: Performace on i.MX53 using OpenGL ES 1.1Jason Mawdsleyhttp://community.qnx.com/sf/go/post888352011-09-15T01:00:00Z2011-09-15T01:00:00ZYou are running swap interval 1, you cannot run benchmarks with swap
interval 1.
Remember, with swap interval 1, the following applies:
Rendering at > 60 fps means you are capped at 60fps
Rendering between 30-59fps means you are capped at 30 fps
Rendering between 20-29 fps means you are capped at 20 fps
Rendering between 15fps and 19 fps means you are capped at 15 fps
Etc
What performance did you get on Tiger on the imx35?
Jason
On 11-09-14 6:12 PM, "John Edwards" <community-noreply@qnx.com> wrote:
>I have been experimenting with the i.MX53 QSB and successfully have
>OpenGL ES 1.1, OpenGL ES 2.0, and OpenVG demo applications running.
>However, I am also seeing drastic performance discrepancies with what the
>i.MX53 should be capable of rendering.
>
>gles2-egl-gears:
>OpenGL ES 2.0 seems to perform the best currently being limited to vsync
>@ 60 fps and only using around 28% CPU as reported by top.
>
>gles1-egl-gears:
>OpenGL ES 1.1 is much worse providing 30 fps and using around 60% of the
>CPU.
>
>vg-egl-tiger:
>OpenVG is much worse than the others running at 15 fps and using around
>85% to 90% of the CPU. This is basically unusable and difficult to
>imagine the GPU2D module is producing performance that low. That's worse
>performance than the i.MX35 processor that uses the same GPU2D module at
>a lower clock speed.
>
>Are there any known issues regarding accelerated graphics performance on
>the i.MX53? Does QNX plan to improve these levels of performance? Any
>information would be very helpful in this matter.
>
>Sincerely,
>John
>
>
>
>_______________________________________________
>
>OpenGL ES
>http://community.qnx.com/sf/go/post88832
>Jason Mawdsley2011-09-15T01:00:00Zpost88832: Re: Performace on i.MX53 using OpenGL ES 1.1John Edwardshttp://community.qnx.com/sf/go/post888322011-09-14T22:12:14Z2011-09-14T22:12:14ZI have been experimenting with the i.MX53 QSB and successfully have OpenGL ES 1.1, OpenGL ES 2.0, and OpenVG demo applications running. However, I am also seeing drastic performance discrepancies with what the i.MX53 should be capable of rendering.
gles2-egl-gears:
OpenGL ES 2.0 seems to perform the best currently being limited to vsync @ 60 fps and only using around 28% CPU as reported by top.
gles1-egl-gears:
OpenGL ES 1.1 is much worse providing 30 fps and using around 60% of the CPU.
vg-egl-tiger:
OpenVG is much worse than the others running at 15 fps and using around 85% to 90% of the CPU. This is basically unusable and difficult to imagine the GPU2D module is producing performance that low. That's worse performance than the i.MX35 processor that uses the same GPU2D module at a lower clock speed.
Are there any known issues regarding accelerated graphics performance on the i.MX53? Does QNX plan to improve these levels of performance? Any information would be very helpful in this matter.
Sincerely,
JohnJohn Edwards2011-09-14T22:12:14Zpost88369: Invert displayBrian McLaughlinhttp://community.qnx.com/sf/go/post883692011-08-25T18:31:41Z2011-08-25T18:31:41ZOur mechanical designer wants to invert the LCD display. Is there a way to invert everything sent to the display?Brian McLaughlin2011-08-25T18:31:41Zpost88288: EGL and GL has R8 and RG88 definitions. Can we have the similar matching definitions in screen.h?Leon Xiahttp://community.qnx.com/sf/go/post882882011-08-23T13:52:14Z2011-08-23T13:52:14ZIf we want to create screen format in R8 and RG88, how can we expand screen.h to accommodate this? For R8 we might be able to use SCREEN_FORMAT_BYTE, but what about RG88? this is not a defined screen format. If screen is the service middle layer, it should define a more flexible format list to allow both application and low level driver to render various color format.Leon Xia2011-08-23T13:52:14Zpost87959: Unable to compile with openGL ES 2Mikko Alaluusuahttp://community.qnx.com/sf/go/post879592011-08-10T08:00:26Z2011-08-10T08:00:26ZHi,
I'm unable to compile my program using openGL ES 2 because the gl2ext.h file includes a macro GL_API_EXT. I can't find a definition for this macro anywhere (and neither can the compiler). Where is this macro defined?Mikko Alaluusua2011-08-10T08:00:26Zpost87138: Re: RE: RE: GLES 2.0 on the iMX5xStephen Bashfordhttp://community.qnx.com/sf/go/post871382011-07-06T14:53:24Z2011-07-06T14:53:24ZI didn't have libcpp.so.4 in my image so I'm re-testing with this and I will come back with additional info if that doesn't help.
Thanks,
StephenStephen Bashford2011-07-06T14:53:24Zpost87127: RE: RE: GLES 2.0 on the iMX5xGaétan Noëlhttp://community.qnx.com/sf/go/post871272011-07-06T13:53:32Z2011-07-06T13:53:32ZCan you send me the contents of sloginfo?
Can you attach your graphics.conf file?
What is GRAPHICS_ROOT set to exactly?
What is the listing of the directory pointed to by GRAPHICS_ROOT?
As a forward looking bit of info, you'll need libcpp.so.4 in your image
(it's used by GLES).
-----Original Message-----
From: Stephen Bashford [mailto:community-noreply@qnx.com]
Sent: July-05-11 11:25 AM
To: opengles-graphics
Subject: Re: RE: GLES 2.0 on the iMX5x
Can you help me understand my error.
I'm trying to run io-gpumgr and have followed this message and
configured GRAPHICS_ROOT.
However, when I run io-gpumgr I get the following error:
io-gpumgr: failed to get gpu manager dll from configuration file
0x00000001
I have checked and GRAPHICS_ROOT contains the graphics.conf file.
Thanks,
Stephen
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post87074Gaétan Noël2011-07-06T13:53:32Zpost87074: Re: RE: GLES 2.0 on the iMX5xStephen Bashfordhttp://community.qnx.com/sf/go/post870742011-07-05T15:25:08Z2011-07-05T15:25:08ZCan you help me understand my error.
I'm trying to run io-gpumgr and have followed this message and configured GRAPHICS_ROOT.
However, when I run io-gpumgr I get the following error:
io-gpumgr: failed to get gpu manager dll from configuration file 0x00000001
I have checked and GRAPHICS_ROOT contains the graphics.conf file.
Thanks,
StephenStephen Bashford2011-07-05T15:25:08Zpost86790: Re: RE: GLES 2.0 on the iMX5xBrian Edmond(deleted)http://community.qnx.com/sf/go/post867902011-06-23T01:15:59Z2011-06-23T01:15:59ZThanks for the information. I can now build and run 2.0 apps on my board. Once thing I have noticed is that the performance is not really what I expected. I can run my application by either using the gf API directly or via OpenGL ES 2.0. I find that I get a better framerate via the gf API which I did not expect. Also I use about the same CPU. The gf API is mainly software rendered I think and I end up using 90% of the CPU for my animations. When I use GL I use 56% of the CPU and then io-gpumgr uses 30% so it ends up being the same CPU usage.
Have you seen this before? Are there any limitations to the GL implementation?
Thanks,
BrianBrian Edmond(deleted)2011-06-23T01:15:59Zpost86759: RE: GLES 2.0 on the iMX5xGaétan Noëlhttp://community.qnx.com/sf/go/post867592011-06-21T17:14:12Z2011-06-21T17:14:12ZHi Brian,
It sounds like you're running gears using the SW version of GLES (just a setup problem).
I assume you have the GPU patch for the iMX53 (http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.imx51_gpu_driver.imx53_20101115, patch-650-2413-iMX53GPU.tar).
In 6.5.0, you still need GF, but there's a QNX redirection layer for EGL, GLES & VG (in /usr/lib/), and it needs the GRAPHICS_ROOT environment variable to be set to point to the folder where the HW specific Khronos libs are located. Our standard folder location on the iMX53 for those libs would be /usr/lib/graphics/iMX5X/, so you would set:
GRAPHICS_ROOT=/usr/lib/graphics/iMX5X
In this folder, there needs to be the graphics.conf file (found in the GPU patch, already in that location). The redirection layer will then load the appropriate HW specific libs from there when needed.
The io-gpumgr resource manager also relies on GRAPHICS_ROOT being set properly.
So in summary, to setup your system, the proper order would be:
- set GRAPHICS_ROOT
- run io-display
- run io-gpumgr
Then you can run io-winmgr (if needed) and Khronos related applications.
Cheers,
Gaétan
-----Original Message-----
From: Brian Edmond [mailto:community-noreply@qnx.com]
Sent: June-20-11 9:38 PM
To: opengles-graphics
Subject: GLES 2.0 on the iMX5x
I am trying to get OpenGL ES 2.0 to run on an iMX51 board. I can run egl-gears on the board and I can build my own OpenGL ES 1.x app as long as I use the gl_ api and use the gf3d target stuff. However I thought this changed in 6.5 and I did not have to use the gf API any longer? I then tried to build a 2.0 version of egl-gears but it just fails to run saying that it can't find a eglConfig. Are there any sample applications for 2.0 and instructions on how to configure GL and build them? I also downloaded a SGX patch for the iMX, which included io-gpumgr but I can't find any instructions on what to do with this manager. It seems to include some new gl libraries also which I am not sure what to do with.
Thanks,
Brian
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post86729Gaétan Noël2011-06-21T17:14:12Zpost86729: GLES 2.0 on the iMX5xBrian Edmond(deleted)http://community.qnx.com/sf/go/post867292011-06-21T01:38:12Z2011-06-21T01:38:12ZI am trying to get OpenGL ES 2.0 to run on an iMX51 board. I can run egl-gears on the board and I can build my own OpenGL ES 1.x app as long as I use the gl_ api and use the gf3d target stuff. However I thought this changed in 6.5 and I did not have to use the gf API any longer? I then tried to build a 2.0 version of egl-gears but it just fails to run saying that it can't find a eglConfig. Are there any sample applications for 2.0 and instructions on how to configure GL and build them? I also downloaded a SGX patch for the iMX, which included io-gpumgr but I can't find any instructions on what to do with this manager. It seems to include some new gl libraries also which I am not sure what to do with.
Thanks,
BrianBrian Edmond(deleted)2011-06-21T01:38:12Zpost86725: Using OpenGL ESGuido Carballohttp://community.qnx.com/sf/go/post867252011-06-20T20:55:37Z2011-06-20T20:55:37ZHello;
I'm trying to write a simple "Hello world!" program to
display just that, a "hello" message using OpenGL ES on QNX, but so far
that has been impossible. The tutorials on the QNX webpage I think that
are incomplete or something, 'cause if I try to follow them I always get
errors. Can somebody tell me, where can I find a step-by-step tutorial
on how can I use OpenGL ES on QNX. I'll greatly appreciate the help. I'm
completely new to QNX and OpenGL, so you guys can image how much I'm
struggling.
Regards!]
Guido Carballo
XMobotsGuido Carballo2011-06-20T20:55:37Zpost79595: Re: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.trevor fuhttp://community.qnx.com/sf/go/post795952010-12-21T16:23:31Z2010-12-21T16:23:31Z> There is currently no OpenGL ES 2 support on VMWare.
>
I ran the app on a ATOM board, the same problem.
I am afraid it is caused by somewhere are not configured while invoking APIs
of EGL/OPENGL.trevor fu2010-12-21T16:23:31Zpost79577: Re: help, urgent! - eglChooseConfig works while linking with
libGLES_CM but fails while linking with libEGL.Etienne Belanger(deleted)http://community.qnx.com/sf/go/post795772010-12-21T15:23:50Z2010-12-21T15:23:50ZThere is currently no OpenGL ES 2 support on VMWare.Etienne Belanger(deleted)2010-12-21T15:23:50Zpost79571: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.trevor fuhttp://community.qnx.com/sf/go/post795712010-12-21T15:11:50Z2010-12-21T15:11:50ZAfter I upgrade my program to ES2.0, eglChooseConfig always return 0 number of config, it means it cannot find a proper config.
When I digged into I found more info - in the original version, I link the program with libGLES_CM, it works well. But after I modify it to link with libEGL aand libGLESv2, eglChooseConfig always fail to find a proper config.
I run the app in VMWare+QNX6.5.
Looking forward you help to figure out the problem, I will have a demo in these couple of days.
Thanks.
Pieces of code are in the attachment.trevor fu2010-12-21T15:11:50Zpost78410: Is this the future of Open GL/ES and QNX ?Armin Steinhoffhttp://community.qnx.com/sf/go/post784102010-12-12T15:47:21Z2010-12-12T15:47:21Zhttp://www.telecomtv.com/comspace_newsDetail.aspx?n=47024&id=e9381817-0593-417a-8639-c4c53e2a2a10#Armin Steinhoff2010-12-12T15:47:21Zpost75815: GL Studio supportAlan Zhanghttp://community.qnx.com/sf/go/post758152010-11-24T16:18:45Z2010-11-24T16:18:45ZHello,
There is a third party tool called GL Studio that can support VxWork, Linux. Some potential customer of us want to konw that if it can support QNX. Does anyone has experience about this? Thanks very much!
Best regards,
AlanAlan Zhang2010-11-24T16:18:45Zpost74494: Performace on i.MX53 using OpenGL ES 1.1Howard Smith(deleted)http://community.qnx.com/sf/go/post744942010-11-12T17:37:20Z2010-11-12T17:37:20ZHello,
I have been doing some benchmarking on gles1-egl demos such as gles1-egl-coaster, planetary, gears etc and have found very poor performace on i.MX53 running QNX 6.5.0 with arm v7 instructions and gcc 4.4.2. quite a few of them run sub 10 FPS and this one, gles1-egl-gears hits about 33 FPS. The openGL ES 2.0 version, gles2-egl-gears runs at 199 FPS. I would expect the openGL ES 1.1 demo to run much faster than 33 FPS on this hardware.
I did a pidin -p and got the following which seems to indicated I am running with HW acceleration not SW but I'm not sure.
pidin -P gles1-egl-gears mem
pid tid name prio STATE code data stack
176141 1 gles1-egl-gears 10r READY 20K 19M 24K(516K)*
libc.so.3 @ 1000000 460K 16K
libGLESv1_CM.so.1 @78000000 20K 4096
libEGL.so.1 @78006000 36K 8192
libgsl_iMX5X.so.1 @78011000 32K 4096
libiow.so.1 @7801a000 20K 4096
libm.so.2 @78020000 148K 8192
libc2d_iMX5X.so.1 @78047000 48K 8192
libEGL_iMX5X.so @78060000 72K 4096
devg-imx51.so @78073000 40K 8192
libgf.so.1 @78080000 96K 4096
libffb.so.2 @780a0000 148K 8192
libcpp.so.4 @780d0000 328K 36K
GLESv1_CM_iMX5X.so @78130000 204K 8192
libGLESv2_iMX5X.so @78200000 2756K 80K
em/ctl-0000,0000,0 @28000000 ( 0) 4096
mem/rbSharedMemory @28001000 ( 0) 4096
face-0000,0000,0:1 @28010000 ( 0) 752K
face-0000,0000,0:0 @280d0000 ( 0) 752K
/dev/mem @28200000 ( 0) 16M
# 164 frames in 5.017 seconds = 32.689 FPS
Are there any tricks to get OpenGL ES 1.1 to run properly. We see the same performace issues on i.MX51.
Thanks,
HowieHoward Smith(deleted)2010-11-12T17:37:20Zpost71671: Performance of using VBO in windowless pluginYang Jiaohttp://community.qnx.com/sf/go/post716712010-10-21T08:55:44Z2010-10-21T08:55:44ZI wrote a windowless plugin, which used the VBO.
The VBO operations (glBindBuffer...) cost a lot of time.
But I wrote another native program running on QNX, which also used VBO. This time the VBO operations didn't need so much time.
Is there any difference between windowless plugin and native program of using VBO?
Does the windowless plugin have no hardware acceleration? just software emulation?Yang Jiao2010-10-21T08:55:44Zpost70003: Re: RE: SVN check out ID and PasswordJIN YOUNC CHEONhttp://community.qnx.com/sf/go/post700032010-10-07T23:08:39Z2010-10-07T23:08:39ZThank you, Max.JIN YOUNC CHEON2010-10-07T23:08:39Zpost69857: RE: SVN check out ID and PasswordMax Feilhttp://community.qnx.com/sf/go/post698572010-10-06T22:00:34Z2010-10-06T22:00:34ZPlease read:
http://community.qnx.com/sf/wiki/do/viewPage/projects.community/wiki/Upd
atedQNXSourceAccessPolicyFAQ
-----Original Message-----
From: JIN YOUNC CHEON [mailto:community-noreply@qnx.com]
Sent: Wednesday, October 06, 2010 5:16 PM
To: opengles-graphics
Subject: SVN check out ID and Password
Hello.
I tried www.qnx.com mylogin ID and PW to check out
http://community.qnx.com/svn/repos/graphics/trunk" but it was denied.
Do I need another ID/PW for this? Or, do I need your grant for this?
Thank you.
Jin Young.
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post69851Max Feil2010-10-06T22:00:34Zpost69851: SVN check out ID and PasswordJIN YOUNC CHEONhttp://community.qnx.com/sf/go/post698512010-10-06T21:15:41Z2010-10-06T21:15:41ZHello.
I tried www.qnx.com mylogin ID and PW to check out http://community.qnx.com/svn/repos/graphics/trunk" but it was denied.
Do I need another ID/PW for this? Or, do I need your grant for this?
Thank you.
Jin Young.JIN YOUNC CHEON2010-10-06T21:15:41Zpost69701: Please grant my membership request.JIN YOUNC CHEONhttp://community.qnx.com/sf/go/post697012010-10-06T10:12:55Z2010-10-06T10:12:55ZHello.
I hope to join the Graphics Project. I am waiting for you grant.
Thanks.
Jin Young.JIN YOUNC CHEON2010-10-06T10:12:55Zpost67544: RE: the differnce between libgf.so and libgf.so.1Derek Leachhttp://community.qnx.com/sf/go/post675442010-09-16T12:08:44Z2010-09-16T12:08:44ZIn essence, there is no difference, on a Neutrino run-time target,
libgf.so should be a link to libgf.so.1, this is the same on a Neutrino
host as well.
If you are developing on a Windows box with Neutrino SDP installed,
Windows does not support links, so there will be two separate files, but
they _should_ be identical to one another.
You should link against the libgf.so ... I cannot comment on the
behaviour changes, as I am not sure what would cause it.
-Derek
-----Original Message-----
From: Kailen High [mailto:community-noreply@qnx.com]
Sent: Thursday, September 16, 2010 6:03 AM
To: opengles-graphics
Subject: the differnce between libgf.so and libgf.so.1
Hello everyone!
When I complie a binary named gf_test ,I linked the dynamic lib
(libgf.so.1),As a result , the error tips that :cannot find -lgf.so.but
when I linked the dynamic lib(
libgf.so),the compling is successful. Then I run the gf_test with
DL_DEBUG=1,the lib(libgf.so.1) is loaded.
what is the difference between libgf.so and libgf.so.1?
why did I complie gf_test with libgf.so, the libgf.so.1 is
loaded when running gf_test?
Please give me some advice ,thanks!
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post67537Derek Leach2010-09-16T12:08:44Zpost67537: the differnce between libgf.so and libgf.so.1Kailen Highhttp://community.qnx.com/sf/go/post675372010-09-16T10:03:10Z2010-09-16T10:03:10ZHello everyone!
When I complie a binary named gf_test ,I linked the dynamic lib (libgf.so.1),As a result , the error tips that :cannot find -lgf.so.but when I linked the dynamic lib(
libgf.so),the compling is successful. Then I run the gf_test with DL_DEBUG=1,the lib(libgf.so.1) is loaded.
what is the difference between libgf.so and libgf.so.1?
why did I complie gf_test with libgf.so, the libgf.so.1 is loaded when running gf_test?
Please give me some advice ,thanks!Kailen High2010-09-16T10:03:10Zpost64958: how to dump PbufferSurface into an image fileAhsan Habibhttp://community.qnx.com/sf/go/post649582010-08-30T08:09:08Z2010-08-30T08:09:08ZI want to dump PbufferSurface or GFSurface into a jpeg or bmp format image.
Can someone give demo or example?
Thanks.Ahsan Habib2010-08-30T08:09:08Zpost64927: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoPavel Kharthttp://community.qnx.com/sf/go/post649272010-08-28T20:11:34Z2010-08-28T20:11:34ZMy way to build QT for QNX on Linux Host
- Install QNX SDP 6.4.1 (Linux Host)
- Install QNX 6.4.1 (on VBox)
- Qt 4.6.3 source
- In mkspecs/.../ qnx-i386-g++.conf replace compiler version -> 4.3.3
- Build Qt-Embedded on Linux Host ::
./configure -xplatform unsupported/qws/qnx-i386-g++ -embedded i386 -no-gfx-linuxfb -no-mouse-linuxtp -no-kbd-tty -no-qt3support -qt-gfx-qnx -qt-mouse-qnx -qt-kbd-qnx -no-exceptions -nomake demos -nomake examples
...
gmake
...
su -c "gmake install"
...
- Build Qt application with Qt Creator (set qt for QNX version)
--------
On Target QNX system:
1) Copy Qt shared libraries [in 1 of LD_LIBRARY_PATH folders]
2) Copy fonts from Qt-Embedded
3) QWS_DISPLAY, QWS_MOUSE_PROTO and QWS_KEYBOARD
environment variables should all be set to qnx (edit $HOME/.profile)
4) Create sh-file::
...
/usr/photon/bin/devi-hid -Pr kbd mouse
./appname
slay devi-hid
sleep 1
/usr/photon/bin/devi-hid kbd mouse
...
5) Exit Photon
6) Run It!Pavel Khart2010-08-28T20:11:34Zpost64729: OpenGL ES rendering to memory glReadPixelsAhsan Habibhttp://community.qnx.com/sf/go/post647292010-08-27T10:29:17Z2010-08-27T10:29:17ZHi all,
I am drawing something well on QNX-Car system ok.And I also want a " screen shot" of the framebuffer.Here is the key code:
char *image;
image = (char *)malloc(width * height * 3 * sizeof(png_byte));
....(drawing )
glFlush();
glFinish();
image = (png_byte *)malloc(width * height * 3 * sizeof(char));
glPixelStorei(GL_PACK_ALIGNMENT, 1);
glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, (unsigned char *)image);
But I can't get anything in the memory address of image?
Can some one give me hints or codes about how to use glReadPixels of OpenGL ES under QNX-Car system.
Thanks!Ahsan Habib2010-08-27T10:29:17Zpost64722: Re: Frame Buffer creationArmin Steinhoffhttp://community.qnx.com/sf/go/post647222010-08-27T07:47:24Z2010-08-27T07:47:24ZHi Ahsan,
if you need a framebuffer, use SDL:
http://community.qnx.com/sf/frs/do/viewSummary/projects.qnx_community_sdl_project/frs
This could also help: http://www.sand-labs.org/owb
--Armin
Ahsan Habib wrote:
> Last one month or so, we are struggling with OpenGL in QNX. We need some help or advice on how to move forward.
>
> Here is what we trying to do: We want to draw map using OpenGL in WebKit. To do that, we have created a plugin that should create an OpenGL context and give it to our OpenGL Map Rendering lib. However, from the forum (replied by Jason Mawdsley and Joel Polin), we come to learn that we can’t create context for Webkit. So, we gave up our hope on this one. We have tested in creating context in native qnx app but we need to do it in a browser setup.
>
> As an alternate, we are trying to create a framebuffer, and then map rendering library can use the framebuffer to create map image, and then use the map image in the WebKit. We are still having trouble in creating a framebuffer from the plugin.
>
> It would be extremely helpful if someone can help us in using OpenGL to draw map in the browser. If there is any example that you guys can share to draw any image using OpenGL in the browser, could you please share that with me?
>
> --Ahsan
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post64701Armin Steinhoff2010-08-27T07:47:24Zpost64701: Frame Buffer creationAhsan Habibhttp://community.qnx.com/sf/go/post647012010-08-26T22:39:57Z2010-08-26T22:39:57ZLast one month or so, we are struggling with OpenGL in QNX. We need some help or advice on how to move forward.
Here is what we trying to do: We want to draw map using OpenGL in WebKit. To do that, we have created a plugin that should create an OpenGL context and give it to our OpenGL Map Rendering lib. However, from the forum (replied by Jason Mawdsley and Joel Polin), we come to learn that we can’t create context for Webkit. So, we gave up our hope on this one. We have tested in creating context in native qnx app but we need to do it in a browser setup.
As an alternate, we are trying to create a framebuffer, and then map rendering library can use the framebuffer to create map image, and then use the map image in the WebKit. We are still having trouble in creating a framebuffer from the plugin.
It would be extremely helpful if someone can help us in using OpenGL to draw map in the browser. If there is any example that you guys can share to draw any image using OpenGL in the browser, could you please share that with me?
--AhsanAhsan Habib2010-08-26T22:39:57Zpost64384: Problem with glTexSubImage2D() creating texture of size 8x32Glenn Schmottlachhttp://community.qnx.com/sf/go/post643842010-08-25T18:04:05Z2010-08-25T18:04:05ZThis is a problem we have encountered on a TI OMAP 3730 development board using OpenGL-ES 1.0.
If we create a texture of size 8x32
glGenTextures(1, &imageData->textureID);
glBindTexture(GL_TEXTURE_2D, imageData->textureID);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, textureFormat, 8,32, 0,
textureFormat, format, NULL);
and then fill it with pixels of size 7x17
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 7,17, textureFormat,
format, pixelData);
the resulting texture is broken, only every second scan line from
pixelData is used and the bottom half of the texture is filled with garbage.
If we change the width of the texture to 32 when it is created
glTexImage2D(GL_TEXTURE_2D, 0, textureFormat, 32,32, 0,
textureFormat, format, NULL);
then filling it with the 7x17 image works fine. Also, if we only fill the
first 16 lines, i.e.,
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 7,16, textureFormat,
format, pixelData);
it works as expected. It looks as if the scanline used by glTexSubImage2D when reading pixelData depends on the height provided.
I hope someone from QNX may help to understand this. Our current workaround is to increase the width of textures in case the width is less than the height. This is unfortunate, though, since we waste memory for tall images.
We have created a small C program that illustrates the problem that is attached to this post. When drawing into a texture of size 8x32, the result is crippled as shown in the bottom line in the attached screenshot. The other texture format 16x32, 32x32, 32x8, 32x16 seem to work.
I compiled the example with
> ntoarm-gcc src/BugglTexImage2D.c -o BugglTexImage2D -lGLESv1_CM -lEGL -lKD -lm
If QNX could please look at this code and confirm whether or not it is a bug. If it is a bug then better suggestions for a work-around would be appreciated.
Thanks....Glenn Schmottlach2010-08-25T18:04:05Zpost63744: RE: Hardware support for OpenGL ES?Derek Leachhttp://community.qnx.com/sf/go/post637442010-08-20T15:30:08Z2010-08-20T15:30:08ZWhat version of gles do you mean? 1.1 is still available under the
GF/Photon world, if the devg driver supports it.
If you are asking about 2.0, someone else will need to comment.
-----Original Message-----
From: Michael Kerpan [mailto:community-noreply@qnx.com]
Sent: Friday, August 20, 2010 11:28 AM
To: opengles-graphics
Subject: Hardware support for OpenGL ES?
Is there any 3D acceleration support left in x86 QNX? I know that at one
point, there was support for Voodoo boards and some early Intel
intergrated stuff, but has that been built on at all or has it just been
left stagnant and/or removed? Also, is the OpenGL SADK stuff available
to people with a hobbyist license or is that for paid customers only?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post63743Derek Leach2010-08-20T15:30:08Zpost63743: Hardware support for OpenGL ES?Michael Kerpanhttp://community.qnx.com/sf/go/post637432010-08-20T15:28:28Z2010-08-20T15:28:28ZIs there any 3D acceleration support left in x86 QNX? I know that at one point, there was support for Voodoo boards and some early Intel intergrated stuff, but has that been built on at all or has it just been left stagnant and/or removed? Also, is the OpenGL SADK stuff available to people with a hobbyist license or is that for paid customers only?Michael Kerpan2010-08-20T15:28:28Zpost63452: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoTom Freedyhttp://community.qnx.com/sf/go/post634522010-08-18T18:42:00Z2010-08-18T18:42:00ZI am interested also.
Thanks,
ThomasTom Freedy2010-08-18T18:42:00Zpost62889: opengl es in browser pluginAhsan Habibhttp://community.qnx.com/sf/go/post628892010-08-13T02:29:12Z2010-08-13T02:29:12ZI can successfully run opengl es demo in qnx-car head unit hardware and qnx GF drawings in qnx browser plugin. However, it seems that qnx browser webkit doesn't have native support on qnx opengl es in its plugin.
Does anyone know how to create opengl context in qnx browser plugin?
Thanks a lot.Ahsan Habib2010-08-13T02:29:12Zpost62014: Re: RE: eglChooseConfig always get 0 in 4th parameterXiongwei Huanghttp://community.qnx.com/sf/go/post620142010-08-06T14:15:50Z2010-08-06T14:15:50ZHi
I test it on the original driver . and I think it will be the same on my modified driver .
I just test it up to layer 2.
I could check in the driver log for loop query .
but the flash config file works fine . it also use the egl config index number .Xiongwei Huang2010-08-06T14:15:50Zpost61995: RE: eglChooseConfig always get 0 in 4th parameterDerek Leachhttp://community.qnx.com/sf/go/post619952010-08-06T13:11:40Z2010-08-06T13:11:40ZIs this using your modified driver with the 3 real/3 virtual layers?
I am not saying the problem is with your driver, maybe in the EGL, but
is your omap_layer_query() callout in the driver OK?
Have you extended it to do all 6 layers? My _guess_ is the library goes
into a loop, and when the layer query fails, it stops (in default case).
Maybe when you specify the layer, it bypasses this loop?
Do you see any layer query calls coming into your driver during this
failure?
Thanks!
-----Original Message-----
From: Xiongwei Huang [mailto:community-noreply@qnx.com]
Sent: Thursday, August 05, 2010 9:32 PM
To: opengles-graphics
Subject: Re: eglChooseConfig always get 0 in 4th parameter
Hi
yes .
As example .
my egl-config
1 rgb565 layer 0
2 rgb888 layer 0
3 argb565 layer 0
4 argb8888 layer 1
5 rgb565 layer 1
6 argb1555 layer 1
when I use gles1-egl-gears -config= 1 2 3 , it works . and when I use
gles1-egl-gears -config=4 5 6 . the egl_num_configs is get 0
when I use gles1-egl-gears -layer=1 . It works . the egl_num_configs is
4 .
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post61943Derek Leach2010-08-06T13:11:40Zpost61943: Re: eglChooseConfig always get 0 in 4th parameterXiongwei Huanghttp://community.qnx.com/sf/go/post619432010-08-06T01:32:08Z2010-08-06T01:32:08ZHi
yes .
As example .
my egl-config
1 rgb565 layer 0
2 rgb888 layer 0
3 argb565 layer 0
4 argb8888 layer 1
5 rgb565 layer 1
6 argb1555 layer 1
when I use gles1-egl-gears -config= 1 2 3 , it works . and when I use gles1-egl-gears -config=4 5 6 . the egl_num_configs is get 0
when I use gles1-egl-gears -layer=1 . It works . the egl_num_configs is 4 .Xiongwei Huang2010-08-06T01:32:08Zpost61725: Re: eglChooseConfig always get 0 in 4th parameterDerek Leachhttp://community.qnx.com/sf/go/post617252010-08-05T13:24:22Z2010-08-05T13:24:22Zok, just to verify your statements, in the case where things "do not work", you are just using the default level, but when things "are working", you are forcing the EGL_LEVEL?Derek Leach2010-08-05T13:24:22Zpost61662: eglChooseConfig always get 0 in 4th parameterXiongwei Huanghttp://community.qnx.com/sf/go/post616622010-08-05T01:21:03Z2010-08-05T01:21:03ZHi
When I test with the gles-egl-gears sample code in the function
eglChooseConfig(egl_disp, (EGLint*)&egl_conf_attr,
egl_configs, 1, &egl_num_configs);
when I test with the config from 1 to 3 the egl_num_configs 1
but when the config from 4 to 10 , the gel_num_configs is always 0
It looks like
http://www.imgtec.com/forum/forum_posts.asp?TID=21
and when I force layer to 1 the gel_num_configs is 4
my platform is omap3530 , I test it both on the omap3530 (ES 3.1)and saras (ES 2.1) with driver from
http://community.qnx.com/sf/frs/do/viewRelease/projects.customer_farmington_hills/frs.sgx_graphics.drop11_sgx_and_flash
Thanks and Best regardsXiongwei Huang2010-08-05T01:21:03Zpost56358: Re: How to display OpengGL Demos with VMwareChen ShunLihttp://community.qnx.com/sf/go/post563582010-06-09T05:06:19Z2010-06-09T05:06:19ZMore Informations:
1. The OpenGL ES version is 1.4
2. Please check the attached display.conf
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------Chen ShunLi2010-06-09T05:06:19Zpost56354: Re: How to display OpengGL Demos with VMwareChen ShunLihttp://community.qnx.com/sf/go/post563542010-06-09T04:08:34Z2010-06-09T04:08:34ZThanks for your quickly response.
Our aim is Navigation with hardware, but we need a PC Simulator also. So I
think we can run it at VMware.
I try to run egl-gears just now but there is problem:
I run it without photon( Because the function eglChooseConfig return 0
config with photon running ).
After the egl-gears ran, the window is change to black but nothing
displayed in it.
Please check the attached 2 SnapShots.
Thanks
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------Chen ShunLi2010-06-09T04:08:34Zpost56352: RE: How to display OpengGL Demos with VMwareJoel Pilon(deleted)http://community.qnx.com/sf/go/post563522010-06-09T02:56:14Z2010-06-09T02:56:14ZThe gfi-demo is not an opengles demo and you'll need a touch screen or mouse.
Regardless, if you'd like to run it, you can try ensuring io-hid and devi-hid is running.
If not you can try:
io-hid -dusb
devi-hid -rP mouse
If your more interested in gles, you can try running egl-gears.
Note however, these are all legacy applications. Our new graphics uses composition manager (io-winmgr) to run graphical applications in a composited windowing system environment. Some of these applications can be found in the public svn repository under trunk/apps/kd and trunk/apps/egl.
It's probably also worth mentioning we support accelerated gles2 and vg on various platforms. Currently, we only support software gles1.0 under vmware.
-Joel
-----Original Message-----
From: Chen ShunLi [mailto:community-noreply@qnx.com]
Sent: Tue 6/8/2010 10:29 PM
To: opengles-graphics
Subject: How to display OpengGL Demos with VMware
Environment:
VMWare Player 3.1 + QNX 6.4.1
I copy the demo files ("egl-pdemo"/"gfi-demo") to QNX OS and run it. I got the failure "gfi_group_attach() failed"
Could you please tell me what's wrong with it.
Comments:
1. I have add the VMware device to display.conf
2. I run it under without photon.
Thanks
=====================================
Chen Shunli
AVNC&IS Division
Neusoft Co., Ltd.
No.2 Xin Xiu Street. Hun Nan New District,
Shenyang 110179, PRC
Tel:+86 24 83664044
Fax:+86 24 23781242
Email:chensl@neusoft.com
Http://www.neusoft.com
=====================================
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post56350Joel Pilon(deleted)2010-06-09T02:56:14Zpost56350: How to display OpengGL Demos with VMwareChen ShunLihttp://community.qnx.com/sf/go/post563502010-06-09T02:29:09Z2010-06-09T02:29:09ZEnvironment:
VMWare Player 3.1 + QNX 6.4.1
I copy the demo files ("egl-pdemo"/"gfi-demo") to QNX OS and run it. I got the failure "gfi_group_attach() failed"
Could you please tell me what's wrong with it.
Comments:
1. I have add the VMware device to display.conf
2. I run it under without photon.
Thanks
=====================================
Chen Shunli
AVNC&IS Division
Neusoft Co., Ltd.
No.2 Xin Xiu Street. Hun Nan New District,
Shenyang 110179, PRC
Tel:+86 24 83664044
Fax:+86 24 23781242
Email:chensl@neusoft.com
Http://www.neusoft.com
=====================================
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------Chen ShunLi2010-06-09T02:29:09Zpost54916: NoneShanShan Qiaohttp://community.qnx.com/sf/go/post549162010-05-18T04:28:13Z2010-05-18T04:28:13ZShanShan Qiao2010-05-18T04:28:13Zpost54138: Re: Need some documentation on Composition Manager!Jason Mawdsleyhttp://community.qnx.com/sf/go/post541382010-05-11T01:59:07Z2010-05-11T01:59:07ZHi Chiranjeevi,
Welcome to QNX!
You can find some simple documentation here:
http://community.qnx.com/sf/wiki/do/viewPage/projects.graphics/wiki/HomePage
It will be better to post questions in the Graphics forum instead of the
GLES forum.
Thanks,
Jason
On 10-05-06 8:24 AM, "chiranjeevi kinnera" <community-noreply@qnx.com>
wrote:
> Hi all,
>
> I am a newbie to QNX, please share some documentation for io-winmgr and
> composition manager.
>
> Thanks
> Chiranjeevi
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post53659
>
>Jason Mawdsley2010-05-11T01:59:07Zpost53659: Need some documentation on Composition Manager!chiranjeevi kinnerahttp://community.qnx.com/sf/go/post536592010-05-06T12:24:17Z2010-05-06T12:24:17ZHi all,
I am a newbie to QNX, please share some documentation for io-winmgr and composition manager.
Thanks
Chiranjeevichiranjeevi kinnera2010-05-06T12:24:17Zpost50658: questions about opengl es on qnxivan chenhttp://community.qnx.com/sf/go/post506582010-03-29T06:43:23Z2010-03-29T06:43:23ZHi, All
I am new to qnx , and there are some questions about how 3d works on qnx .
1. Most of gles demo source code will create a surface which size is the same with the display, can it be resized and move around the desktop and will opengles driver track the window size and position change?
2. libGLESv1_CM.so seems to provide the gles1.0 core support, which will load libgf.so and load the corresponding 3d driver.
Current definition of 3d acceleration interface is very limited , how can I provide gles2.0 support?
I want to provid a library like libGLESv2_CM.so , but EGL seems not open source, I don't know how to interact with EGL, is there any programming guide?
Or is there any programming guide to completely replace the EGL and core lib?
Thanks!ivan chen2010-03-29T06:43:23Zpost49784: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoChristian Leutloffhttp://community.qnx.com/sf/go/post497842010-03-17T18:47:56Z2010-03-17T18:47:56ZI am interested in your modification to build Qt. How are the programs running?
Thanks
ChristianChristian Leutloff2010-03-17T18:47:56Zpost46059: Re: No GL_IMG/GL_ARB extensions found in OpenGL 1.4Marton Torokhttp://community.qnx.com/sf/go/post460592010-01-27T16:06:58Z2010-01-27T16:06:58ZHi Derek,
Thanks for the clarification, it seems we got confused on the versions, but now this fact answers all our questions.
So now the next step is to purchase the necessary libs :)
Thanks & regards,
MartonMarton Torok2010-01-27T16:06:58Zpost46022: Re: No GL_IMG/GL_ARB extensions found in OpenGL 1.4Etienne Belanger(deleted)http://community.qnx.com/sf/go/post460222010-01-27T13:26:10Z2010-01-27T13:26:10ZRight now, you are using the 'all-software' QNX OpenGL ES 1.0 driver with an EGL 1.4. When the ImgTech driver is released for OMAP3530, it will support all IMG extensions and some OES extensions. I don't think the ImgTech driver supports any ARB extension on OpenGL ES.
Note that the extensions supported vary between the OpenGL ES 1.1 and the OpenGL ES 2.0 APIs that are both supported by the ImgTech driver.
If there is an extension in particular you plan on using, we should be able to tell you if the driver will support it.Etienne Belanger(deleted)2010-01-27T13:26:10Zpost46018: RE: No GL_IMG/GL_ARB extensions found in OpenGL 1.4Derek Leachhttp://community.qnx.com/sf/go/post460182010-01-27T12:53:17Z2010-01-27T12:53:17ZHi Marton,
Maybe someone else will clarify further, but ...
It actually says:
OpenGL ES-CM 1.0
the EGL interface is indicated as 1.4
Kind Regards,
-Derek
-----Original Message-----
From: Marton Torok [mailto:community-noreply@qnx.com]
Sent: Wednesday, January 27, 2010 6:39 AM
To: opengles-graphics
Subject: No GL_IMG/GL_ARB extensions found in OpenGL 1.4
Hi All,
We have an MTP development board (OMAP3530) with QNX 6.4.1, and the
gears demo states there's OpenGL 1.4 on it.
Are the GL_IMG and GL_ARB extensions supported here (or do they exist at
all in 1.4)?
Or should we set anything to get them work?
By default, no environment variables are set (should we set any?), but
the demo runs well (without these extensions...):
# gles1-kd-gears -verbose
EGL1.4
found 1 config(s)
EGL_CONFIG_ID = 32
EGL_RED_SIZE = 5
EGL_GREEN_SIZE = 6
EGL_BLUE_SIZE = 5
EGL_ALPHA_SIZE = 0
EGL_DEPTH_SIZE = 16
EGL_LEVEL = 0
EGL_NATIVE_RENDERABLE = EGL_FALSE
EGL_NATIVE_VISUAL_TYPE = 4880
EGL_RENDERABLE_TYPE = 0x0001
EGL_SURFACE_TYPE = 0x0487
EGL_TRANSPARENT_TYPE = EGL_NONE
GL_RENDERER = Software Rasterizer
GL_VERSION = OpenGL ES-CM 1.0
GL_VENDOR = QNX Software Systems
GL_EXTENSIONS = GL_OES_compressed_paletted_texture
GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format
Thanks in advance.
Regards,
Marton
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post46011Derek Leach2010-01-27T12:53:17Zpost46011: No GL_IMG/GL_ARB extensions found in OpenGL 1.4Marton Torokhttp://community.qnx.com/sf/go/post460112010-01-27T11:38:51Z2010-01-27T11:38:51ZHi All,
We have an MTP development board (OMAP3530) with QNX 6.4.1, and the gears demo states there's OpenGL 1.4 on it.
Are the GL_IMG and GL_ARB extensions supported here (or do they exist at all in 1.4)?
Or should we set anything to get them work?
By default, no environment variables are set (should we set any?), but the demo runs well (without these extensions...):
# gles1-kd-gears -verbose
EGL1.4
found 1 config(s)
EGL_CONFIG_ID = 32
EGL_RED_SIZE = 5
EGL_GREEN_SIZE = 6
EGL_BLUE_SIZE = 5
EGL_ALPHA_SIZE = 0
EGL_DEPTH_SIZE = 16
EGL_LEVEL = 0
EGL_NATIVE_RENDERABLE = EGL_FALSE
EGL_NATIVE_VISUAL_TYPE = 4880
EGL_RENDERABLE_TYPE = 0x0001
EGL_SURFACE_TYPE = 0x0487
EGL_TRANSPARENT_TYPE = EGL_NONE
GL_RENDERER = Software Rasterizer
GL_VERSION = OpenGL ES-CM 1.0
GL_VENDOR = QNX Software Systems
GL_EXTENSIONS = GL_OES_compressed_paletted_texture GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format
Thanks in advance.
Regards,
MartonMarton Torok2010-01-27T11:38:51Zpost45379: RE: Anti-aliasing in openGLES 1.1Derek Leachhttp://community.qnx.com/sf/go/post453792010-01-18T13:07:38Z2010-01-18T13:07:38ZHi Sachin,
I do not know very much about GLES API calls, but I checked some places,
and I think you need to make some of these calls:
glEnable(GL_LINE_SMOOTH);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);
I am not sure if all are required, but it would seem to be so. Maybe
someone else will further clarify, but I think this will give you
something to try.
-----Original Message-----
From: Sachin Rastogi [mailto:community-noreply@qnx.com]
Sent: Sunday, January 17, 2010 8:02 AM
To: opengles-graphics
Subject: Anti-aliasing in openGLES 1.1
Hi,
If I want to draw an anti-alias line using openGL ES 1.1, how can I
acheive this? Is there any direct api call to support anti-alias?
Thanks
sachin
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post45364Derek Leach2010-01-18T13:07:38Zpost45364: Anti-aliasing in openGLES 1.1Sachin Rastogihttp://community.qnx.com/sf/go/post453642010-01-17T13:02:13Z2010-01-17T13:02:13ZHi,
If I want to draw an anti-alias line using openGL ES 1.1, how can I acheive this? Is there any direct api call to support anti-alias?
Thanks
sachinSachin Rastogi2010-01-17T13:02:13Zpost45117: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoIstvan Balazshttp://community.qnx.com/sf/go/post451172010-01-13T05:46:09Z2010-01-13T05:46:09ZWow, thanks, that's exactly I wanted to learn.
Unwillingly I got the same the same result by adding -DQT_GLES_EGL, which does your case 1 :)
QGL libraries built well with that, but guess there is no need than for the libGLESv1_C(M)(L) libs.
Thank you again. If anyone else is interested in the topic, I will attach the mods I made during the build if I finally succeed with it.Istvan Balazs2010-01-13T05:46:09Zpost45077: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoEtienne Belanger(deleted)http://community.qnx.com/sf/go/post450772010-01-12T17:22:17Z2010-01-12T17:22:17Z6.4.1 comes with two OpenGL ES stacks:
1) A libGLES_C[M|L].so that contains EGL functions. With this library, there is no need to link with an EGL library. The <GLES/egl.h> header is the one that should be included in this case.
2) A libGLESv1_C[M|L].so that doesn't contain any EGL functions. With this library, a separate libEGL.so, which contains the EGL functions, must be used. The <EGL/egl.h> header is the one that matches with libEGL.so.
If you are passing a gf_device_t to eglGetDisplay() somewhere, you must the EGL 1.2 functions contained in libGLES_C[M|L].so.Etienne Belanger(deleted)2010-01-12T17:22:17Zpost44995: Re: RE: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoIstvan Balazshttp://community.qnx.com/sf/go/post449952010-01-12T10:00:00Z2010-01-12T10:00:00ZThanks for your reply,
I have sen the platform notes, but since I am building as a QNX-fan , I was interested whether I can use OpenGL or not. If I fail to build it with OpenGL, I will try out the -embedded i386 option also, and check how it performs.
BRIstvan Balazs2010-01-12T10:00:00Zpost44993: RE: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoMate Szarvashttp://community.qnx.com/sf/go/post449932010-01-12T09:42:37Z2010-01-12T09:42:37ZHello Istvan
Pretty sure you have seen this but have you tried to use the config line
verbatim from this page:
http://doc.trolltech.com/4.6-snapshot/platform-notes-qnx.html
There appear to be minor differences compared to yours (presence of
-embedded option; lack of -opengl option).
Have not built this myself so I'm just suggesting the obvious..
--
Mate
-----Original Message-----
From: Istvan Balazs [mailto:community-noreply@qnx.com]
Sent: January 11, 2010 9:29 PM
To: opengles-graphics
Subject: Configuring Qt 4.6 opensource for qnx
SDP-6.4.1-200905201802-nto
Hi,
I am trying to do benchmarks for different OS-es with Qt 4.6 opensource
from Nokia. I have installed a virtual machine with
SDP-6.4.1-200905201802-nto, and tried to configure Qt for Qnx. I added
the EGL and GLES library and include paths under the supplied mkspec for
Qnx, than configured with the following command.
./configure \
-platform unsupported/qnx-g++ -no-libtiff -no-qt3support
-no-gfx-linuxfb \ -no-mouse-linuxtp -no-kbd-tty -qt-gfx-qnx
-qt-mouse-qnx -qt-kbd-qnx\ -opensource -opengl es1 -qt-libjpeg
-qt-libpng -qt-libmng -qt-gif -silent
Configure runs Ok, and than I try to :
make install
which runs ok until trying to build OpenGL libraries. Here I got an
error, whith conflicting type declarations within EGL/eglplatform.h and
GLES/egltypes.h
Honestly, I am confused, which declarations are meant for my use. Maybe
I should just try to forbid use of EGL libraries? there is an egl.h also
within the GLES folder. (guess needed for the context creation).
Have anyone succesfully managed to build Qt opensource on Qnx SDP 6.4.1?
All help is apreciated,
Istvan
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post44870Mate Szarvas2010-01-12T09:42:37Zpost44992: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoIstvan Balazshttp://community.qnx.com/sf/go/post449922010-01-12T09:24:04Z2010-01-12T09:24:04ZOk, there are no responses, but I wrote down my experience, maybe it will be useful.
I added an additional define in the mkspec , with -DQT_GLES_EGL, so Qt won't use EGL and GLES simultanously. However, the EGL and GLES egl differences are still not completely clear to me (but this is not qnx-related).
Also, there might be a bug in Qt according to http://lists.trolltech.com/pipermail/qt-embedded-interest/2009-December/000767.html.
I edited Qt's qpaintengineex_opengl2_p.h file to get rid of the shader model (which i guess not relevant for OpenGLL ES 1.1. Now the build script is still running, so no more experience, but GL libraries at least are built with Qt.
If someone have some good results with Qt on QNX I will elcome this; if not, I hope this post will help others who trying to build Qt on QNX.Istvan Balazs2010-01-12T09:24:04Zpost44870: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-ntoIstvan Balazshttp://community.qnx.com/sf/go/post448702010-01-11T12:28:59Z2010-01-11T12:28:59ZHi,
I am trying to do benchmarks for different OS-es with Qt 4.6 opensource from Nokia. I have installed a virtual machine with SDP-6.4.1-200905201802-nto, and tried to configure Qt for Qnx. I added the EGL and GLES library and include paths under the supplied mkspec for Qnx, than configured with the following command.
./configure \
-platform unsupported/qnx-g++ -no-libtiff -no-qt3support -no-gfx-linuxfb \
-no-mouse-linuxtp -no-kbd-tty -qt-gfx-qnx -qt-mouse-qnx -qt-kbd-qnx\
-opensource -opengl es1 -qt-libjpeg -qt-libpng -qt-libmng -qt-gif -silent
Configure runs Ok, and than I try to :
make install
which runs ok until trying to build OpenGL libraries. Here I got an error, whith
conflicting type declarations within EGL/eglplatform.h and GLES/egltypes.h
Honestly, I am confused, which declarations are meant for my use. Maybe I should just try to forbid use of EGL libraries? there is an egl.h also within the GLES folder. (guess needed for the context creation).
Have anyone succesfully managed to build Qt opensource on Qnx SDP 6.4.1?
All help is apreciated,
IstvanIstvan Balazs2010-01-11T12:28:59Zpost43147: Re: io-display pends on a mutex indefinitelyMario Mastrodicasahttp://community.qnx.com/sf/go/post431472009-12-03T21:22:07Z2009-12-03T21:22:07ZAttached the dump of io-display during stalling.
> Attached the new screenshot. I have omitted the first thread because it is
> simply waiting for SIGTERM.
> The others are waiting for work to be done rather than the third that want to
> serve the request from my process.
>
> Here the output of pidin. My process is 303137.
>
>
> pid tid name prio STATE Blocked
> 1 1 boot/procnto-instr 0f READY
> 1 2 boot/procnto-instr 255r RECEIVE 1
> 1 3 boot/procnto-instr 255r RECEIVE 1
> 1 4 boot/procnto-instr 10r RUNNING
> 1 5 boot/procnto-instr 255r RECEIVE 1
> 1 6 boot/procnto-instr 10r RECEIVE 1
> 1 7 boot/procnto-instr 10r RECEIVE 1
> 1 8 boot/procnto-instr 10r RECEIVE 1
> 1 9 boot/procnto-instr 10r RECEIVE 1
> 1 15 boot/procnto-instr 10r RECEIVE 1
> 1 16 boot/procnto-instr 10r RECEIVE 1
> 1 18 boot/procnto-instr 10r RECEIVE 1
> 2 1 sbin/tinit 10o REPLY 1
> 4099 1 proc/boot/pci-bios 10o RECEIVE 1
> 4100 1 proc/boot/slogger 10o RECEIVE 1
> 4101 1 proc/boot/io-usb 10o SIGWAITINFO
> 4101 2 proc/boot/io-usb 21r RECEIVE 4
> 4101 3 proc/boot/io-usb 21r RECEIVE 7
> 4101 4 proc/boot/io-usb 21r RECEIVE 1
> 4101 5 proc/boot/io-usb 10o RECEIVE 10
> 4101 6 proc/boot/io-usb 10r NANOSLEEP
> 4101 7 proc/boot/io-usb 10o RECEIVE 10
> 4102 1 proc/boot/io-hid 10o SIGWAITINFO
> 4102 2 proc/boot/io-hid 21r RECEIVE 1
> 4102 3 proc/boot/io-hid 10o RECEIVE 4
> 4102 4 proc/boot/io-hid 15r RECEIVE 12
> 4102 5 proc/boot/io-hid 10r REPLY 4101
> 4102 6 proc/boot/io-hid 10o RECEIVE 4
> 4102 7 proc/boot/io-hid 9r RECEIVE 16
> 4103 1 /boot/devc-con-hid 10o RECEIVE 1
> 4103 2 /boot/devc-con-hid 10o REPLY 4102
> 8200 1 roc/boot/devb-eide 10o SIGWAITINFO
> 8200 2 roc/boot/devb-eide 21r RECEIVE 1
> 8200 3 roc/boot/devb-eide 21r RECEIVE 4
> 8200 4 roc/boot/devb-eide 10o RECEIVE 10
> 8200 6 roc/boot/devb-eide 10o RECEIVE 7
> 8200 9 roc/boot/devb-eide 10o RECEIVE 7
> 8200 11 roc/boot/devb-eide 10o RECEIVE 7
> 8200 12 roc/boot/devb-eide 10o RECEIVE 7
> 8200 14 roc/boot/devb-eide 10o RECEIVE 7
> 20489 1 sbin/pipe 10o SIGWAITINFO
> 20489 2 sbin/pipe 10o RECEIVE 1
> 20489 3 sbin/pipe 10o RECEIVE 1
> 20489 4 sbin/pipe 10o RECEIVE 1
> 20489 5 sbin/pipe 10o RECEIVE 1
> 24586 1 sbin/mqueue 10o RECEIVE 1
> 61451 1 usr/sbin/mcd 10o RECEIVE 1
> 61451 2 usr/sbin/mcd 10o NANOSLEEP
> 61451 3 usr/sbin/mcd 10o SIGWAITINFO
> 61451 4 usr/sbin/mcd 9o NANOSLEEP
> 61451 5 usr/sbin/mcd 10o SIGWAITINFO
> 61451 6 usr/sbin/mcd 10o SIGWAITINFO
> 61451 7 usr/sbin/mcd 10o SIGWAITINFO
> 65548 1 usr/sbin/random 10o SIGWAITINFO
> 65548 2 usr/sbin/random 10o RECEIVE 1
> 65548 3 usr/sbin/random 10o NANOSLEEP
> 69645 1 sbin/enum-devices 10o REPLY 20489
> 86032 1 sbin/enum-usb 10o SIGWAITINFO
> 86032 2 sbin/enum-usb 10r REPLY 4101
> 98319 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO
> 98319 2 sbin/io-pkt-v4-hc 21o RECEIVE 1
> 98319 3 sbin/io-pkt-v4-hc 21r RECEIVE 16
> 118802 1 sbin/io-display 10o SIGWAITINFO
> 118802 2 sbin/io-display 10o RECEIVE 1
> 118802 3 sbin/io-display 10o MUTEX (0x40100000) 118802-01 #1
> 118802 4 sbin/io-display 10o RECEIVE 3
> 118802 5 sbin/io-display 10o RECEIVE 1
> 131092 1 r/sbin/dhcp.client 10o NANOSLEEP
> 139286 1 sbin/io-audio 10o SIGWAITINFO
> 139286 2 sbin/io-audio 10o RECEIVE 1
> 139286 3 sbin/io-audio 10o RECEIVE 1
> 139286 4 sbin/io-audio 10o RECEIVE 1
> 139286 5 sbin/io-audio 50r INTR
> 139286 6 sbin/io-audio 50r RECEIVE 7
> 176142 1 sbin/devc-ser8250 10o RECEIVE 1
> 176149 1 sbin/devb-fdc 10o SIGWAITINFO
> 184337 1 sbin/devc-pty 20o RECEIVE 1
> 196627 1 usr/sbin/dumper 10o RECEIVE 1
> 200727 1 usr/sbin/qconn 10o SIGWAITINFO
> 200727 2 usr/sbin/qconn 10o CONDVAR (0x8067df0)
> 200727 3 usr/sbin/qconn 10o RECEIVE 1
> 200727 4 usr/sbin/qconn 10o RECEIVE 3
> 200730 2 usr/sbin/fs-cifs 10o RECEIVE 1
> 200730 3 usr/sbin/fs-cifs 10o RECEIVE 1
> 200731 2 usr/sbin/fs-cifs 10o RECEIVE 1
> 200731 3 usr/sbin/fs-cifs 10o RECEIVE 1
> 200732 1 usr/sbin/fs-cifs 10o RECEIVE 1
> 200732 2 usr/sbin/fs-cifs 10o RECEIVE 1
> 200732 3 usr/sbin/fs-cifs 10o RECEIVE 1
> 200732 4 usr/sbin/fs-cifs 10o RECEIVE 1
> 221213 1 usr/sbin/inetd 10o SIGWAITINFO
> 237592 1 bin/sh 10o REPLY 4103
> 237593 1 bin/login 10o REPLY 4103
> 237598 1 bin/login 10o REPLY 4103
> 237599 1 bin/login 10o REPLY 4103
> 274464 1 hoton/bin/devi-hid 10o RECEIVE 1
> 274464 2 hoton/bin/devi-hid 10o REPLY 4102
> 274464 3 hoton/bin/devi-hid 12o SIGWAITINFO
> 274464 5 hoton/bin/devi-hid 10o RECEIVE 4
> 274464 6 hoton/bin/devi-hid 10o RECEIVE 4
> 303137 1 ario12592491159982 10r REPLY 118802
> 303139 1 usr/bin/pdebug 10o SIGWAITINFO
> 315426 1 usr/sbin/telnetd 10o SIGWAITINFO
> 319525 1 bin/sh 10o SIGSUSPEND
> 376870 1 usr/bin/pdebug 10o REPLY 98319
> 380964 1 bin/pidin 10o REPLY 1Mario Mastrodicasa2009-12-03T21:22:07Zpost42679: Re: io-display pends on a mutex indefinitelyMario Mastrodicasahttp://community.qnx.com/sf/go/post426792009-11-26T16:10:58Z2009-11-26T16:10:58ZAttached the new screenshot. I have omitted the first thread because it is simply waiting for SIGTERM.
The others are waiting for work to be done rather than the third that want to serve the request from my process.
Here the output of pidin. My process is 303137.
pid tid name prio STATE Blocked
1 1 boot/procnto-instr 0f READY
1 2 boot/procnto-instr 255r RECEIVE 1
1 3 boot/procnto-instr 255r RECEIVE 1
1 4 boot/procnto-instr 10r RUNNING
1 5 boot/procnto-instr 255r RECEIVE 1
1 6 boot/procnto-instr 10r RECEIVE 1
1 7 boot/procnto-instr 10r RECEIVE 1
1 8 boot/procnto-instr 10r RECEIVE 1
1 9 boot/procnto-instr 10r RECEIVE 1
1 15 boot/procnto-instr 10r RECEIVE 1
1 16 boot/procnto-instr 10r RECEIVE 1
1 18 boot/procnto-instr 10r RECEIVE 1
2 1 sbin/tinit 10o REPLY 1
4099 1 proc/boot/pci-bios 10o RECEIVE 1
4100 1 proc/boot/slogger 10o RECEIVE 1
4101 1 proc/boot/io-usb 10o SIGWAITINFO
4101 2 proc/boot/io-usb 21r RECEIVE 4
4101 3 proc/boot/io-usb 21r RECEIVE 7
4101 4 proc/boot/io-usb 21r RECEIVE 1
4101 5 proc/boot/io-usb 10o RECEIVE 10
4101 6 proc/boot/io-usb 10r NANOSLEEP
4101 7 proc/boot/io-usb 10o RECEIVE 10
4102 1 proc/boot/io-hid 10o SIGWAITINFO
4102 2 proc/boot/io-hid 21r RECEIVE 1
4102 3 proc/boot/io-hid 10o RECEIVE 4
4102 4 proc/boot/io-hid 15r RECEIVE 12
4102 5 proc/boot/io-hid 10r REPLY 4101
4102 6 proc/boot/io-hid 10o RECEIVE 4
4102 7 proc/boot/io-hid 9r RECEIVE 16
4103 1 /boot/devc-con-hid 10o RECEIVE 1
4103 2 /boot/devc-con-hid 10o REPLY 4102
8200 1 roc/boot/devb-eide 10o SIGWAITINFO
8200 2 roc/boot/devb-eide 21r RECEIVE 1
8200 3 roc/boot/devb-eide 21r RECEIVE 4
8200 4 roc/boot/devb-eide 10o RECEIVE 10
8200 6 roc/boot/devb-eide 10o RECEIVE 7
8200 9 roc/boot/devb-eide 10o RECEIVE 7
8200 11 roc/boot/devb-eide 10o RECEIVE 7
8200 12 roc/boot/devb-eide 10o RECEIVE 7
8200 14 roc/boot/devb-eide 10o RECEIVE 7
20489 1 sbin/pipe 10o SIGWAITINFO
20489 2 sbin/pipe 10o RECEIVE 1
20489 3 sbin/pipe 10o RECEIVE 1
20489 4 sbin/pipe 10o RECEIVE 1
20489 5 sbin/pipe 10o RECEIVE 1
24586 1 sbin/mqueue 10o RECEIVE 1
61451 1 usr/sbin/mcd 10o RECEIVE 1
61451 2 usr/sbin/mcd 10o NANOSLEEP
61451 3 usr/sbin/mcd 10o SIGWAITINFO
61451 4 usr/sbin/mcd 9o NANOSLEEP
61451 5 usr/sbin/mcd 10o SIGWAITINFO
61451 6 usr/sbin/mcd 10o SIGWAITINFO
61451 7 usr/sbin/mcd 10o SIGWAITINFO
65548 1 usr/sbin/random 10o SIGWAITINFO
65548 2 usr/sbin/random 10o RECEIVE 1
65548 3 usr/sbin/random 10o NANOSLEEP
69645 1 sbin/enum-devices 10o REPLY 20489
86032 1 sbin/enum-usb 10o SIGWAITINFO
86032 2 sbin/enum-usb 10r REPLY 4101
98319 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO
98319 2 sbin/io-pkt-v4-hc 21o RECEIVE 1
98319 3 sbin/io-pkt-v4-hc 21r RECEIVE 16
118802 1 sbin/io-display 10o SIGWAITINFO
118802 2 sbin/io-display 10o RECEIVE 1
118802 3 sbin/io-display 10o MUTEX (0x40100000) 118802-01 #1
118802 4 sbin/io-display 10o RECEIVE 3
118802 5 sbin/io-display 10o RECEIVE 1
131092 1 r/sbin/dhcp.client 10o NANOSLEEP
139286 1 sbin/io-audio 10o SIGWAITINFO
139286 2 sbin/io-audio 10o RECEIVE 1
139286 3 sbin/io-audio 10o RECEIVE 1
139286 4 sbin/io-audio 10o RECEIVE 1
139286 5 sbin/io-audio 50r INTR
139286 6 sbin/io-audio 50r RECEIVE 7
176142 1 sbin/devc-ser8250 10o RECEIVE 1
176149 1 sbin/devb-fdc 10o SIGWAITINFO
184337 1 sbin/devc-pty 20o RECEIVE 1
196627 1 usr/sbin/dumper 10o RECEIVE 1
200727 1 usr/sbin/qconn 10o SIGWAITINFO
200727 2 usr/sbin/qconn 10o CONDVAR (0x8067df0)
200727 3 usr/sbin/qconn 10o RECEIVE 1
200727 4 usr/sbin/qconn 10o RECEIVE 3
200730 2 usr/sbin/fs-cifs 10o RECEIVE 1
200730 3 usr/sbin/fs-cifs 10o RECEIVE 1
200731 2 usr/sbin/fs-cifs 10o RECEIVE 1
200731 3 usr/sbin/fs-cifs 10o RECEIVE 1
200732 1 usr/sbin/fs-cifs 10o RECEIVE 1
200732 2 usr/sbin/fs-cifs 10o RECEIVE 1
200732 3 usr/sbin/fs-cifs 10o RECEIVE 1
200732 4 usr/sbin/fs-cifs 10o RECEIVE 1
221213 1 usr/sbin/inetd 10o SIGWAITINFO
237592 1 bin/sh 10o REPLY 4103
237593 1 bin/login 10o REPLY 4103
237598 1 bin/login 10o REPLY 4103
237599 1 bin/login 10o REPLY 4103
274464 1 hoton/bin/devi-hid 10o RECEIVE 1
274464 2 hoton/bin/devi-hid 10o REPLY 4102
274464 3 hoton/bin/devi-hid 12o SIGWAITINFO
274464 5 hoton/bin/devi-hid 10o RECEIVE 4
274464 6 hoton/bin/devi-hid 10o RECEIVE 4
303137 1 ario12592491159982 10r REPLY 118802
303139 1 usr/bin/pdebug 10o SIGWAITINFO
315426 1 usr/sbin/telnetd 10o SIGWAITINFO
319525 1 bin/sh 10o SIGSUSPEND
376870 1 usr/bin/pdebug 10o REPLY 98319
380964 1 bin/pidin 10o REPLY 1Mario Mastrodicasa2009-11-26T16:10:58Zpost42662: Re: io-display pends on a mutex indefinitelyColin Burgess(deleted)http://community.qnx.com/sf/go/post426622009-11-26T14:46:56Z2009-11-26T14:46:56ZThe __count is 0x80000001, and the owner is 0xb0200001, which looks perfectly normal.
Looks like thread 1 (I assume of the same process) has the process locked.
If you post the backtrace of thread1 then the graphics guys will likely be able to tell
you the cause. You should also post the output of pidin
Mario Mastrodicasa wrote:
> I'm using SDP 6.4.1 on a vmware box.
> I have a strange issue when I try to use OpenGL.
> The code creates in sequence:
> - 2 surfaces capable of 3D operations (flag GF_SURFACE_CREATE_3D_ACCESSIBLE)
> - from the previous surfaces creates a 3d target surface
> - then use it as native for EGL
> - after the code try to create a surface for offscreen drawing (offscreen framebuffer) but at this point my code wait indefinitely on a reply from io-display.
>
> Looking on io-display I can see that one thread is waiting to lock a mutex. Seems that this mutex wasn't unlocked on the last AGF operation. Using the symbols and looking deeper in the mutex is possible to see that the values are very strange, like an uninitialized mutex.
> As attachment I send the screen shot of the "injured" thread call stack.
>
> Thanks,
> Mario.
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post42622
>
>
> ------------------------------------------------------------------------
>
--
cburgess@qnx.comColin Burgess(deleted)2009-11-26T14:46:56Zpost42622: io-display pends on a mutex indefinitelyMario Mastrodicasahttp://community.qnx.com/sf/go/post426222009-11-26T09:03:24Z2009-11-26T09:03:24ZI'm using SDP 6.4.1 on a vmware box.
I have a strange issue when I try to use OpenGL.
The code creates in sequence:
- 2 surfaces capable of 3D operations (flag GF_SURFACE_CREATE_3D_ACCESSIBLE)
- from the previous surfaces creates a 3d target surface
- then use it as native for EGL
- after the code try to create a surface for offscreen drawing (offscreen framebuffer) but at this point my code wait indefinitely on a reply from io-display.
Looking on io-display I can see that one thread is waiting to lock a mutex. Seems that this mutex wasn't unlocked on the last AGF operation. Using the symbols and looking deeper in the mutex is possible to see that the values are very strange, like an uninitialized mutex.
As attachment I send the screen shot of the "injured" thread call stack.
Thanks,
Mario.Mario Mastrodicasa2009-11-26T09:03:24Zpost40598: RE: RE: RE: RE: RE: New with QNX OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post405982009-10-23T12:23:09Z2009-10-23T12:23:09ZI would hope they would all work, no matter the driver, using soft3d if
necessary ... but if you can narrow down the root cause/differences,
please post it back here ...
-----Original Message-----
From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
Sent: Thursday, October 22, 2009 8:00 PM
To: opengles-graphics
Subject: Re: RE: RE: RE: RE: New with QNX OpenGL ES
There were 3 demos at this location. I downloaded them all and here is
what I have to report:
Radian Mode
All Three work properly
Vesa.Bios Mode
Only the "Demo" one worked properly, the other two _2d and _3d get
the message I posted previously.
VGA Mode
Only the "Demo" one worked at all. I had to put the screen into
800x600 mode to get into VGA mode, and the program didn't work very
well, but no need to follow up on this in my opinion. The other two
got the same error message about the off screen context.
So, apparently software Open GL can work in Vesa.Bios mode. I'll have
to dig into that "demo" program to see what is different about it.
Thanks,
Mitchell
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post40572Derek Leach2009-10-23T12:23:09Zpost40597: RE: RE: RE: RE: New with QNX OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post405972009-10-23T12:21:45Z2009-10-23T12:21:45Zfrom the source repository under this project.
-----Original Message-----
From: Praveen VS [mailto:community-noreply@qnx.com]
Sent: Thursday, October 22, 2009 11:26 PM
To: opengles-graphics
Subject: Re: RE: RE: RE: New with QNX OpenGL ES
Where can we get the source for no photon version of gears, gf 2d vsync
etc...
Regards
Praveen
----- Original Message -----
From: "Derek Leach" <community-noreply@qnx.com>
To: "opengles-graphics" <post40544@community.qnx.com>
Sent: Friday, October 23, 2009 2:16 AM
Subject: RE: RE: RE: RE: New with QNX OpenGL ES
>
http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.pho
ton.
> gf_ph_2d
>
> -----Original Message-----
> From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
> Sent: Thursday, October 22, 2009 11:31 AM
> To: opengles-graphics
> Subject: Re: RE: RE: RE: New with QNX OpenGL ES
>
> Well the name of the program is gf-ph-3d and it came with source and
PhAB
> development files. I don't really know where I first obtained it.
Can
> you point me at a link to the version you are using? I will download
and
> re-test.
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post40504
>
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post40544
>
>
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post40580Derek Leach2009-10-23T12:21:45Zpost40580: Re: RE: RE: RE: New with QNX OpenGL ESPraveen VShttp://community.qnx.com/sf/go/post405802009-10-23T03:26:07Z2009-10-23T03:26:07ZWhere can we get the source for no photon version of gears, gf 2d vsync
etc...
Regards
Praveen
----- Original Message -----
From: "Derek Leach" <community-noreply@qnx.com>
To: "opengles-graphics" <post40544@community.qnx.com>
Sent: Friday, October 23, 2009 2:16 AM
Subject: RE: RE: RE: RE: New with QNX OpenGL ES
> http://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.photon.
> gf_ph_2d
>
> -----Original Message-----
> From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
> Sent: Thursday, October 22, 2009 11:31 AM
> To: opengles-graphics
> Subject: Re: RE: RE: RE: New with QNX OpenGL ES
>
> Well the name of the program is gf-ph-3d and it came with source and PhAB
> development files. I don't really know where I first obtained it. Can
> you point me at a link to the version you are using? I will download and
> re-test.
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post40504
>
>
>
>
> _______________________________________________
>
> OpenGL ES
> http://community.qnx.com/sf/go/post40544
>
>Praveen VS2009-10-23T03:26:07Zpost40572: Re: RE: RE: RE: RE: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post405722009-10-22T23:59:30Z2009-10-22T23:59:30ZThere were 3 demos at this location. I downloaded them all and here is what I have to report:
Radian Mode
All Three work properly
Vesa.Bios Mode
Only the "Demo" one worked properly, the other two _2d and _3d get the message I posted previously.
VGA Mode
Only the "Demo" one worked at all. I had to put the screen into 800x600 mode to get into VGA mode, and the program didn't work very well, but no need to follow up on this in my opinion. The other two got the same error message about the off screen context.
So, apparently software Open GL can work in Vesa.Bios mode. I'll have to dig into that "demo" program to see what is different about it.
Thanks,
MitchellMitchell Schoenbrun2009-10-22T23:59:30Zpost40544: RE: RE: RE: RE: New with QNX OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post405442009-10-22T20:46:43Z2009-10-22T20:46:43Zhttp://community.qnx.com/sf/frs/do/viewRelease/projects.graphics/frs.photon.
gf_ph_2d
-----Original Message-----
From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
Sent: Thursday, October 22, 2009 11:31 AM
To: opengles-graphics
Subject: Re: RE: RE: RE: New with QNX OpenGL ES
Well the name of the program is gf-ph-3d and it came with source and PhAB
development files. I don't really know where I first obtained it. Can
you point me at a link to the version you are using? I will download and
re-test.
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post40504Derek Leach2009-10-22T20:46:43Zpost40504: Re: RE: RE: RE: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post405042009-10-22T15:30:43Z2009-10-22T15:30:43ZWell the name of the program is gf-ph-3d and it came with source and PhAB development files. I don't really know where I first obtained it. Can you point me at a link to the version you are using? I will download and re-test.Mitchell Schoenbrun2009-10-22T15:30:43Zpost40489: RE: RE: RE: New with QNX OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post404892009-10-22T13:02:40Z2009-10-22T13:02:40ZHi Mitchell,
Just to clarify, what code is being used here?
I have a Radeon (actually 2), and I have run the gf-ph-3d demo from
foundry without issue, using devg-radeon.so and devg-vesabios.so (on one
of the cards, the other crashed, but that's another story).
From the statement, PdCreateOffscreenContextGF() below, I assume this is
a GLES and Photon hybrid application.
-Derek
-----Original Message-----
From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
Sent: Wednesday, October 21, 2009 9:11 PM
To: opengles-graphics
Subject: Re: RE: RE: New with QNX OpenGL ES
Ok, I experimented with the original "Gears" program and this is the
error message I got when I'm not using the Radeon driver, but rather the
Vesabios driver.
PdCreateOffscreenContextGFC() failed.
I'm guessing that this is not technically an OpenGL problem, but rather
an OS environment problem. I'm also guessing that the solution is to
just not use an off screen context because the vesabios doesn't support
it?
Is that right?
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post40473Derek Leach2009-10-22T13:02:40Zpost40473: Re: RE: RE: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post404732009-10-22T01:11:12Z2009-10-22T01:11:12ZOk, I experimented with the original "Gears" program and this is the error message I got when I'm not using the Radeon driver, but rather the Vesabios driver.
PdCreateOffscreenContextGFC() failed.
I'm guessing that this is not technically an OpenGL problem, but rather an OS environment problem. I'm also guessing that the solution is to just not use an off screen context because the vesabios doesn't support it?
Is that right?Mitchell Schoenbrun2009-10-22T01:11:12Zpost40444: RE: RE: New with QNX OpenGL ESMichael Van Reenenhttp://community.qnx.com/sf/go/post404442009-10-21T16:34:44Z2009-10-21T16:34:44ZI can understand your concern as you're not the first to raise the issue
of having a plug-in card available. Unfortunately with the rising
complexity of graphics devices its not as easy as it used to be to add
this support but we'll take this under consideration.
-----Original Message-----
From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
Sent: October 19, 2009 11:38 AM
To: opengles-graphics
Subject: Re: RE: New with QNX OpenGL ES
> We do have GLES 1.0 acceleration for the Intel Extreme2 chipsets
(Intel 85x) and the Intel GMA915/945GM (with devg-gma9xx.so) but these
are embedded on the motherboard - not add-on cards so I'm not sure if
this helps you.
>
Well, I can only repeat my previous shagrin. Not every embedded system
runs on a special embedded board. It would be nice if there was
even just one plug in board supported. Maybe that will come down the
line. If I knew what was involved, I might be interested the
project. Is it hard getting the hardware specs to do this out of a
hardware manufacturer these days? I've heard NVidia is close lipped,
but maybe there is someone else more open?
> The output below does confirm that the software 3D is being used.
>
> As far as the appliation running with the Radeon driver but not VESA
or SVGA - do you get any kind of error message when starting the
application with these drivers? Are you running at a
resolution/refresh rate that the BIOS supports?
I'll be the first to admit that I don't really undestand the EGL
startup code so maybe that is the problem. I used the "Gears" demo
program as a starting point.
Yes there is an error message, some code that calls an EGL routine and
burps I believe. I'm not in my office now, but within a few days
I'll get back to you on that error message.
Thanks,
Mitchell
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post40239Michael Van Reenen2009-10-21T16:34:44Zpost40239: Re: RE: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post402392009-10-19T15:37:43Z2009-10-19T15:37:43Z> We do have GLES 1.0 acceleration for the Intel Extreme2 chipsets (Intel 85x) and the Intel GMA915/945GM (with devg-gma9xx.so) but these are embedded on the motherboard - not add-on cards so I'm not sure if this helps you.
>
Well, I can only repeat my previous shagrin. Not every embedded system
runs on a special embedded board. It would be nice if there was
even just one plug in board supported. Maybe that will come down the
line. If I knew what was involved, I might be interested the
project. Is it hard getting the hardware specs to do this out of a
hardware manufacturer these days? I've heard NVidia is close lipped,
but maybe there is someone else more open?
> The output below does confirm that the software 3D is being used.
>
> As far as the appliation running with the Radeon driver but not VESA or SVGA - do you get any kind of error message when starting the application with these drivers? Are you running at a resolution/refresh rate that the BIOS supports?
I'll be the first to admit that I don't really undestand the EGL
startup code so maybe that is the problem. I used the "Gears" demo program as a starting point.
Yes there is an error message, some code that calls an EGL routine and
burps I believe. I'm not in my office now, but within a few days
I'll get back to you on that error message.
Thanks,
MitchellMitchell Schoenbrun2009-10-19T15:37:43Zpost40207: Re: RE: New with QNX OpenGL ESMichael Van Reenenhttp://community.qnx.com/sf/go/post402072009-10-19T12:31:17Z2009-10-19T12:31:17ZSorry for the delay on this response - although I'm monitoring the forum I didn't get an update.
We do have GLES 1.0 acceleration for the Intel Extreme2 chipsets (Intel 85x) and the Intel GMA915/945GM (with devg-gma9xx.so) but these are embedded on the motherboard - not add-on cards so I'm not sure if this helps you.
The output below does confirm that the software 3D is being used.
As far as the appliation running with the Radeon driver but not VESA or SVGA - do you get any kind of error message when starting the application with these drivers? Are you running at a resolution/refresh rate that the BIOS supports?
Re: RE: New with QNX OpenGL ES
>
> Unfortunately not anything current at the moment. Our focus has been
> primarily on more embedded chipsets.
Ummm, what can I say? Not even one? Well I understand QNX's focus is on the embedded market, but even with that in
mind, there are customers who might want a card solution. The customer I'm working with sells a large medical device
with two embedded computers running QNX and they would need some kind of card, PCI, AGP, or PCI-Express to provide
hardware acceleration. There's no need to be concerned about them at the moment as the software powered openGL seems
to be fast enough for our current application, just something to think about.
BTW, there's posted something about an Intel Extreme something or other? Is this a motherboard hardware openGL
supported in it?
>
> When running a GLES app on the 9250 with 6.4.1 can you send the output
> of pidin mem?
>
Absolutely. See Below.
Just out of curiosity though, I've noticed that my openGL ES photon application on 6.4.1 does not work if I set the
driver to VESA or VGA. That sounds odd since there appears to be no hardware acceleration. Could the problem be in
my EGL setup? Just wondering.
The openGL application is called displayph8. I hope this is useful to you.
Mitchell
pid tid name prio STATE code data stack
1 1 /procnto-smp-instr 0f READY 503K 2708K 320(320)*
1 2 /procnto-smp-instr 0f READY 503K 2708K 320(320)*
1 3 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 4 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 5 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 6 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 8 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 9 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 10 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 12 /procnto-smp-instr 10r RUNNING 503K 2708K 8192(8192)
1 15 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 17 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 18 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
2 1 sbin/tinit 10o REPLY 8192 112K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4099 1 proc/boot/pci-bios 10o RECEIVE 60K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4100 1 proc/boot/slogger 10o RECEIVE 12K 172K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4101 1 proc/boot/io-usb 10o SIGWAITINFO 84K 256K 8192(516K)*
4101 2 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 3 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 4 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 5 proc/boot/io-usb 10o RECEIVE 84K 256K 4096(20K)
4101 6 proc/boot/io-usb 10r NANOSLEEP 84K 256K 4096(20K)
4101 7 proc/boot/io-usb 10o RECEIVE 84K 256K 4096(20K)
libc.so.3 @b0300000 468K 12K
devu-uhci.so @b8200000 24K 4096
devu-ohci.so @b8207000 24K 4096
devu-ehci.so @b820e000 32K 4096
4102 1 proc/boot/io-hid 10o SIGWAITINFO 28K 112K 8192(516K)*
4102 2 proc/boot/io-hid 21r RECEIVE 28K 112K 4096(12K)
4102 3 proc/boot/io-hid 15r RECEIVE 28K 112K 4096(12K)
4102 4 proc/boot/io-hid 10o RECEIVE 28K 112K 4096(20K)
4102 5 proc/boot/io-hid 10r REPLY 28K 112K 4096(20K)
4102 6 proc/boot/io-hid 10o RECEIVE 28K 112K 8192(20K)
4102 7 proc/boot/io-hid 15r RECEIVE 28K 112K 4096(12K)
libc.so.3 @b0300000 468K 12K
libhiddi.so.1 @b8200000 24K 4096
devh-ps2ser.so @b8207000 48K 8192
devh-usb.so @b8215000 16K 4096
libusbdi.so.2 @b821a000 40K 8192
4103 1 /boot/devc-con-hid 20o RECEIVE 100K 144K 8192(516K)*
4103 2 /boot/devc-con-hid 10o REPLY 100K 144K 4096(20K)
libc.so.3 @b0300000 468K 12K
/dev/mem @40100000 ( 0) 4096
/dev/mem @40101000 ( b8000) 32K
8200 1 roc/boot/devb-eide 10o SIGWAITINFO 88K 41M 8192(516K)*
8200 2 roc/boot/devb-eide 21r RECEIVE 88K 41M 4096(20K)
8200 3 roc/boot/devb-eide 21r RECEIVE 88K 41M 4096(20K)
8200 4 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 5 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 6 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 8 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 9 roc/boot/devb-eide 21o RECEIVE 88K 41M 20K(24K)
8200 13 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
libc.so.3 @b0300000 468K 12K
libcam.so.2 @b8200000 64K 8192
io-blk.so @b8212000 140K 8192
cam-disk.so @b8237000 8192 4096
cam-cdrom.so @b823a000 16K 4096
fs-udf.so @b823f000 64K 8192
fs-qnx6.so @b8251000 64K 4096
20489 1 sbin/pipe 10o SIGWAITINFO 16K 112K 4096(516K)*
20489 2 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 3 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 4 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 5 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
libc.so.3 @b0300000 468K 12K
24586 1 sbin/mqueue 10o RECEIVE 12K 112K 8192(516K)*
libc.so.3 @b0300000 468K 12K
53259 1 usr/sbin/mcd 10o RECEIVE 32K 112K 8192(516K)*
53259 2 usr/sbin/mcd 10o NANOSLEEP 32K 112K 8192(20K)
53259 3 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 4 usr/sbin/mcd 9o NANOSLEEP 32K 112K 8192(20K)
53259 5 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 6 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 7 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
libc.so.3 @b0300000 468K 12K
57356 1 usr/sbin/random 10o SIGWAITINFO 24K 368K 8192(516K)*
57356 2 usr/sbin/random 10o RECEIVE 24K 368K 8192(132K)
57356 3 usr/sbin/random 10o NANOSLEEP 24K 368K 4096(132K)
libc.so.3 @b0300000 468K 12K
libm.so.2 @b8200000 184K 20K
libz.so.2 @b8233000 48K 8192
61453 1 sbin/enum-devices 10o REPLY 28K 176K 8192(516K)*
libc.so.3 @b0300000 468K 12K
77840 1 sbin/enum-usb 10o SIGWAITINFO 16K 112K 8192(516K)*
77840 2 sbin/enum-usb 10r REPLY 16K 112K 4096(20K)
libc.so.3 @b0300000 468K 12K
libusbdi.so.2 @b8200000 40K 8192
94222 1 sbin/devc-ser8250 24o RECEIVE 64K 140K 8192(516K)*
libc.so.3 @b0300000 468K 12K
94226 1 sbin/devc-par 10o RECEIVE 60K 144K 8192(516K)*
94226 2 sbin/devc-par 9r CONDVAR 60K 144K 4096(132K)
libc.so.3 @b0300000 468K 12K
98324 1 sbin/io-display 10o SIGWAITINFO 44K 244K 8192(516K)*
98324 2 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 3 sbin/io-display 12o RECEIVE 44K 244K 8192(132K)
98324 4 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 5 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 6 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
libc.so.3 @b0300000 468K 12K
devg-radeon.so @b8200000 80K 8192
libm.so.2 @b8216000 184K 20K
libffb.so.2 @b8249000 68K 4096
em/ctl-1002,5960,0 @40100000 ( 0) 4096
/dev/mem @40101000 (dfef0000) 16K
/dev/mem @40400000 ( 0) 128M
114709 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO 868K 544K 8192(516K)*
114709 2 sbin/io-pkt-v4-hc 21o RECEIVE 868K 544K 8192(132K)
114709 3 sbin/io-pkt-v4-hc 10r RECEIVE 868K 544K 4096(132K)
libc.so.3 @b0300000 468K 12K
devnp-shim.so @b8200000 28K 8192
devn-tulip.so @b8209000 68K 8192
147471 1 sbin/devb-fdc 10o SIGWAITINFO 24K 244K 8192(516K)*
147471 2 sbin/devb-fdc 21r RECEIVE 24K 244K 4096(12K)
147471 3 sbin/devb-fdc 10o RECEIVE 24K 244K 20K(24K)
147471 4 sbin/devb-fdc 21o RECEIVE 24K 244K 20K(24K)
147471 5 sbin/devb-fdc 10o RECEIVE 24K 244K 20K(24K)
147471 6 sbin/devb-fdc 21o RECEIVE 24K 244K 20K(24K)
libc.so.3 @b0300000 468K 12K
libcam.so.2 @b8200000 64K 8192
io-blk.so @b8212000 140K 8192
cam-disk.so @b8237000 8192 4096
147473 1 sbin/devc-pty 20o RECEIVE 60K 336K 8192(516K)*
libc.so.3 @b0300000 468K 12K
163859 1 usr/sbin/dumper 10o RECEIVE 56K 180K 36K(516K)*
libc.so.3 @b0300000 468K 12K
180246 1 bin/sh 10o REPLY 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180247 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180248 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180249 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
237595 1 /photon/bin/Photon 10r RUNNING 72K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
258076 1 on/bin/io-graphics 12r CONDVAR 80K 5000K 12K(516K)*
258076 2 on/bin/io-graphics 10r RECEIVE 80K 5000K 8192(516K)
258076 3 on/bin/io-graphics 12r REPLY 80K 5000K 8192(132K)
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libph.so.3 @b8215000 1052K 36K
libfont.so.1 @b8325000 28K 4096
libphrender.so.2 @b832d000 232K 8192
phfont.so @b8369000 92K 12K
FCcore.so @b8383000 36K 4096
libblkcache.so.2 @b838d000 12K 4096
libFF-T2K-fm.so.1 @b8391000 12K 4096
bFF-T2K-cache.so.2 @b8395000 8192 4096
libFF-T2K.so.2 @b8398000 280K 12K
PHFcore.so @b83e1000 24K 8192
libfontutils.so.1 @b83e9000 4096 4096
ttfFFcore.so @b83eb000 36K 8192
devg-radeon.so @b83f6000 80K 8192
libm.so.2 @b840c000 184K 20K
libffb.so.2 @b843f000 68K 4096
m/Pf258076.806a250 @40100000 ( 0) 64K
em/ctl-1002,5960,0 @40110000 ( 0) 4096
ture-1002,5960,0:1 @40111000 ( 0) 16K
ture-1002,5960,0:2 @40115000 ( 0) 68K
ture-1002,5960,0:0 @40400000 ( 0) 128M
v/shmem/Pg40200001 @48400000 ( 0) 3600K
274462 1 hoton/bin/devi-hid 10o RECEIVE 100K 144K 4096(132K)
274462 2 hoton/bin/devi-hid 10o REPLY 100K 144K 4096(20K)
274462 3 hoton/bin/devi-hid 12o SIGWAITINFO 100K 144K 8192(132K)
274462 5 hoton/bin/devi-hid 10o RECEIVE 100K 144K 4096(132K)
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libhiddi.so.1 @b8215000 24K 4096
294941 1 usr/photon/bin/pwm 10o RECEIVE 64K 172K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libph.so.3 @b822f000 1052K 36K
libimg.so.1 @b833f000 60K 4096
libfont.so.1 @b834f000 28K 4096
wframe_updated2.so @b8357000 44K 8192
323615 1 r/photon/bin/shelf 10o CONDVAR 80K 528K 12K(516K)*
323615 2 r/photon/bin/shelf 10o RECEIVE 80K 528K 8192(132K)
libc.so.3 @b0300000 468K 12K
libAp.so.3 @b8200000 60K 8192
libph.so.3 @b8211000 1052K 36K
libm.so.2 @b8321000 184K 20K
libcpp.so.4 @b8354000 376K 32K
libfont.so.1 @b83ba000 28K 4096
launchmenu.so @b83c2000 20K 4096
libphexlib.so.3 @b83c8000 180K 8192
libimg.so.1 @b83f7000 60K 4096
taskbar.so @b8407000 24K 4096
clock.so @b840e000 12K 4096
launcher.so @b8412000 12K 8192
pload.so @b8417000 20K 8192
libsocket.so.2 @b841e000 160K 28K
volume.so @b844d000 12K 4096
libasound.so.2 @b8451000 68K 12K
worldview.so @b8465000 20K 4096
344096 1 photon/bin/bkgdmgr 10o RECEIVE 12K 6044K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libph.so.3 @b8200000 1052K 36K
libphexlib.so.3 @b8310000 180K 8192
libimg.so.1 @b833f000 60K 4096
libfont.so.1 @b834f000 28K 4096
img_codec_jpg.so @b8357000 100K 4096
v/shmem/Pg40200000 @40100000 ( 0) 2304K
v/shmem/Pg40200001 @40340000 ( 0) 3600K
344097 1 hoton/bin/wmswitch 10o RECEIVE 12K 204K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libAp.so.3 @b8200000 60K 8192
libph.so.3 @b8211000 1052K 36K
libfont.so.1 @b8321000 28K 4096
344098 1 r/photon/bin/saver 10o RECEIVE 20K 204K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libAp.so.3 @b822f000 60K 8192
libph.so.3 @b8240000 1052K 36K
libimg.so.1 @b8350000 60K 4096
libfont.so.1 @b8360000 28K 4096
376858 1 r/photon/bin/pterm 10o RECEIVE 48K 240K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libimg.so.1 @b822f000 60K 4096
libAp.so.3 @b823f000 60K 8192
libph.so.3 @b8250000 1052K 36K
libm.so.2 @b8360000 184K 20K
libfont.so.1 @b8393000 28K 4096
376867 1 bin/sh 10o SIGSUSPEND 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
426020 1 r/photon/bin/pterm 10o RECEIVE 48K 240K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libimg.so.1 @b822f000 60K 4096
libAp.so.3 @b823f000 60K 8192
libph.so.3 @b8250000 1052K 36K
libm.so.2 @b8360000 184K 20K
libfont.so.1 @b8393000 28K 4096
426021 1 bin/sh 10o SIGSUSPEND 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
426022 1 x86/o/displayph8 10o RUNNING 20K 7880K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libGLES_CM.so.1 @b8215000 144K 4096
libAp.so.3 @b823a000 60K 8192
libph.so.3 @b824b000 1052K 36K
libm.so.2 @b835b000 184K 20K
libfont.so.1 @b838e000 28K 4096
devg-radeon.so @b8396000 80K 8192
libffb.so.2 @b83ac000 68K 4096
devg-soft3d.so @b83be000 60K 8192
em/ctl-1002,5960,0 @40100000 ( 0) 4096
ture-1002,5960,0:1 @40101000 ( 0) 16K
ture-1002,5960,0:2 @40105000 ( 0) 68K
ture-1002,5960,0:0 @40400000 ( 0) 128M
430119 1 bin/pidin 10o REPLY 52K 184K 8192(516K)*
libc.so.3 @b0300000 468K 12KMichael Van Reenen2009-10-19T12:31:17Zpost39859: Re: Getting started with OpenGLRobert Vallerhttp://community.qnx.com/sf/go/post398592009-10-14T10:40:14Z2009-10-14T10:40:14ZOK, thanks again for all your support.
All the best,
RobRobert Valler2009-10-14T10:40:14Zpost39762: Re: glLineWidth()Etienne Belanger(deleted)http://community.qnx.com/sf/go/post397622009-10-13T13:22:38Z2009-10-13T13:22:38ZIn general, OpenGL ES supports lines with varying widths. However, there is nothing in the specification which warrants support for a minimum range, i.e. an implementation can support line widths from 1..1 and be compliant.
Any line width that isn't within the GL_ALIASED_LINE_WIDTH_RANGE (GL_LINE_SMOOTH disabled) or GL_SMOOTH_LINE_WIDTH_RANGE (GL_LINE_SMOOTH enabled) will either be clamped or ignored.Etienne Belanger(deleted)2009-10-13T13:22:38Zpost39758: Re: Getting started with OpenGLEtienne Belanger(deleted)http://community.qnx.com/sf/go/post397582009-10-13T12:50:08Z2009-10-13T12:50:08ZThere is no hardware acceleration of OpenGL ES on the iMX35.Etienne Belanger(deleted)2009-10-13T12:50:08Zpost39747: Re: Getting started with OpenGLRobert Vallerhttp://community.qnx.com/sf/go/post397472009-10-13T08:18:17Z2009-10-13T08:18:17ZHello again,
Thanks for the feedback.
Are you saying there is NO support AT ALL for OpenGL acceleration on the iMX35 ?
Is this limited by hardware or the BSP ?
Thanks again for all your help.
Cheers,
RobRobert Valler2009-10-13T08:18:17Zpost39740: Re: Getting started with OpenGLJoel Pilon(deleted)http://community.qnx.com/sf/go/post397402009-10-12T19:07:04Z2009-10-12T19:07:04ZUnfortunately, the imx35 only has an OpenVG accelerator which accelerates the fixed OpenVG pipeline. It is not programmable like an SGX graphics accelerator were the VG pipeline could be implemented with shaders. I don't believe an OpenGLESv1 on OpenVG implementation is viable either. So you'll always be restricted to software implementations of OpenGLES on this partform. As you're aware of, we do have software fall backs for GLESv1 you can use, but performance is restricted by CPU.Joel Pilon(deleted)2009-10-12T19:07:04Zpost39738: Getting started with OpenGLRobert Vallerhttp://community.qnx.com/sf/go/post397382009-10-12T14:57:13Z2009-10-12T14:57:13ZHello,
Im currently using QNX 6.4.1 (with composition manager) on a Freescale iMX35 PDK.
I am attempting to use OpenGL in HW accelerated mode.
I have tried the egl-gears demo:
egl-gears -layer=1
This is only running at approx 13fps, I assume that this is running in SW rendering mode. there is also a lot of flickering.
I cannot get egl-gears to run without devg-soft3d.so
I ran the egl-configs program and there is nothing in the GL colum, I suspect I
have missed something out for GL support. I have copied the files specified in the
Graphics section in the realease notes,
http://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/Nto640FreescaleI.mx353dsTrunkReleasenotes
Files:
devg-imx35.so
libgf.so.1
libGLES_CM.so.1
libffb.so.2
libm.so.2
libOpenVG.so.1
libOpenVG-G12.so.1
Do I also need an EGL config profile in the winmgr.conf file ? if so, how ?
I already have the flash player running in OpenVG accelerated mode which works fine.
Thanks for your time,
RobRobert Valler2009-10-12T14:57:13Zpost39708: glLineWidth()li xiuhuihttp://community.qnx.com/sf/go/post397082009-10-10T09:35:04Z2009-10-10T09:35:04ZHi all,
I use the API glLineWidth() to change the width of line ,but why it doesn't effect?
Or OpenGL ES doesn't support the glLineWidth()?li xiuhui2009-10-10T09:35:04Zpost39410: Re: RE: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post394102009-10-06T01:29:44Z2009-10-06T01:29:44Z>
> Unfortunately not anything current at the moment. Our focus has been
> primarily on more embedded chipsets.
Ummm, what can I say? Not even one? Well I understand QNX's focus is on the embedded market, but even with that in mind, there are customers who might want a card solution. The customer I'm working with sells a large medical device with two embedded computers running QNX and they would need some kind of card, PCI, AGP, or PCI-Express to provide hardware acceleration. There's no need to be concerned about them at the moment as the software powered openGL seems to be fast enough for our current application, just something to think about.
BTW, there's posted something about an Intel Extreme something or other? Is this a motherboard hardware openGL supported in it?
>
> When running a GLES app on the 9250 with 6.4.1 can you send the output
> of pidin mem?
>
Absolutely. See Below.
Just out of curiosity though, I've noticed that my openGL ES photon application on 6.4.1 does not work if I set the driver to VESA or VGA. That sounds odd since there appears to be no hardware acceleration. Could the problem be in my EGL setup? Just wondering.
The openGL application is called displayph8. I hope this is useful to you.
Mitchell
pid tid name prio STATE code data stack
1 1 /procnto-smp-instr 0f READY 503K 2708K 320(320)*
1 2 /procnto-smp-instr 0f READY 503K 2708K 320(320)*
1 3 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 4 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 5 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 6 /procnto-smp-instr 255r RECEIVE 503K 2708K 8192(8192)
1 8 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 9 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 10 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 12 /procnto-smp-instr 10r RUNNING 503K 2708K 8192(8192)
1 15 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 17 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
1 18 /procnto-smp-instr 10r RECEIVE 503K 2708K 8192(8192)
2 1 sbin/tinit 10o REPLY 8192 112K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4099 1 proc/boot/pci-bios 10o RECEIVE 60K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4100 1 proc/boot/slogger 10o RECEIVE 12K 172K 8192(516K)*
libc.so.3 @b0300000 468K 12K
4101 1 proc/boot/io-usb 10o SIGWAITINFO 84K 256K 8192(516K)*
4101 2 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 3 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 4 proc/boot/io-usb 21r RECEIVE 84K 256K 4096(20K)
4101 5 proc/boot/io-usb 10o RECEIVE 84K 256K 4096(20K)
4101 6 proc/boot/io-usb 10r NANOSLEEP 84K 256K 4096(20K)
4101 7 proc/boot/io-usb 10o RECEIVE 84K 256K 4096(20K)
libc.so.3 @b0300000 468K 12K
devu-uhci.so @b8200000 24K 4096
devu-ohci.so @b8207000 24K 4096
devu-ehci.so @b820e000 32K 4096
4102 1 proc/boot/io-hid 10o SIGWAITINFO 28K 112K 8192(516K)*
4102 2 proc/boot/io-hid 21r RECEIVE 28K 112K 4096(12K)
4102 3 proc/boot/io-hid 15r RECEIVE 28K 112K 4096(12K)
4102 4 proc/boot/io-hid 10o RECEIVE 28K 112K 4096(20K)
4102 5 proc/boot/io-hid 10r REPLY 28K 112K 4096(20K)
4102 6 proc/boot/io-hid 10o RECEIVE 28K 112K 8192(20K)
4102 7 proc/boot/io-hid 15r RECEIVE 28K 112K 4096(12K)
libc.so.3 @b0300000 468K 12K
libhiddi.so.1 @b8200000 24K 4096
devh-ps2ser.so @b8207000 48K 8192
devh-usb.so @b8215000 16K 4096
libusbdi.so.2 @b821a000 40K 8192
4103 1 /boot/devc-con-hid 20o RECEIVE 100K 144K 8192(516K)*
4103 2 /boot/devc-con-hid 10o REPLY 100K 144K 4096(20K)
libc.so.3 @b0300000 468K 12K
/dev/mem @40100000 ( 0) 4096
/dev/mem @40101000 ( b8000) 32K
8200 1 roc/boot/devb-eide 10o SIGWAITINFO 88K 41M 8192(516K)*
8200 2 roc/boot/devb-eide 21r RECEIVE 88K 41M 4096(20K)
8200 3 roc/boot/devb-eide 21r RECEIVE 88K 41M 4096(20K)
8200 4 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 5 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 6 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 8 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
8200 9 roc/boot/devb-eide 21o RECEIVE 88K 41M 20K(24K)
8200 13 roc/boot/devb-eide 10o RECEIVE 88K 41M 20K(24K)
libc.so.3 @b0300000 468K 12K
libcam.so.2 @b8200000 64K 8192
io-blk.so @b8212000 140K 8192
cam-disk.so @b8237000 8192 4096
cam-cdrom.so @b823a000 16K 4096
fs-udf.so @b823f000 64K 8192
fs-qnx6.so @b8251000 64K 4096
20489 1 sbin/pipe 10o SIGWAITINFO 16K 112K 4096(516K)*
20489 2 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 3 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 4 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
20489 5 sbin/pipe 10o RECEIVE 16K 112K 12K(16K)
libc.so.3 @b0300000 468K 12K
24586 1 sbin/mqueue 10o RECEIVE 12K 112K 8192(516K)*
libc.so.3 @b0300000 468K 12K
53259 1 usr/sbin/mcd 10o RECEIVE 32K 112K 8192(516K)*
53259 2 usr/sbin/mcd 10o NANOSLEEP 32K 112K 8192(20K)
53259 3 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 4 usr/sbin/mcd 9o NANOSLEEP 32K 112K 8192(20K)
53259 5 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 6 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
53259 7 usr/sbin/mcd 10o SIGWAITINFO 32K 112K 8192(20K)
libc.so.3 @b0300000 468K 12K
57356 1 usr/sbin/random 10o SIGWAITINFO 24K 368K 8192(516K)*
57356 2 usr/sbin/random 10o RECEIVE 24K 368K 8192(132K)
57356 3 usr/sbin/random 10o NANOSLEEP 24K 368K 4096(132K)
libc.so.3 @b0300000 468K 12K
libm.so.2 @b8200000 184K 20K
libz.so.2 @b8233000 48K 8192
61453 1 sbin/enum-devices 10o REPLY 28K 176K 8192(516K)*
libc.so.3 @b0300000 468K 12K
77840 1 sbin/enum-usb 10o SIGWAITINFO 16K 112K 8192(516K)*
77840 2 sbin/enum-usb 10r REPLY 16K 112K 4096(20K)
libc.so.3 @b0300000 468K 12K
libusbdi.so.2 @b8200000 40K 8192
94222 1 sbin/devc-ser8250 24o RECEIVE 64K 140K 8192(516K)*
libc.so.3 @b0300000 468K 12K
94226 1 sbin/devc-par 10o RECEIVE 60K 144K 8192(516K)*
94226 2 sbin/devc-par 9r CONDVAR 60K 144K 4096(132K)
libc.so.3 @b0300000 468K 12K
98324 1 sbin/io-display 10o SIGWAITINFO 44K 244K 8192(516K)*
98324 2 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 3 sbin/io-display 12o RECEIVE 44K 244K 8192(132K)
98324 4 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 5 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
98324 6 sbin/io-display 10o RECEIVE 44K 244K 4096(132K)
libc.so.3 @b0300000 468K 12K
devg-radeon.so @b8200000 80K 8192
libm.so.2 @b8216000 184K 20K
libffb.so.2 @b8249000 68K 4096
em/ctl-1002,5960,0 @40100000 ( 0) 4096
/dev/mem @40101000 (dfef0000) 16K
/dev/mem @40400000 ( 0) 128M
114709 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO 868K 544K 8192(516K)*
114709 2 sbin/io-pkt-v4-hc 21o RECEIVE 868K 544K 8192(132K)
114709 3 sbin/io-pkt-v4-hc 10r RECEIVE 868K 544K 4096(132K)
libc.so.3 @b0300000 468K 12K
devnp-shim.so @b8200000 28K 8192
devn-tulip.so @b8209000 68K 8192
147471 1 sbin/devb-fdc 10o SIGWAITINFO 24K 244K 8192(516K)*
147471 2 sbin/devb-fdc 21r RECEIVE 24K 244K 4096(12K)
147471 3 sbin/devb-fdc 10o RECEIVE 24K 244K 20K(24K)
147471 4 sbin/devb-fdc 21o RECEIVE 24K 244K 20K(24K)
147471 5 sbin/devb-fdc 10o RECEIVE 24K 244K 20K(24K)
147471 6 sbin/devb-fdc 21o RECEIVE 24K 244K 20K(24K)
libc.so.3 @b0300000 468K 12K
libcam.so.2 @b8200000 64K 8192
io-blk.so @b8212000 140K 8192
cam-disk.so @b8237000 8192 4096
147473 1 sbin/devc-pty 20o RECEIVE 60K 336K 8192(516K)*
libc.so.3 @b0300000 468K 12K
163859 1 usr/sbin/dumper 10o RECEIVE 56K 180K 36K(516K)*
libc.so.3 @b0300000 468K 12K
180246 1 bin/sh 10o REPLY 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180247 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180248 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
180249 1 bin/login 10o REPLY 20K 108K 8192(516K)*
libc.so.3 @b0300000 468K 12K
237595 1 /photon/bin/Photon 10r RUNNING 72K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
258076 1 on/bin/io-graphics 12r CONDVAR 80K 5000K 12K(516K)*
258076 2 on/bin/io-graphics 10r RECEIVE 80K 5000K 8192(516K)
258076 3 on/bin/io-graphics 12r REPLY 80K 5000K 8192(132K)
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libph.so.3 @b8215000 1052K 36K
libfont.so.1 @b8325000 28K 4096
libphrender.so.2 @b832d000 232K 8192
phfont.so @b8369000 92K 12K
FCcore.so @b8383000 36K 4096
libblkcache.so.2 @b838d000 12K 4096
libFF-T2K-fm.so.1 @b8391000 12K 4096
bFF-T2K-cache.so.2 @b8395000 8192 4096
libFF-T2K.so.2 @b8398000 280K 12K
PHFcore.so @b83e1000 24K 8192
libfontutils.so.1 @b83e9000 4096 4096
ttfFFcore.so @b83eb000 36K 8192
devg-radeon.so @b83f6000 80K 8192
libm.so.2 @b840c000 184K 20K
libffb.so.2 @b843f000 68K 4096
m/Pf258076.806a250 @40100000 ( 0) 64K
em/ctl-1002,5960,0 @40110000 ( 0) 4096
ture-1002,5960,0:1 @40111000 ( 0) 16K
ture-1002,5960,0:2 @40115000 ( 0) 68K
ture-1002,5960,0:0 @40400000 ( 0) 128M
v/shmem/Pg40200001 @48400000 ( 0) 3600K
274462 1 hoton/bin/devi-hid 10o RECEIVE 100K 144K 4096(132K)
274462 2 hoton/bin/devi-hid 10o REPLY 100K 144K 4096(20K)
274462 3 hoton/bin/devi-hid 12o SIGWAITINFO 100K 144K 8192(132K)
274462 5 hoton/bin/devi-hid 10o RECEIVE 100K 144K 4096(132K)
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libhiddi.so.1 @b8215000 24K 4096
294941 1 usr/photon/bin/pwm 10o RECEIVE 64K 172K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libph.so.3 @b822f000 1052K 36K
libimg.so.1 @b833f000 60K 4096
libfont.so.1 @b834f000 28K 4096
wframe_updated2.so @b8357000 44K 8192
323615 1 r/photon/bin/shelf 10o CONDVAR 80K 528K 12K(516K)*
323615 2 r/photon/bin/shelf 10o RECEIVE 80K 528K 8192(132K)
libc.so.3 @b0300000 468K 12K
libAp.so.3 @b8200000 60K 8192
libph.so.3 @b8211000 1052K 36K
libm.so.2 @b8321000 184K 20K
libcpp.so.4 @b8354000 376K 32K
libfont.so.1 @b83ba000 28K 4096
launchmenu.so @b83c2000 20K 4096
libphexlib.so.3 @b83c8000 180K 8192
libimg.so.1 @b83f7000 60K 4096
taskbar.so @b8407000 24K 4096
clock.so @b840e000 12K 4096
launcher.so @b8412000 12K 8192
pload.so @b8417000 20K 8192
libsocket.so.2 @b841e000 160K 28K
volume.so @b844d000 12K 4096
libasound.so.2 @b8451000 68K 12K
worldview.so @b8465000 20K 4096
344096 1 photon/bin/bkgdmgr 10o RECEIVE 12K 6044K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libph.so.3 @b8200000 1052K 36K
libphexlib.so.3 @b8310000 180K 8192
libimg.so.1 @b833f000 60K 4096
libfont.so.1 @b834f000 28K 4096
img_codec_jpg.so @b8357000 100K 4096
v/shmem/Pg40200000 @40100000 ( 0) 2304K
v/shmem/Pg40200001 @40340000 ( 0) 3600K
344097 1 hoton/bin/wmswitch 10o RECEIVE 12K 204K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libAp.so.3 @b8200000 60K 8192
libph.so.3 @b8211000 1052K 36K
libfont.so.1 @b8321000 28K 4096
344098 1 r/photon/bin/saver 10o RECEIVE 20K 204K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libAp.so.3 @b822f000 60K 8192
libph.so.3 @b8240000 1052K 36K
libimg.so.1 @b8350000 60K 4096
libfont.so.1 @b8360000 28K 4096
376858 1 r/photon/bin/pterm 10o RECEIVE 48K 240K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libimg.so.1 @b822f000 60K 4096
libAp.so.3 @b823f000 60K 8192
libph.so.3 @b8250000 1052K 36K
libm.so.2 @b8360000 184K 20K
libfont.so.1 @b8393000 28K 4096
376867 1 bin/sh 10o SIGSUSPEND 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
426020 1 r/photon/bin/pterm 10o RECEIVE 48K 240K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libphexlib.so.3 @b8200000 180K 8192
libimg.so.1 @b822f000 60K 4096
libAp.so.3 @b823f000 60K 8192
libph.so.3 @b8250000 1052K 36K
libm.so.2 @b8360000 184K 20K
libfont.so.1 @b8393000 28K 4096
426021 1 bin/sh 10o SIGSUSPEND 184K 144K 8192(516K)*
libc.so.3 @b0300000 468K 12K
426022 1 x86/o/displayph8 10o RUNNING 20K 7880K 12K(516K)*
libc.so.3 @b0300000 468K 12K
libgf.so.1 @b8200000 76K 8192
libGLES_CM.so.1 @b8215000 144K 4096
libAp.so.3 @b823a000 60K 8192
libph.so.3 @b824b000 1052K 36K
libm.so.2 @b835b000 184K 20K
libfont.so.1 @b838e000 28K 4096
devg-radeon.so @b8396000 80K 8192
libffb.so.2 @b83ac000 68K 4096
devg-soft3d.so @b83be000 60K 8192
em/ctl-1002,5960,0 @40100000 ( 0) 4096
ture-1002,5960,0:1 @40101000 ( 0) 16K
ture-1002,5960,0:2 @40105000 ( 0) 68K
ture-1002,5960,0:0 @40400000 ( 0) 128M
430119 1 bin/pidin 10o REPLY 52K 184K 8192(516K)*
libc.so.3 @b0300000 468K 12KMitchell Schoenbrun2009-10-06T01:29:44Zpost39381: RE: New with QNX OpenGL ESMichael Van Reenenhttp://community.qnx.com/sf/go/post393812009-10-05T15:03:53Z2009-10-05T15:03:53ZUnfortunately not anything current at the moment. Our focus has been
primarily on more embedded chipsets.
When running a GLES app on the 9250 with 6.4.1 can you send the output
of pidin mem?
Thanks
-----Original Message-----
From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com]
Sent: September 29, 2009 2:00 AM
To: opengles-graphics
Subject: New with QNX OpenGL ES
I've been playing around with OpenGL on 6.4.1 under Photon. I have Mike
to thank for some demo code that got me started.
I'm wondering, is there a desktop AGP or PCI card that has hardware
supported openGL from QNX? I've tried an ATI 9250 card, but I'm 90%
sure that there is no hardware acceleration going on.
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post38933Michael Van Reenen2009-10-05T15:03:53Zpost38933: New with QNX OpenGL ESMitchell Schoenbrunhttp://community.qnx.com/sf/go/post389332009-09-29T06:00:04Z2009-09-29T06:00:04ZI've been playing around with OpenGL on 6.4.1 under Photon. I have Mike to thank for some demo code that got me started.
I'm wondering, is there a desktop AGP or PCI card that has hardware supported openGL from QNX? I've tried an ATI 9250 card, but I'm 90% sure that there is no hardware acceleration going on.Mitchell Schoenbrun2009-09-29T06:00:04Zpost38524: glQueryMatrixxOES is broken in QNX 6.4.1Mike Gorchakhttp://community.qnx.com/sf/go/post385242009-09-23T07:39:01Z2009-09-23T07:39:01ZWhile porting GLU nurbs to OpenGL ES 1.0 I've found strange behavior of glQueryMatrixxOES() when quering GL_MODELVIEW_MATRIX state. My code:
...
GLint lg2table[32]=
{
0x00000001,
0x00000002,
0x00000004,
0x00000008,
0x00000010,
0x00000020,
0x00000040,
0x00000080,
0x00000100,
0x00000200,
0x00000400,
0x00000800,
0x00001000,
0x00002000,
0x00004000,
0x00008000,
0x00010000,
0x00020000,
0x00040000,
0x00080000,
0x00100000,
0x00200000,
0x00400000,
0x00800000,
0x01000000,
0x02000000,
0x04000000,
0x08000000,
0x10000000,
0x20000000,
0x40000000,
0x80000000
};
...
/* Fixed point to float point conversion */
#define FX2F(fx) (GLfloat(fx)/65536.0f)
....
/* Check if OpenGL ES 1.1 is used, then call glGetFloatv directly */
#if defined(GL_VERSION_ES_CM_1_1)
/* Just passthrough the request to OpenGL ES 1.1 */
glGetFloatv(pname, params);
return;
#endif /* GL_VERSION_ES_CM_1_1 */
/* Check if OpenGL ES 1.0 is used, then try to emulate glGetFloatv */
#if (defined(GL_OES_VERSION_1_0) || defined(GL_VERSION_ES_CM_1_0)) && !defined(GL_VERSION_ES_CM_1_1)
/* Check for query_matrix extension, which is very usefull in OpenGL ES 1.0 to obtain */
/* GLES 1.0 dynamic state */
#if defined(GL_OES_query_matrix)
{
GLfixed mantissa[16];
GLint exponent[16];
/* Clear the output data, in case if glQueryMatrixxOES() will fail */
memset(params, 0x00, 16*sizeof(GLfloat));
/* Since OpenGL ES 1.0 has no GL_MATRIX_MODE for glGet() we will try to setup */
/* required matrix and then restore modelview matrix, because it must be default */
/* current matrix mode for rendering process. */
switch (pname)
{
case GL_MODELVIEW_MATRIX:
glMatrixMode(GL_MODELVIEW);
break;
case GL_PROJECTION_MATRIX:
glMatrixMode(GL_PROJECTION);
break;
}
/* Query current matrix content */
if (glQueryMatrixxOES(mantissa, exponent)==0)
{
for (int it=0; it<16; it++)
{
params[it]=FX2F(mantissa[it])*lg2table[exponent[it]];
}
}
/* Restore "default" matrix mode */
glMatrixMode(GL_MODELVIEW);
}
#else
#error "Do not know how to query modelview and projection matrices"
#endif /* GL_OES_query_matrix */
And the simple OpenGL and OpenGL ES code, which transforms modelview matrix:
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(0.0, 0.0, -15.0);
glRotatef(330.0f, 1.0, 0.0, 0.0);
glRotatef(3.0f, 1.0f, 1.0f, 1.0f);
After this code execution I query the modelview matrix and got:
modelview:
m[0]=0.999084 m[1]=0.000000 m[2]=-0.000000 m[3]=0.000000
m[4]=-0.000000 m[5]=0.880569 m[6]=-0.000000 m[7]=0.000000
m[8]=0.000000 m[9]=0.000000 m[10]=0.880112 m[11]=0.000000
m[12]=0.000000 m[13]=0.000000 m[14]=-15.000000 m[15]=1.000000
You can see, that only diagonal matrix elements are set correctly and m[14] element - translation in Z axis. But when I query the same transformed matrix in OpenGL under Windows, not in OpenGL ES, I got:
modelview:
m[0]=0.999086 m[1]=0.011684 m[2]=-0.041109 m[3]=0.000000
m[4]=-0.029759 m[5]=0.880571 m[6]=-0.472980 m[7]=0.000000
m[8]=0.030673 m[9]=0.473771 m[10]=0.880114 m[11]=0.000000
m[12]=0.000000 m[13]=0.000000 m[14]=-15.000000 m[15]=1.000000
Diagonal elements have small differencies comparing to OpenGL ES in QNX, it is due to calculation precision in double instead of float, but other non-diagonal matrix elements are set correctly after two subsequent glRotatef calls.Mike Gorchak2009-09-23T07:39:01Zpost36253: Re: Software Rasterizer vs. Coral?Malte Mundt(deleted)http://community.qnx.com/sf/go/post362532009-08-19T13:02:55Z2009-08-19T13:02:55ZSo it actually does use the hardware to render, only prints out wrong information? Ok, glad to hear this. Thanks.
- MalteMalte Mundt(deleted)2009-08-19T13:02:55Zpost36251: Re: Software Rasterizer vs. Coral?Etienne Belanger(deleted)http://community.qnx.com/sf/go/post362512009-08-19T12:45:19Z2009-08-19T12:45:19ZThere is a bug in egl-gears. It calls glGetString before eglGetDisplay, eglInitialize, eglCreateContext, eglCreate[xyz]Surface, and eglMakeCurrent. Normally, the returned strings in this case should be NULL and the problem would have been rectified. However, this implementation of EGL returns the software rasterizer strings until a connection to a real OpenGL ES device is established.
The problem was fixed in egl-tunnel.Etienne Belanger(deleted)2009-08-19T12:45:19Zpost36243: Software Rasterizer vs. Coral?Malte Mundt(deleted)http://community.qnx.com/sf/go/post362432009-08-19T11:37:13Z2009-08-19T11:37:13ZHi,
on my MPC5200 with Coral-P, 6.4.1, I start egl-gears and get:
# egl-gears -info
GL_RENDERER = Software Rasterizer
GL_VERSION = OpenGL ES-CM 1.0
GL_VENDOR = QNX Software Systems
GL_EXTENSIONS = GL_OES_compressed_paletted_texture GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format
156 frames in 5.025 seconds = 31.045 FPS
155 frames in 5.026 seconds = 30.840 FPS
with egl-tunnel on the same hardware, I get:
# egl-tunnel -info
GL_RENDERER = Fujitsu Coral
GL_VERSION = OpenGL ES-CM 1.0
GL_VENDOR = QNX Software Systems
GL_EXTENSIONS = GL_OES_compressed_paletted_texture GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format GL_QNX
_stippled_lines
53 frames in 5.058 seconds = 10.478 FPS
Why is GL_RENDERER not always 'Fujitsu Coral'?
- MalteMalte Mundt(deleted)2009-08-19T11:37:13Zpost31192: Bug with alpha blending with lighting enabled and enabled GL_COLOR_MATERIALMike Gorchakhttp://community.qnx.com/sf/go/post311922009-06-09T12:42:35Z2009-06-09T12:42:35ZSample code:
glEnable(GL_LIGHTING);
/* Setup light source, etc. on GL_LIGHT1 */
glEnable(GL_LIGHT1);
glBlendFunc(GL_SRC_ALPHA, GL_ONE);
glEnable(GL_BLEND);
glColor4f(1.0f, 1.0f, 1.0f, 0.5f);
glEnable(GL_COLOR_MATERIAL);
Then try to render any primitive, nothing have been produced. Result is just clear screen after glClear().
If glEnable(GL_COLOR_MATERIAL); line is commented out, all works according to standard.Mike Gorchak2009-06-09T12:42:35Zpost30666: Bug in the glTexImage2D() with UNSIGNED_SHORT_5_5_5_1 and UNSIGNED_SHORT_4_4_4_4Mike Gorchakhttp://community.qnx.com/sf/go/post306662009-06-03T12:45:15Z2009-06-03T12:45:15ZglTexImage2D() reads texture image colors in wrong order, when texture data format passed as the UNSIGNED_SHORT_5_5_5_1 or as the UNSIGNED_SHORT_4_4_4_4.
When texture is displayed, I can see, that it has been read previously in format ABRA (not a typo), by bits: 1st byte: ABBBBBRR 2nd byte: RRRAAAAA. But according to standard, texture image must be in the RGBA format (R - highest bit, A - lowest bit).
The same for the RGBA4444 texture format, green color is omitted and color components are placed in wrong order.
I can't check right now UNSIGNED_SHORT_5_6_5, but I think it is also affected
Could be reproduced using software (devg-svga, devg-i830) or hardware renderer (devg-extreme2).Mike Gorchak2009-06-03T12:45:15Zpost30167: Re: Bug in the glCopyTexImage2D() implementationMike Gorchakhttp://community.qnx.com/sf/go/post301672009-05-27T18:03:49Z2009-05-27T18:03:49Z> If you are not going to use the texture until glCopyTexImage2D is called, I
> would just drop the first glTexImage2D. If the texture is used prior to the
> glCopyTexImage2D, you could try to specify the first image with a LUMINANCE
> internalformat. Because the internal formats match, the driver won't have to
> reallocate memory when you do your glCopyTexImage2D. It might even make your
> problem go away because I suspect the problem is related to the difference in
> internal formats between image specifications.
I use the texture before glCopyTexImage2D(), but anyway changing GL_LUMINANCE to GL_RGBA helps me. GL_LUMINANCE is used in the first case because output for "render to texture" is monochromatic itself.
I hope this bug with conversion will be fixed soon. Etienne, I'm sorry to remind you, but maybe you'll answer my other questions in the OpenGL ES forum, which have remained unanswered.Mike Gorchak2009-05-27T18:03:49Zpost30125: Re: Bug in the glCopyTexImage2D() implementationEtienne Belanger(deleted)http://community.qnx.com/sf/go/post301252009-05-27T12:42:56Z2009-05-27T12:42:56ZIt is true that the copying of image data is mostly done in software, but each driver may have its own transfer routines. I am not 100% sure if this problem is common to all drivers or devg-extreme2 only. However, it sure sounds like there is a problem.
One thing, though. Your initial call to glTexImage2D defines an image of size 128 x 128 for level 0 of the currently bound texture with an RGBA format. The subsequent call to glCopyTexImage2D makes level 0 (I assume of the same texture) to be a 128 x 128 image with LUMINANCE format. Because the formats don't match, the driver will have to free the memory used by the first image data specification and allocate memory for this new image data.
If you are not going to use the texture until glCopyTexImage2D is called, I would just drop the first glTexImage2D. If the texture is used prior to the glCopyTexImage2D, you could try to specify the first image with a LUMINANCE internalformat. Because the internal formats match, the driver won't have to reallocate memory when you do your glCopyTexImage2D. It might even make your problem go away because I suspect the problem is related to the difference in internal formats between image specifications.Etienne Belanger(deleted)2009-05-27T12:42:56Zpost30106: Bug in the glCopyTexImage2D() implementationMike Gorchakhttp://community.qnx.com/sf/go/post301062009-05-27T05:11:11Z2009-05-27T05:11:11ZAs far as I understand glCopyTexImage2D() is implemented always using software fallback only, so problem affects all 3D drivers, not only devg-extreme2.
I'm creating texture as:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 128, 128, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
texture data is set to 0x00 as the initial state.
Then color buffer content (in monochromatic form) is copied to this texture via:
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 0, 0, 128, 128, 0);
When color buffer is set to 565 format all works fine, but in case of current color buffer is in 8888 format (maybe 888 too - I can't check) copied texture looks shrinked twice by horizontal resolution.
If GL_LUMINANCE is replaced with GL_RGBA in glCopyTexImage2D() function call - all works fine with any color buffer format.Mike Gorchak2009-05-27T05:11:11Zpost29619: Re: GL_OES_vertex_buffer_object extension incorrect defines.Mike Gorchakhttp://community.qnx.com/sf/go/post296192009-05-18T13:54:48Z2009-05-18T13:54:48ZBy the way, GL_VERSION_ES_CM_1_0 and GL_VERSION_ES_CL_1_0 are not defined in QNX 6.4.1, only GL_OES_VERSION_1_0 is defined.Mike Gorchak2009-05-18T13:54:48Zpost29336: Re: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post293362009-05-13T11:53:57Z2009-05-13T11:53:57Z> If I set material settings (AMBIENT and DIFFUSE) to default values, shading
> begins to work correctly.
Any news ?Mike Gorchak2009-05-13T11:53:57Zpost29245: Re: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post292452009-05-12T12:33:20Z2009-05-12T12:33:20Z> What happens if you manually set the light and material state to the default
> values ?
If I set material settings (AMBIENT and DIFFUSE) to default values, shading begins to work correctly.Mike Gorchak2009-05-12T12:33:20Zpost29243: Re: Something wrong with default Materials settings in QNX's OpenGL ESEtienne Belanger(deleted)http://community.qnx.com/sf/go/post292432009-05-12T12:18:36Z2009-05-12T12:18:36ZWhat happens if you manually set the light and material state to the default values ?Etienne Belanger(deleted)2009-05-12T12:18:36Zpost29220: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyMike Gorchakhttp://community.qnx.com/sf/go/post292202009-05-12T04:31:30Z2009-05-12T04:31:30ZI'm working now on project, where is my task to convert large OpenGL/Windows engineering visualization project to OpenGL ES/QNX.
I can compare now OpenGL/Windows output (using nVidia and ATI chips) and QNX's software and hardware (devg-extreme2) OpenGL ES output.
In QNX I get an overbrighten scene in all cases, with the same parameters, many triangles became too bright and when I manually trying to make more darken colors, all scene looks like an overbrighten scene painted using dark colors.
P.S. And issue with GL_LIGHT_MODEL_AMBIENT still persist.Mike Gorchak2009-05-12T04:31:30Zpost29219: Re: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post292192009-05-12T04:16:32Z2009-05-12T04:16:32ZEtienne, could you comment this issue, because problem still persist.Mike Gorchak2009-05-12T04:16:32Zpost28910: Re: VBO and VA limitsMike Gorchakhttp://community.qnx.com/sf/go/post289102009-05-07T13:59:36Z2009-05-07T13:59:36Z> glBindBuffer(GL_ARRAY_BUFFER, vbo);
> [...]
> glVertexPointer(3, GL_FLOAT, 0, 0);
> [...]
> glBufferData(GL_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
> [...]
> glDrawArrays(GL_TRIANGLES, 0, count);
I'm talking about bad offset value could hang the machine. I know how to use VBOs.
Etienne, could you answer on question "What is maximum vertex count could be passed as VBOs and VAs data ?"Mike Gorchak2009-05-07T13:59:36Zpost28907: Re: glGetString(GL_VERSION) do not conforms to OpenGL ES 1.0 specification !Mike Gorchakhttp://community.qnx.com/sf/go/post289072009-05-07T13:55:23Z2009-05-07T13:55:23Z> This is incorrect. The format of the VERSION string you describe is the one
> defined in the OpenGL 1.3 specification. This is one area where there are
> differences between OpenGL 1.3 and OpenGL ES 1.0.
>
> http://www.khronos.org/registry/gles/specs/1.0/opengles_spec_1_0.pdf
>
> In section 6.1 of the OpenGL ES 1.0 specification, Querying GL state, the
> version string format is specified as:
>
> "OpenGL ES-XX 1.0" XX={CM, CL}
>
> The version string returned by the QNX OpenGL ES 1.0 follows the specification
> .
My quote above from: http://www.khronos.org/registry/gles/specs/1.0/opengles_1_0_manual.pdfMike Gorchak2009-05-07T13:55:23Zpost28896: Re: glGetString(GL_VERSION) do not conforms to OpenGL ES 1.0 specification !Etienne Belanger(deleted)http://community.qnx.com/sf/go/post288962009-05-07T13:29:08Z2009-05-07T13:29:08ZThis is incorrect. The format of the VERSION string you describe is the one defined in the OpenGL 1.3 specification. This is one area where there are differences between OpenGL 1.3 and OpenGL ES 1.0.
http://www.khronos.org/registry/gles/specs/1.0/opengles_spec_1_0.pdf
In section 6.1 of the OpenGL ES 1.0 specification, Querying GL state, the version string format is specified as:
"OpenGL ES-XX 1.0" XX={CM, CL}
The version string returned by the QNX OpenGL ES 1.0 follows the specification.Etienne Belanger(deleted)2009-05-07T13:29:08Zpost28891: Re: VBO and VA limitsEtienne Belanger(deleted)http://community.qnx.com/sf/go/post288912009-05-07T13:21:02Z2009-05-07T13:21:02ZglVertexPointer can return one of the following errors:
GL_INVALID_VALUE is generated if size is not 2, 3, or 4.
GL_INVALID_ENUM is generated if type is is not an accepted value.
GL_INVALID_VALUE is generated if stride is negative.
The only VBO related work that glVertexPointer is required to do is to copy the buffer object name in the ARRAY_BUFFER_BINDING internal state to the VERTEX_ARRAY_BUFFER_BINDING internal state. This allows the following code to work:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
[...]
glVertexPointer(3, GL_FLOAT, 0, 0);
[...]
glBufferData(GL_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
[...]
glDrawArrays(GL_TRIANGLES, 0, count);
GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES are marked as exposed, but not queriable in the OpenGL ES 1.0 spec. Neither are exposed in the OpenGL ES 1.1 spec. For these reasons, I would just refrain from writing code that uses these constants.Etienne Belanger(deleted)2009-05-07T13:21:02Zpost28882: Re: OpenGLES possible with my configuration?Frank Maierhttp://community.qnx.com/sf/go/post288822009-05-07T12:49:36Z2009-05-07T12:49:36ZThx for this info ... but i cannot found a AGTDK package only patches for IDE 6.3.2 ...
Can you give me a link?Frank Maier2009-05-07T12:49:36Zpost28880: Re: OpenGLES possible with my configuration?Etienne Belanger(deleted)http://community.qnx.com/sf/go/post288802009-05-07T12:27:11Z2009-05-07T12:27:11ZYou can build OpenGL ES 1.0 applications with QNX Neutrino 6.3.2 and the 4.0.1 IDE if you install the AGTDK and related patches.Etienne Belanger(deleted)2009-05-07T12:27:11Zpost28873: OpenGLES possible with my configuration?Frank Maierhttp://community.qnx.com/sf/go/post288732009-05-07T11:27:26Z2009-05-07T11:27:26ZHi,
i am working with the IDE Version 4.0.1 because here in the forum i received the answer that i must use this version because of the QNX version 6.3.2 on my target.
But i want to use OpenGLES ... it seems to me that i required the 6.4.0 IDE to use OpenGLES.
So what shall i do ???
Any hints?
FrankFrank Maier2009-05-07T11:27:26Zpost28842: Re: GL_OES_vertex_buffer_object extension incorrect defines.Etienne Belanger(deleted)http://community.qnx.com/sf/go/post288422009-05-06T18:04:23Z2009-05-06T18:04:23ZThey are part of OpenGL ES 1.1, so unless your application code targets platforms with OpenGL ES frozen at 1.0, you shouldn't have functions named glBindBuffer, glPointParameterf etc in your code.Etienne Belanger(deleted)2009-05-06T18:04:23Zpost28840: Re: Stencil problem with devg-extreme2 on 82852GMMike Gorchakhttp://community.qnx.com/sf/go/post288402009-05-06T17:33:38Z2009-05-06T17:33:38ZMy apologies, stencil works using software renderer, but on devg-extreme2 (on 6.4.0 and 6.4.1 M4) it is broken, now I've just a black screen when stencil is on.Mike Gorchak2009-05-06T17:33:38Zpost28839: Re: GL_OES_vertex_buffer_object extension incorrect defines.Mike Gorchakhttp://community.qnx.com/sf/go/post288392009-05-06T17:14:57Z2009-05-06T17:14:57Z> Extension functions are not required to be named the same as the string that
> is used to get them unless they are also exported statically.
> That's why eglGetProcAddress("glBindBufferOES") can return the address of a
> function named glBindBuffer. You wouldn't want to force eglGetProcAddress("
> glBindBufferOES") to return a pointer to a glBindBufferOES function on a
> OpenGL ES 1.1 implementation...
No, I mean glBindBuffer() function is exported inside shared object, so if application uses it's own declarations (GLES headers), it can be linked even if it uses glBindBuffer() function directly. Maybe better to rename all VBO functions with underscore prefix, like _glBindBuffer() or to use GCC's special directive for function exporting and to hide the rest functions, which are not belong to an API.Mike Gorchak2009-05-06T17:14:57Zpost28821: Re: GL_OES_vertex_buffer_object extension incorrect defines.Etienne Belanger(deleted)http://community.qnx.com/sf/go/post288212009-05-06T15:17:07Z2009-05-06T15:17:07ZExtension functions are not required to be named the same as the string that is used to get them unless they are also exported statically.
That's why eglGetProcAddress("glBindBufferOES") can return the address of a function named glBindBuffer. You wouldn't want to force eglGetProcAddress("glBindBufferOES") to return a pointer to a glBindBufferOES function on a OpenGL ES 1.1 implementation...
From the EGL 1.4 spec on eglGetProcAddress:
[...]
For functions that are queryable with eglGetProcAddress, implementations may choose to also export those functions statically from the object libraries implementing those functions. However, portable clients cannot rely on this behavior.
[...]Etienne Belanger(deleted)2009-05-06T15:17:07Zpost28810: VBO and VA limitsMike Gorchakhttp://community.qnx.com/sf/go/post288102009-05-06T14:14:04Z2009-05-06T14:14:04Zif VBO is activated in the current context, it doesn't check if offset passed via glVertexPointer() is exceeds amount of data passed to vertex buffer object.
glBindBufferOES(GL_ARRAY_BUFFER_ES, nVBOVertices);
glVertexPointer(3, GL_FLOAT, 0, 0x60000000);
glDrawArrays(GL_TRIANGLES, 0, nVertexCount);
It is silly example but in my case I specified 32768 vertices offset instead of 31255, and it was enough to hang all QNX box.
What is vertex maximum count (or memory size in bytes) limit when vertices are passed to VBO ?
What about limits for VAs ? On devg-extreme2 glGetIntegerv() returns 65536 for GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES. But by mistake I've passed near 98K of vertices and all primitives have been drawn, like there are no any limits.Mike Gorchak2009-05-06T14:14:04Zpost28802: Re: GL_OES_vertex_buffer_object extension incorrect defines.Mike Gorchakhttp://community.qnx.com/sf/go/post288022009-05-06T13:55:16Z2009-05-06T13:55:16Z> Correct.
>
> GLES/glext.h should define GL_ARRAY_BUFFER_OES. GLES/gl.h should define
> GL_ARRAY_BUFFER if GL_VERSION_ES_CM_1_1 or GL_VERSION_ES_CL_1_1 is defined.
> The same is true for all the other GL_OES_vertex_buffer_object constants.
By the way, libGLES_CM in 6.4.0 and in 6.4.1 contains glBindBuffer() instead of glBindBufferOES(). The same for the other VBO functions.
Since I'm using dynamic address loading for VBO functions, I've not noticed that they are having wrong names. But eglGetProcAddress() handles xxxxxdOES names and returns correct address for all VBO functions with or without OES suffix.Mike Gorchak2009-05-06T13:55:16Zpost28781: Re: GL_OES_vertex_buffer_object extension incorrect defines.Etienne Belanger(deleted)http://community.qnx.com/sf/go/post287812009-05-06T12:44:44Z2009-05-06T12:44:44ZCorrect.
GLES/glext.h should define GL_ARRAY_BUFFER_OES. GLES/gl.h should define GL_ARRAY_BUFFER if GL_VERSION_ES_CM_1_1 or GL_VERSION_ES_CL_1_1 is defined. The same is true for all the other GL_OES_vertex_buffer_object constants.Etienne Belanger(deleted)2009-05-06T12:44:44Zpost28780: Re: glNewList(), glCallList(), glDeleteLists() in 6.4.1Etienne Belanger(deleted)http://community.qnx.com/sf/go/post287802009-05-06T12:38:45Z2009-05-06T12:38:45ZglGetFloatv is defined in OpenGL ES 1.1 but no in OpenGL ES 1.0. If glGetString(GL_VERSION) returns "1.0...", you should avoid using this function, otherwise unexpected results may occur now or with future updates.
glNewList, glCallList, glDeleteLists, etc are not part of OpenGL ES, but they are part of OpenGL ES SC. For this reason, it would be better not to have functions with identical names, even if you would expect these to be defined in libGLES_SC only, and not libGLES_C[M|L]. To my knowledge, these entry points were added for very specific uses and should not be for general use.Etienne Belanger(deleted)2009-05-06T12:38:45Zpost28772: glNewList(), glCallList(), glDeleteLists() in 6.4.1Mike Gorchakhttp://community.qnx.com/sf/go/post287722009-05-06T11:24:56Z2009-05-06T11:24:56ZJust found that GLES_CM library in 6.4.1 M4 have glNewList(), glCallList(), glDeleteLists(), etc. functions. I've found them because they are intersects with my library which also have these functions for GL emulation with identical names.
Why these functions for ?
Does gGetlFloatv() works as expected in QNX's GLES 1.0 implementation ?Mike Gorchak2009-05-06T11:24:56Zpost28762: GL_OES_vertex_buffer_object extension incorrect defines.Mike Gorchakhttp://community.qnx.com/sf/go/post287622009-05-06T06:56:25Z2009-05-06T06:56:25ZGLES/glext.h contains definition of functions:
glBindBufferOES(), glDeleteBuffersOES(), glGenBuffersOES(), glIsBufferOES(), glBufferDataOES(), glBufferSubDataOES(), glGetBufferParameterivOES().
And defines for GL_OES_vertex_buffer_object extension:
#define GL_ARRAY_BUFFER 0x8892
#define GL_ELEMENT_ARRAY_BUFFER 0x8893
.... etc.
This is incorrect, since all defines must have _OES suffix, since it is an extension, not a part of OpenGL ES 1.0. Defines must be like this:
#define GL_ARRAY_BUFFER_OES 0x8892
#define GL_ELEMENT_ARRAY_BUFFER_OES 0x8893
.... etc.Mike Gorchak2009-05-06T06:56:25Zpost28699: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post286992009-05-05T14:36:44Z2009-05-05T14:36:44Z> > I've added pauses between each triangle rendering and glFlush() after each
> > glDrawArrays() call. When eglSwapInterval() is set to 0 and
> > gf_3d_target_create() allocates two surfaces for double buffering, I am able
>
> > to see how hidden faces are rendered first, and then how front faces are
> > rendered. So it is definitely a bug, GLES renders to visible buffer, but not
>
> > to back buffer.
>
> With what driver were you seeing this ? Was it on the extreme2, soft3d or with
> vmware ?
>
> I wouldn't say this is "proof" that GLES rendering is done on the front buffer
> . It could simply be that the implementation of glFinish on this particular
> driver returns too early, which causes EGL to flip buffers while rendering is
> still going on. In that case, one could still argue that rendering is done on
> the "front" buffer ; )
>
> I'll look at the sample one more time to rule out the application, then, I
> would have to get my hands on the same hardware to do more investigating.
This sample will work (and will show the problem) on any hardware, excluding vga, svga, flat, vesa and vmware drivers, because they are not providing video memory allocation for the second buffer using double buffering.
Could you also comment other issues, which I've found ?Mike Gorchak2009-05-05T14:36:44Zpost28688: Re: Double buffering in OpenGL ESEtienne Belanger(deleted)http://community.qnx.com/sf/go/post286882009-05-05T13:24:12Z2009-05-05T13:24:12Z> I've added pauses between each triangle rendering and glFlush() after each
> glDrawArrays() call. When eglSwapInterval() is set to 0 and
> gf_3d_target_create() allocates two surfaces for double buffering, I am able
> to see how hidden faces are rendered first, and then how front faces are
> rendered. So it is definitely a bug, GLES renders to visible buffer, but not
> to back buffer.
With what driver were you seeing this ? Was it on the extreme2, soft3d or with vmware ?
I wouldn't say this is "proof" that GLES rendering is done on the front buffer. It could simply be that the implementation of glFinish on this particular driver returns too early, which causes EGL to flip buffers while rendering is still going on. In that case, one could still argue that rendering is done on the "front" buffer ; )
I'll look at the sample one more time to rule out the application, then, I would have to get my hands on the same hardware to do more investigating.Etienne Belanger(deleted)2009-05-05T13:24:12Zpost28684: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post286842009-05-05T13:10:01Z2009-05-05T13:10:01ZEtienne, could you comment the described issue with eglSwapInterval(0) ?Mike Gorchak2009-05-05T13:10:01Zpost28633: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyMike Gorchakhttp://community.qnx.com/sf/go/post286332009-05-04T15:36:31Z2009-05-04T15:36:31Z> GL_EMISSION (e_cm in the equation) and GL_LIGHT_MODEL_AMBIENT (a_cs in the
> equation) are not attenuated based on distance (attn_i in the equation).
> I did a quick check and color clamping is done at the very last stage to
> ensure proper evaluation of the color derivatives and texture environment
> during the rasterization process.
Just tested out another parameter {-0.2f, -0.2f, -0.2f, -1.0f} - nagative, based on the default ambient lighting and it produces wonderfull gamma of colors instead of darkened one. I think something wrong with negative value of colors in the lighting equation.Mike Gorchak2009-05-04T15:36:31Zpost28632: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyMike Gorchakhttp://community.qnx.com/sf/go/post286322009-05-04T15:23:33Z2009-05-04T15:23:33ZI just tested out {-1.0f, -1.0f, -1.0f, -1.0f) as GL_LIGHT_MODEL_AMBIENT and it produces overbrighted color inversed scene, but must be very dark colored scene. Definitely lighting equation is evualated incorrectly.Mike Gorchak2009-05-04T15:23:33Zpost28631: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyEtienne Belanger(deleted)http://community.qnx.com/sf/go/post286312009-05-04T15:20:12Z2009-05-04T15:20:12ZGL_EMISSION (e_cm in the equation) and GL_LIGHT_MODEL_AMBIENT (a_cs in the equation) are not attenuated based on distance (attn_i in the equation).
I did a quick check and color clamping is done at the very last stage to ensure proper evaluation of the color derivatives and texture environment during the rasterization process.Etienne Belanger(deleted)2009-05-04T15:20:12Zpost28630: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyMike Gorchakhttp://community.qnx.com/sf/go/post286302009-05-04T15:05:59Z2009-05-04T15:05:59Z> The OpenGL 1.3 spec gives the following lighting equation (I assume this is
> what you were referring to...)
>
> [...]
> If c_es = SINGLE COLOR, then the equations to compute c_pri and c_sec are
>
> c_pri = e_cm + a_cm * a_cs + sum(i=0..n-1, att_i * spot_i * [a_cm * a_cli + (n
> dot VP_pli) * d_cm * d_cli + f_i * exp(n dot h_i, s_rm) * s_cm * s_cli])
>
> csec = (0; 0; 0; 0)
> [...]
>
> I looked at the software renderer and it does implement the above equation.
Etienne, at which stage color clamping [-1.0f ... 1.0f] is performed during lighting equation evaluation ? Maybe problem is in the distance between vertex and light source calculation, since overbright scene lighting could be appeared only if object directly near light source, otherwise light must be attenuated according to vertex distance.Mike Gorchak2009-05-04T15:05:59Zpost28623: Re: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2Mike Gorchakhttp://community.qnx.com/sf/go/post286232009-05-04T14:28:36Z2009-05-04T14:28:36Z> Was this measured using devg-extreme2 ?
Yes.Mike Gorchak2009-05-04T14:28:36Zpost28614: Re: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2Etienne Belanger(deleted)http://community.qnx.com/sf/go/post286142009-05-04T13:34:08Z2009-05-04T13:34:08ZI would expect a difference in performance between GL_SHININESS set to 0 and GL_SHININESS set to other values because in the first case, we can avoid the exponentiation. However, it does seem odd that the performance would be proportional to the GL_SHININESS.
Was this measured using devg-extreme2 ?Etienne Belanger(deleted)2009-05-04T13:34:08Zpost28608: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyEtienne Belanger(deleted)http://community.qnx.com/sf/go/post286082009-05-04T13:26:44Z2009-05-04T13:26:44ZThe OpenGL 1.3 spec gives the following lighting equation (I assume this is what you were referring to...)
[...]
If c_es = SINGLE COLOR, then the equations to compute c_pri and c_sec are
c_pri = e_cm + a_cm * a_cs + sum(i=0..n-1, att_i * spot_i * [a_cm * a_cli + (n dot VP_pli) * d_cm * d_cli + f_i * exp(n dot h_i, s_rm) * s_cm * s_cli])
csec = (0; 0; 0; 0)
[...]
I looked at the software renderer and it does implement the above equation.
What is the value of the ambient color of the material ?
What is the state of the GL_COLOR_MATERIAL cap ?
What is the state of the GL_LIGHT[0..7] caps ?
If GL_COLOR_MATERIAL is enabled,
What is the color material mode for the GL_FRONT, GL_BACK faces ?
What is the state of the GL_COLOR_ARRAY cap ?
If GL_COLOR_ARRAY is disabled, what is the current color (glColor4f) ?
If GL_COLOR_ARRAY is enabled, what are the colors stored in the array ?
Once we know what is the value of a_cm, we can determine if the results of the lighting calculation with GL_LIGHT_MODEL_AMBIENT set to (1; 1; 1; 1) is correct or not, assuming no other lights are enabled.Etienne Belanger(deleted)2009-05-04T13:26:44Zpost28579: RE: OpenGL ES Tutorials/Lessons/CodesamplesDerek Leachhttp://community.qnx.com/sf/go/post285792009-05-04T06:43:16Z2009-05-04T06:43:16Zvery cool :)
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Sat 02/05/2009 1:42 AM
To: opengles-graphics
Subject: OpenGL ES Tutorials/Lessons/Codesamples
This weekend I have a lot of free time and continue working on misc OpenGL ES stuff. Everything I have ported is located here: http://embedded.org.ua/opengles/lessons.html
Check them out :) !
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post28559Derek Leach2009-05-04T06:43:16Zpost28562: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2Mike Gorchakhttp://community.qnx.com/sf/go/post285622009-05-02T17:26:38Z2009-05-02T17:26:38ZIf GL_SHININESS is set to default 0.0f parameter all work well, if I tried to slightly increase it to 1.0f I can see almost twice perfomance loss, if I set it to 5.0f I can see 5x perfomance loss.
Why GL_SHININESS affects perfomance so much ?Mike Gorchak2009-05-02T17:26:38Zpost28561: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectlyMike Gorchakhttp://community.qnx.com/sf/go/post285612009-05-02T17:14:58Z2009-05-02T17:14:58ZDefault GL_LIGHT_MODEL_AMBIENT equals to {0.2f, 0.2f, 0.2f, 1.0f} and it affects to light equation calculation more than it must affect. For example if GL_LIGHT_MODEL_AMBIENT equals to {1.0f, 1.0f, 1.0f, 1.0f} I will get maximum bright color without any shadings, but look into the color computation equation when lighting is enabled, you'll see that GL_LIGHT_MODEL_AMBIENT must not affect so dramatic to the result color.
The same behavior using software renderer and hardware renderer provided by devg-extreme2.Mike Gorchak2009-05-02T17:14:58Zpost28559: OpenGL ES Tutorials/Lessons/CodesamplesMike Gorchakhttp://community.qnx.com/sf/go/post285592009-05-02T05:42:05Z2009-05-02T05:42:05ZThis weekend I have a lot of free time and continue working on misc OpenGL ES stuff. Everything I have ported is located here: http://embedded.org.ua/opengles/lessons.html
Check them out :) !Mike Gorchak2009-05-02T05:42:05Zpost28299: Fog and devg-extreme2Mike Gorchakhttp://community.qnx.com/sf/go/post282992009-04-29T04:28:04Z2009-04-29T04:28:04ZWhile using devg-extreme2 fog (GL_EXP, GL_EXP2 and GL_LINEAR) is rendered incorrectly, fog distance is completely ignored, fog density and fog colour are used to be as texture colour modulation, independently from object distance.
At the same time, software renderer works well with all fog modes.Mike Gorchak2009-04-29T04:28:04Zpost28108: Re: Any comments on OpenGL ES issues ?Mike Gorchakhttp://community.qnx.com/sf/go/post281082009-04-27T07:30:47Z2009-04-27T07:30:47Z> The main 3D guys is on vacation, and the other one is extremely busy at the
> moment. I will review the topics, but I am no 3D expert ...
Any news about main 3D guys availability ? :)Mike Gorchak2009-04-27T07:30:47Zpost27828: Re: devg-extreme2 is omitting points when glDrawArrays() is executing.Logan Fraserhttp://community.qnx.com/sf/go/post278282009-04-22T20:14:39Z2009-04-22T20:14:39ZHi I work with Kevin Raymond and I came across the problem of invisible points in i830 in QNX 6.4 with a core duo machine while writing a program that uses OpenGL to draw a simple set of points in 2D. I modified the photon GL gears app to showcase this problem, if you run it with gma9xx you can see one of the gears, in i830 you see nothing. I will attach the program and quote the included README:
---------------------------------------------------------------------
This code demonstrates the issue with the i830 driver in QNX. Tested in i830 display on a Core Duo with intel 945 integrated graphics.
When run in i830 with 16M color (we have found this configuration the most stable) you will see a black screen.
When run with gma9xx with 32K color (16M crashes QNX sometimes..) you do see the green gear in the bottom right part of the screen drawn as faint points.
The problem at hand seems to be that in the i830 driver QNX will not render GL_POINTS on plane z=0. This is incorrect behaviour as all other OpenGL implementations render GL_POINTS at z=0. Doing a glTranslatef(0.0, 0.0, -1.0) will allow the points to show up but in some cases it is important to render with 0 depth.
--- Card from pci -v -------
Class = Display (VGA)
Vendor ID = 8086h, Intel Corporation
Device ID = 2772h, 82945G/GZ Integrated Graphics Controller
PCI index = 0h
PCI Mem Address = ffa80000h enabled
PCI IO Address = ec00h enabled
PCI Mem Address = e0000000h enabled
PCI Mem Address = ffa40000h enabled
PCI Int Pin = INT A
Interrupt line = 5
CPU Interrupt = 5hLogan Fraser2009-04-22T20:14:39Zpost27571: glClear(GL_COLOR_BUFFER_BIT) using devg-i830 graphics driverMike Gorchakhttp://community.qnx.com/sf/go/post275712009-04-21T08:23:08Z2009-04-21T08:23:08ZIf render target is created using gf_3d_target_create(), and gf_3d_target_create() has allocated two buffers for double buffering sometimes glClear() call is ignored for the GL_COLOR_BUFFER_BIT and framebuffer is left uncleared. This issue could be reproduced if egl-intermix for example has been executed few times consequently.Mike Gorchak2009-04-21T08:23:08Zpost27318: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post273182009-04-17T05:59:38Z2009-04-17T05:59:38ZI've added pauses between each triangle rendering and glFlush() after each glDrawArrays() call. When eglSwapInterval() is set to 0 and gf_3d_target_create() allocates two surfaces for double buffering, I am able to see how hidden faces are rendered first, and then how front faces are rendered. So it is definitely a bug, GLES renders to visible buffer, but not to back buffer.Mike Gorchak2009-04-17T05:59:38Zpost27225: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post272252009-04-16T13:59:28Z2009-04-16T13:59:28ZI'll rewrite my code to do all stuff like in the gf_3d_target_create(). Thanks!
Regarding double buffer flickering issue, you will not able to see how it flickers while using vmware driver, according to this source :) This must be tested on the real hardware ...Mike Gorchak2009-04-16T13:59:28Zpost27214: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post272142009-04-16T13:30:28Z2009-04-16T13:30:28Zcpu fast access and 3D accessible, but lets not mix words, here's the source :)
int
gf_3d_target_create(gf_3d_target_t *ptarget, gf_layer_t layer,
gf_surface_t *surfaces, int nsurfaces,
int width, int height, gf_format_t format)
{
struct _gf_3d_target *target;
int arraysize;
int rc = GF_ERR_OK;
gf_dev_t gdev = layer->display->gdev;
GF_ASSERT(!gf_dev_islocked(gdev));
if (surfaces == NULL) {
nsurfaces = 1;
}
arraysize = sizeof(surfaces) * (nsurfaces < 2 ? 2 : nsurfaces);
target = calloc(1, sizeof(*target) + arraysize);
if (target == NULL) {
return GF_ERR_MEM;
}
target->surfaces = (void *)(target + 1);
if (surfaces == NULL) {
/*
* Create drawing surfaces that can both be displayed on
* the given layer, and targeted by the 3D engine
*/
if ((rc = gf_surface_create_layer(&target->surfaces[0], &layer, 1, 0,
width, height, format, NULL,
GF_SURFACE_CREATE_3D_ACCESSIBLE)) != GF_ERR_OK) {
free(target);
return rc;
}
target->internal_alloced[0] = 1;
} else {
memcpy(target->surfaces, surfaces, arraysize);
}
target->nsurfaces = nsurfaces;
/* Try to allocate a second surface for double buffering */
if (nsurfaces < 2) {
disp_3d_caps_t caps;
unsigned flags = GF_SURFACE_CREATE_3D_ACCESSIBLE;
if (gdev->rendf.query_caps) {
gdev->rendf.query_caps(gdev->handle_3d, &caps);
}
if (!(caps.flags & DISP_3D_CAP_ACCEL)) {
flags |= GF_SURFACE_CREATE_CPU_FAST_ACCESS;
}
if (gf_surface_create_layer(&target->surfaces[1], &layer, 1, 0,
width, height, format, NULL,
flags) == GF_ERR_OK) {
target->nsurfaces++;
target->internal_alloced[1] = 1;
} else {
/*
* Cannot allocate two layer-displayable surfaces,
* and therefore cannot double-buffer. Allocate
* a non-layer displayable surface, so that the
* the OpenGL ES library can blit from the
* back-buffer to the displayable buffer instead.
*/
if ((rc = gf_surface_create(&target->surfaces[1],
gdev, width, height, format, NULL,
flags)) != GF_ERR_OK) {
goto fail;
}
target->nsurfaces++;
target->internal_alloced[1] = 1;
}
}
target->width = width;
target->height = height;
target->layer = layer;
target->swap_layer = swap_layer;
*ptarget = target;
return GF_ERR_OK;
fail:
if (target->internal_alloced[0]) {
gf_surface_free(target->surfaces[0]);
}
free(target);
return rc;
}Derek Leach2009-04-16T13:30:28Zpost27212: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post272122009-04-16T13:26:40Z2009-04-16T13:26:40Zok, I will debug devg-vmware.so ... to see what I can do, because it's the only option I have at the moment ...
-DerekDerek Leach2009-04-16T13:26:40Zpost27211: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post272112009-04-16T13:24:37Z2009-04-16T13:24:37Z> What are you passing for the flags value to gf_surface_create_layer()? This
> is rather odd ... hmmm ...
Derek, by the way, with which flags gf_3d_target_create() is creating surfaces for 3D rendering by default if surfaces are not passed to this function ?
What gf_3d_target_create() will do if only first surface is allocated and second allocation was failed ?Mike Gorchak2009-04-16T13:24:37Zpost27204: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post272042009-04-16T12:59:24Z2009-04-16T12:59:24ZThe flags are GF_SURFACE_CREATE_2D_ACCESSIBLE | GF_SURFACE_CREATE_3D_ACCESSIBLE | GF_SURFACE_CREATE_SHAREABLEMike Gorchak2009-04-16T12:59:24Zpost27203: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post272032009-04-16T12:53:37Z2009-04-16T12:53:37Z> OK, I am running in argb8888 ... but I am using vmware ... what are you
> passing to gf_surface_create_layer()? I assume that is what is failing in
> this case ...
This is updated testsprite2 test, but it doesn't work with the devg-vmware or devg-svga. And I doubt that you can see flickering under VMWare ...Mike Gorchak2009-04-16T12:53:37Zpost27202: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post272022009-04-16T12:48:18Z2009-04-16T12:48:18ZWhat are you passing for the flags value to gf_surface_create_layer()? This is rather odd ... hmmm ...Derek Leach2009-04-16T12:48:18Zpost27198: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post271982009-04-16T12:43:28Z2009-04-16T12:43:28Z> OK, I am running in argb8888 ... but I am using vmware ... what are you
> passing to gf_surface_create_layer()? I assume that is what is failing in
> this case ...
Under my VMWare 6.0.0 build-45731 it prints "Couldn't create renderer: unsufficient free video memory". I'm using VMWare very rare, so did not tested on it well. As far as I understand the same will be using SVGA driver, since it doesn't provide video memory allocation.
At this point, where error is printed, I'm trying to allocate second frame buffer and then to pass both buffers to gf_3d_target_create().Mike Gorchak2009-04-16T12:43:28Zpost27197: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post271972009-04-16T12:30:35Z2009-04-16T12:30:35ZOK, I am running in argb8888 ... but I am using vmware ... what are you passing to gf_surface_create_layer()? I assume that is what is failing in this case ...Derek Leach2009-04-16T12:30:35Zpost27196: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post271962009-04-16T12:25:35Z2009-04-16T12:25:35Z> OK, I am getting this:
> ./testsprite2 --vsync --renderer opengl_es
> Couldn't create renderer: GF: Can't create main layer surface
> Any ideas? I can run egl-gears OK ...
This is similar to my issue with devg-radeon: http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.advanced_graphics.topc6683 .
Try to change color depth in the photon to 16 or 32 bpp, and then exit from photon to text mode, or manually fix it in the display.conf.Mike Gorchak2009-04-16T12:25:35Zpost27195: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post271952009-04-16T12:10:35Z2009-04-16T12:10:35ZOK, I am getting this:
./testsprite2 --vsync --renderer opengl_es
Couldn't create renderer: GF: Can't create main layer surface
Any ideas? I can run egl-gears OK ...Derek Leach2009-04-16T12:10:35Zpost27191: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post271912009-04-16T11:54:49Z2009-04-16T11:54:49ZYes, this issue could be reproduced on any hardware, including software renderer.Mike Gorchak2009-04-16T11:54:49Zpost27190: Re: Double buffering in OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post271902009-04-16T11:51:41Z2009-04-16T11:51:41ZMike, do you see similar issues using devg-soft3d.so? I only have access to that renderer at the moment.
-DerekDerek Leach2009-04-16T11:51:41Zpost27189: RE: Any comments on OpenGL ES issues ?Derek Leachhttp://community.qnx.com/sf/go/post271892009-04-16T11:49:54Z2009-04-16T11:49:54ZI prefer artillery myself ;)
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Thu 16/04/2009 7:34 AM
To: opengles-graphics
Subject: Re: Any comments on OpenGL ES issues ?
> The main 3D guys is on vacation, and the other one is extremely busy at the
> moment. I will review the topics, but I am no 3D expert ...
"Aviation will not take a part in this war, because pilot is ill" :)
Thanks, Derek. The most important topic for me is flickering (framebuffer clearance) when double buffering is on and synchronization on vsync is off.
This one: http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.opengl_es.topc6891
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post27184Derek Leach2009-04-16T11:49:54Zpost27186: Re: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!Derek Leachhttp://community.qnx.com/sf/go/post271862009-04-16T11:37:05Z2009-04-16T11:37:05ZOk, looking at the source, min_filter is initialized to be:
GL_NEAREST_MIPMAP_LINEAR
and mag_filter is:
GL_LINEAR
I seen you second response here, and maybe there is corruption in the driver, and an "off by 1" indexing issue ...
-DerekDerek Leach2009-04-16T11:37:05Zpost27184: Re: Any comments on OpenGL ES issues ?Mike Gorchakhttp://community.qnx.com/sf/go/post271842009-04-16T11:34:34Z2009-04-16T11:34:34Z> The main 3D guys is on vacation, and the other one is extremely busy at the
> moment. I will review the topics, but I am no 3D expert ...
"Aviation will not take a part in this war, because pilot is ill" :)
Thanks, Derek. The most important topic for me is flickering (framebuffer clearance) when double buffering is on and synchronization on vsync is off.
This one: http://community.qnx.com/sf/discussion/do/listPosts/projects.graphics/discussion.opengl_es.topc6891Mike Gorchak2009-04-16T11:34:34Zpost27182: Re: Any comments on OpenGL ES issues ?Derek Leachhttp://community.qnx.com/sf/go/post271822009-04-16T11:18:38Z2009-04-16T11:18:38ZThe main 3D guys is on vacation, and the other one is extremely busy at the moment. I will review the topics, but I am no 3D expert ...
Thanks,
-DerekDerek Leach2009-04-16T11:18:38Zpost27181: Any comments on OpenGL ES issues ?Mike Gorchakhttp://community.qnx.com/sf/go/post271812009-04-16T11:16:30Z2009-04-16T11:16:30ZSorry for useless topic, but maybe someone will comment issues which I've found ?Mike Gorchak2009-04-16T11:16:30Zpost26742: Re: Stencil problem with devg-extreme2 on 82852GMMike Gorchakhttp://community.qnx.com/sf/go/post267422009-04-13T10:53:43Z2009-04-13T10:53:43ZForgot to mention, that stencil in software OpenGL ES implementation is also broken, not only using devg-extreme2 driver.Mike Gorchak2009-04-13T10:53:43Zpost26741: Re: Stencil problem with devg-extreme2 on 82852GMMike Gorchakhttp://community.qnx.com/sf/go/post267412009-04-13T10:51:26Z2009-04-13T10:51:26ZI got some free time to dig deeper into stencil problem. This is a port of http://www.zeuscmd.com/tutorials/opengles/25-Reflections.php tutorial demo for QNX 6.4.x.
This demo shows that in QNX's OpenGL ES implementation stencil buffer is completely broken.
P.S. Is anyone here alive ? Almost 10 days without any comments ...Mike Gorchak2009-04-13T10:51:26Zpost26498: Re: devg-extreme2 is omitting points when glDrawArrays() is executing.Mike Gorchakhttp://community.qnx.com/sf/go/post264982009-04-09T08:53:43Z2009-04-09T08:53:43ZAdditional information. Problem with points disappearing using devg-extreme2 graphics driver could be reproduced if current display color depth is 15 bpp (1555) or 16 bpp (565). But while using 32 bpp depth (8888 format) all works fine.Mike Gorchak2009-04-09T08:53:43Zpost26483: devg-extreme2 is omitting points when glDrawArrays() is executing.Mike Gorchakhttp://community.qnx.com/sf/go/post264832009-04-09T05:01:12Z2009-04-09T05:01:12ZKevin Raymond reports the same problem with devg-gma9xx driver here:
http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc6952
I'm able to reproduce this problem on devg-extreme2, but test application will be in binary form, since it using a lot of dependencies to software which is under development.
The same binaries work fine using software GLES implementation. Under devg-extreme2:
sphere - uses QNX's native egl interface. All points on sphere are drawed correctly.
sdl_sphere - uses SDL which initializes all GLES stuff, like it done in "sphere" test, applications are very similar to each other, even the same. But the sphere located in the middle-bottom has been drawn incorrectly, when sdl_sphere renders sphere of points.
Take a look into it.Mike Gorchak2009-04-09T05:01:12Zpost26267: Re: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!Mike Gorchakhttp://community.qnx.com/sf/go/post262672009-04-07T18:26:37Z2009-04-07T18:26:37ZLooks like problem is deeper than it appears: GL_TEXTURE_MIN_FILTER affect GL_TEXTURE_MAG_FILTER on devg-extreme2. Magnification filter became the same as minimization filter.Mike Gorchak2009-04-07T18:26:37Zpost26266: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!Mike Gorchakhttp://community.qnx.com/sf/go/post262662009-04-07T18:20:21Z2009-04-07T18:20:21ZQuote from OpenGL ES 1.0 specification:
"The initial value of GL_TEXTURE_MAG_FILTER is GL_LINEAR."
Software renderer conforms to this sentence, but hardware renderer which is provided by devg-extreme2 driver uses GL_NEAREST as initial value of GL_TEXTURE_MAG_FILTER, which is wrong.
Maybe GL_TEXTURE_MIN_FILTER parameter must be checked too.Mike Gorchak2009-04-07T18:20:21Zpost26039: Re: Stencil problem with devg-extreme2 on 82852GMMike Gorchakhttp://community.qnx.com/sf/go/post260392009-04-06T08:56:34Z2009-04-06T08:56:34ZDoes glGetFloatv(), which is present in the CM and CL OpenGL ES libraries, but not declared in the headers, works ?
Looks like I have a problem with this, by mistake I used glGetFloatv() function, which is not present in 1.0 OpenGL ES specification, to obtain modelview matrix content, but this function appears to be present in the library ...Mike Gorchak2009-04-06T08:56:34Zpost26038: Re: GLU 1.3 for OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post260382009-04-06T07:00:46Z2009-04-06T07:00:46ZAn updated version of GLU ES is located here: http://glues.googlecode.comMike Gorchak2009-04-06T07:00:46Zpost26002: Stencil problem with devg-extreme2 on 82852GMMike Gorchakhttp://community.qnx.com/sf/go/post260022009-04-03T17:48:55Z2009-04-03T17:48:55ZDoes devg-extreme2 supports hardware stencil operations ? I chose framebuffer config, which has RGBA8888 format with 24 bit depth size and 8 bit stencil size (ID: 6).
My application works on ATI OpenGL ES emulator, QNX's software OpenGL ES implementation, but doesn't work on devg-extreme2. The symptoms are as follows: stencil states and operations are completely ignored, there are no stencil buffer fillings occured during rendering to stencil buffer.Mike Gorchak2009-04-03T17:48:55Zpost25956: RE: GLU 1.3 for OpenGL ESDerek Leachhttp://community.qnx.com/sf/go/post259562009-04-03T11:02:27Z2009-04-03T11:02:27ZHey Mike,
That's cool news, thanks!
-Derek
________________________________
From: Mike Gorchak [mailto:community-noreply@qnx.com]
Sent: Fri 03/04/2009 6:59 AM
To: opengles-graphics
Subject: GLU 1.3 for OpenGL ES
Not all GLU functions could be ported to OpenGL ES, especially nurbs, but libutil (GLU component) has been ported almost completely. Here is the list of supported functions:
gluCheckExtension();
gluCylinder();
gluDeleteQuadric();
gluDisk();
gluErrorString();
gluGetString();
gluLookAt();
gluNewQuadric();
gluOrtho2D();
gluPartialDisk();
gluPerspective();
gluPickMatrix();
gluProject();
gluQuadricCallback();
gluQuadricDrawStyle();
gluQuadricNormals();
gluQuadricOrientation();
gluQuadricTexture();
gluSphere();
gluUnProject();
gluUnProject4();
gluScaleImage();
gluBuild2DMipmapLevels();
gluBuild2DMipmaps();
In the attachment complete source code of this port. Archive also have few tests for GLU functions. Source code is under "SGI FREE SOFTWARE LICENSE B." license.
_______________________________________________
OpenGL ES
http://community.qnx.com/sf/go/post25955Derek Leach2009-04-03T11:02:27Zpost25955: GLU 1.3 for OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post259552009-04-03T10:59:12Z2009-04-03T10:59:12ZNot all GLU functions could be ported to OpenGL ES, especially nurbs, but libutil (GLU component) has been ported almost completely. Here is the list of supported functions:
gluCheckExtension();
gluCylinder();
gluDeleteQuadric();
gluDisk();
gluErrorString();
gluGetString();
gluLookAt();
gluNewQuadric();
gluOrtho2D();
gluPartialDisk();
gluPerspective();
gluPickMatrix();
gluProject();
gluQuadricCallback();
gluQuadricDrawStyle();
gluQuadricNormals();
gluQuadricOrientation();
gluQuadricTexture();
gluSphere();
gluUnProject();
gluUnProject4();
gluScaleImage();
gluBuild2DMipmapLevels();
gluBuild2DMipmaps();
In the attachment complete source code of this port. Archive also have few tests for GLU functions. Source code is under "SGI FREE SOFTWARE LICENSE B." license.Mike Gorchak2009-04-03T10:59:12Zpost25755: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post257552009-04-01T13:53:21Z2009-04-01T13:53:21ZMaybe I'm wrong, but it looks like rendering surface and visible surface in double buffer mode is the same and when eglSwapBuffers() switches to new buffer it sets new surface as visible and as rendering target at the same time.Mike Gorchak2009-04-01T13:53:21Zpost25754: Re: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post257542009-04-01T13:45:39Z2009-04-01T13:45:39ZArgh, you can test it easy by commenting out three glMaterial calls in the gf-ph-3d example. In this case default material settings must be used.Mike Gorchak2009-04-01T13:45:39Zpost25751: Re: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post257512009-04-01T13:35:03Z2009-04-01T13:35:03Z> Can you provide a small example that shows this ?
Yes, within one day.
> -Did you provide a valid glNormalPointer before issuing glDrawArrays
Yes, I have tried to setup global glNormal3f() and per-vertex normals via glNormalPointer - there is no difference.
> -Is the GL_NORMAL_ARRAY enabled with glEnableClientState
In case if glNormalPointer used, yes, it is enabled.
> -What is the GL_MODELVIEW_MATRIX used
Sorry, but I have no my example sources right now.
> -Is fog/texturing enabled or disabled
Fog is disabled, and there is no difference in shading (no shading) nor when texturing is enabled nor is disabled.Mike Gorchak2009-04-01T13:35:03Zpost25741: Re: Something wrong with default Materials settings in QNX's OpenGL ESEtienne Belanger(deleted)http://community.qnx.com/sf/go/post257412009-04-01T12:39:49Z2009-04-01T12:39:49ZCan you provide a small example that shows this ?
Some things to verify:
-Did you provide a valid glNormalPointer before issuing glDrawArrays
-Is the GL_NORMAL_ARRAY enabled with glEnableClientState
-What is the GL_MODELVIEW_MATRIX used
-Is fog/texturing enabled or disabledEtienne Belanger(deleted)2009-04-01T12:39:49Zpost25740: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceEtienne Belanger(deleted)http://community.qnx.com/sf/go/post257402009-04-01T12:32:39Z2009-04-01T12:32:39ZUnfortunately, eglWaitNative() also does nothing. You would have to add gf_draw_finish, or replace any gf_draw_flush with gf_draw_finish before gf_draw_end. However, that only covers for the rendering that you are doing...
The correct implementation would have to wait on all operations, including the ones from other processes. As far as I know, the GF API (our "native" API) doesn't have a wait idle function, which is why eglWaitNative can't do anything for now.
Nevertheless, in the gf-ph-3d example, I don't think this is an issue because the framework waits for operations to complete before calling the work_proc, so the call to eglWaitNative may not be necessary.Etienne Belanger(deleted)2009-04-01T12:32:39Zpost25729: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post257292009-04-01T05:32:44Z2009-04-01T05:32:44ZHow to use attached example:
Do not run photon, just run in the plain console.
1) run ./testsprite2 --vsync --renderer opengl_es
eglSwapInterval() is set to 1 in this case. You can see moving 2D sprites (instead of sprites will be the trash, I still working on opengl_es 2D renderer) without blinking.
2) run ./testsprite2 --renderer opengl_es
eglSwapInterval() is set to 0 in this case. You can see blinking 2D sprites while double buffering is enabled. While using software OpenGL ES renderer, only left-bottom side (why only left-bottom ?) of screen is blinking when sprites are moving. While using hardware OpenGL ES renderer (In my case it is devg-extreme2 on 82852GM) all sprites are blinking.
Run photon and run the ./testsprite2 --renderer opengl_es - this how "present copy" works using one buffer only. There are no any blinking sprites, all works fine.Mike Gorchak2009-04-01T05:32:44Zpost25727: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post257272009-04-01T04:44:00Z2009-04-01T04:44:00Z> It's very difficult to distinguish between a presentation blit and a simple
> buffer clear going on. Perhaps you can try adding some geometry to the scene
> to see if scene elements build up on you, or if it is just the final blit that
> you see in progress.
I've found two rendered images in my buffers, so OpenGL ES definitely uses two buffers. But when I set eglSwapInterval() to zero, I can see buffer clear operation visually. I will post a binary example soon to show the problem.Mike Gorchak2009-04-01T04:44:00Zpost25726: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceMike Gorchakhttp://community.qnx.com/sf/go/post257262009-04-01T04:36:13Z2009-04-01T04:36:13Z> The problem is that eglWaitGL is stubbed out. I don't know why inserting it at
> different locations fixes your problem. It probably didn't; just changed the
> timing a little bit.
Thanks for the eglWaitGL() internals explanation :) Dunno why, but it really helps to avoid lockups in my application running on 82852GM. You are right, it adds some very small delays in code execution...
eglWaitNative() also does nothing ?Mike Gorchak2009-04-01T04:36:13Zpost25719: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceEtienne Belanger(deleted)http://community.qnx.com/sf/go/post257192009-03-31T19:24:36Z2009-03-31T19:24:36Zgf-ph-3d does all the right calls to ensure the presentation blits and 3D rendering are serialized. However, you may be right when you say that you nevertheless observe simultaneous buffer access by the 3D and 2D engines.
The problem is that eglWaitGL is stubbed out. I don't know why inserting it at different locations fixes your problem. It probably didn't; just changed the timing a little bit.
Pending the resolution of this issue, you should replace eglWaitGL with glFinish, or simply add a glFinish before eglWaitGL in your work_proc.Etienne Belanger(deleted)2009-03-31T19:24:36Zpost25710: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceMisha Nefedovhttp://community.qnx.com/sf/go/post257102009-03-31T18:38:43Z2009-03-31T18:38:43ZYour analysis of what gf-ph-3d does is wrong. This application is not multi-threaded. The raw widget doesn’t render 3d scene – it merely copies the content of the 3d frame buffer to the current photon’s render context (which will take care of calculation what part of the window is actually visible and so on) when it is told to do so. It calls the PgWaitHWIdle() to make sure that the blit is actually done before the work_proc() will render the next frame. The work_proc() works when it has a chance, sequentially, not in parallel to the blit.Misha Nefedov2009-03-31T18:38:43Zpost25709: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceMike Gorchakhttp://community.qnx.com/sf/go/post257092009-03-31T18:09:09Z2009-03-31T18:09:09ZMaybe this could help you, I think OpenGL ES gears demo for photon (gf-ph-3d) is bad example by design, it uses widget damage routine to draw OpenGL ES backbuffer in place of PtRaw widget in same time when some GL drawings are performing in the work_proc() routine.
Looks like 82852GM has an issue with simultaneous frame buffer access by 2D and by 3D engines, or has problem with hardware graphics pipe when executing mixed 2D and 3D commands without flushing after transition from 2D mode to 3D and vice versa. Since I added eglWaitGL() as first function of raw_draw_f() callback, there are no any lockups during last two hours. But this patch looks weak on multi-processor machines.Mike Gorchak2009-03-31T18:09:09Zpost25594: Re: devg-extreme2 on 82852GM Intel integrated graphics deviceMichael Van Reenenhttp://community.qnx.com/sf/go/post255942009-03-30T18:10:27Z2009-03-30T18:10:27ZWe've filed a PR for this issue on your behalf. (PR # 66876)Michael Van Reenen2009-03-30T18:10:27Zpost25521: Re: GL_RENDERER in my application and in the egl-gearsEtienne Belanger(deleted)http://community.qnx.com/sf/go/post255212009-03-30T13:17:08Z2009-03-30T13:17:08ZThere is a problem with the information provided by egl-gears when the -info command line option is supplied. It calls glGetString before creating an OpenGL ES context, and before even doing eglGetDisplay. This is why it always inaccurately reports soft3d.Etienne Belanger(deleted)2009-03-30T13:17:08Zpost25507: devg-extreme2 on 82852GM Intel integrated graphics deviceMike Gorchakhttp://community.qnx.com/sf/go/post255072009-03-30T06:10:35Z2009-03-30T06:10:35ZI noticed recently problem with devg-extreme2 stability while using on Intel 82852GM integrated graphics device on LexSystem CI852A embedded SBC (pci -vvv output is attached).
After 10-20 consecutive runs of apllication which uses OpenGL ES (egl-ph-gears or egl-gears, for example), application hangs with all graphics stuff, only net and keyboard still work. It could hang at gf_display_detach() or gf_dev_attach() function calls (maybe during hardware initialization), but in another time it could hang somwhere inside rendering.
Bug could be reproduced easily when you will run egl-ph-gears and will try to resize window size (maximize/restore). Sometimes 30-40 resizes is enough to hang graphics driver.
While using the same graphics driver devg-extreme2 on 82865G (desktop chipset) all work fine, without any lockups.Mike Gorchak2009-03-30T06:10:35Zpost25504: Something wrong with default Materials settings in QNX's OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post255042009-03-30T05:17:39Z2009-03-30T05:17:39ZWhen FLAT or SMOOTH shading is enabled, there are no any shading performed if lighting is enabled via glEnable(GL_LIGHTING). Looks like QNX's OpenGL ES implementation have wrong initial values for materials. GL ES specs says:
GL_AMBIENT must be set to (0.2, 0.2, 0.2, 1.0).
GL DIFFUSE must be set to (0.8, 0.8, 0.8, 1.0).
GL_SPECULAR must be set to (0, 0, 0, 1).
GL EMISSION must be set to (0, 0, 0, 1).
GL SHININESS must be set to 0.
Or if no any of material parameters are set QNX's OpenGL ES implementation switches off materials or they are not used in the lighting equation if they are not set.Mike Gorchak2009-03-30T05:17:39Zpost25497: GL_RENDERER in my application and in the egl-gearsMike Gorchakhttp://community.qnx.com/sf/go/post254972009-03-28T12:14:57Z2009-03-28T12:14:57ZI'm using LexSystem CI852A SBC, which has Intel 80852 integrated graphics. Default graphics driver in my system is devg-extreme2, which is 3D accelerated.
egl-gears -info produces this information:
GL_RENDERER = Software Rasterizer
GL_VERSION = OpenGL ES-CM 1.0
GL_VENDOR = QNX Software Systems
GL_EXTENSIONS = GL_OES_compressed_paletted_texture GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format
While my application tries to obtain GL_xxxx strings it get:
Vendor : QNX Software Systems
Renderer : Intel 82830/82845/82852/82855/82865
Version : OpenGL ES-CM 1.0
Extensions : GL_OES_compressed_paletted_texture GL_OES_vertex_buffer_object GL_OES_query_matrix GL_OES_read_format
In both cases all OpenGL ES output is accelerated.
But on devg-svga driver GL_RENDERER string is "Unaccelerated ....", so I do not know where egl-gears got GL_RENDERER string.Mike Gorchak2009-03-28T12:14:57Zpost25446: Re: Switch between accelerated and unaccelerated OpenGL ES implementationsMike Gorchakhttp://community.qnx.com/sf/go/post254462009-03-27T13:11:42Z2009-03-27T13:11:42ZYes, I want to use reference software rasterizer in debugging purpouses, to check if my error in rasterization has been caused by hardware errors/bugs in graphics driver or my error has been caused by my incorrect OpenGL ES usage.Mike Gorchak2009-03-27T13:11:42Zpost25443: Re: Switch between accelerated and unaccelerated OpenGL ES implementationsEtienne Belanger(deleted)http://community.qnx.com/sf/go/post254432009-03-27T13:04:12Z2009-03-27T13:04:12ZIs there a specific reason for wanting to switch between accelerated and non-accelerated rendering ?Etienne Belanger(deleted)2009-03-27T13:04:12Zpost25441: Re: eglChooseConfig and vmwareEtienne Belanger(deleted)http://community.qnx.com/sf/go/post254412009-03-27T13:01:14Z2009-03-27T13:01:14ZEGL_RENDERABLE_TYPE is defined in the EGL specification. It was introduced in version 1.2, when support for OpenVG was added.
The best thing to do in an application is to get major and minor version numbers when calling eglInitialize and use EGL_RENDERABLE_TYPE when the version number is 1.2 or greater.
Note that the existing EGL implementation in QNX will return version 1.2, but is not fully compliant with the 1.2 spec. EGL_RENDERABLE_TYPE is one of those non-compliant areas. All EGL configs are OpenGL ES 1 renderable, but trying to use the EGL_RENDERABLE_TYPE enum will result in an error.Etienne Belanger(deleted)2009-03-27T13:01:14Zpost25417: Feature request: GL_BGR/GL_BGRA/GL_ABGR extensions for OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post254172009-03-27T05:41:30Z2009-03-27T05:41:30ZIt would be nice to have GL_BGR/GL_BGRA/GL_ABGR extensions in QNX's OpenGL ES implementation, since often required to swap B, R and A channels around before texture loading.Mike Gorchak2009-03-27T05:41:30Zpost25407: eglChooseConfig and vmwareMario Mastrodicasahttp://community.qnx.com/sf/go/post254072009-03-26T21:16:47Z2009-03-26T21:16:47ZI've tried to use the sample demo gf-ph-3d under vmware.
I've applied a little modification to the parameter used to query a suitable configuration. In particular I've added a request for a type:
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT
but using this element in the attrib_list passed to eglChooseConfig it fails.
I have searched about EGL_RENDERABLE_TYPE parameter on http://www.khronos.org/opengles/documentation/opengles1_0/html/eglChooseConfig.html and it isn't present, but other implementation use it.
where is my error?
is there an error in my is Vmware driver unable to use that parameter or is it a bug in the qnx implementation?
As attachment my modified file.
Thanks,
Mario.Mario Mastrodicasa2009-03-26T21:16:47Zpost25334: Re: Double buffering in OpenGL ESEtienne Belanger(deleted)http://community.qnx.com/sf/go/post253342009-03-26T14:04:40Z2009-03-26T14:04:40ZIt's very difficult to distinguish between a presentation blit and a simple buffer clear going on. Perhaps you can try adding some geometry to the scene to see if scene elements build up on you, or if it is just the final blit that you see in progress.Etienne Belanger(deleted)2009-03-26T14:04:40Zpost25323: Re: Double buffering in OpenGL ESMike Gorchakhttp://community.qnx.com/sf/go/post253232009-03-26T13:41:56Z2009-03-26T13:41:56ZStrange, but I can see full buffer clearence while double buffer is on. I'll check my code of buffers creation one more.Mike Gorchak2009-03-26T13:41:56Z