Feed for discussion OpenGL ES in project Graphics.

post117040: Re: QNX SDK Apps and Media 1.1 supports Intel HD4400 GPU?

Gao Zhining(deleted) — Tue, 01 Nov 2016 03:17:06 GMT

Yes， The QNX for Apps and Media 1.1 supports Intel HD4400 GPU.

post116981: QNX SDK Apps and Media 1.1 supports Intel HD4400 GPU?

Gao Zhining(deleted) — Tue, 18 Oct 2016 02:49:19 GMT

The 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.

post116384: I can't get access to sources repository

Evgenii Startcev(deleted) — Mon, 06 Jun 2016 11:38:45 GMT

I 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?

post110781: Re: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915

Bettina Kurz-Kalweit(deleted) — Fri, 20 Jun 2014 11:17:23 GMT

It 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!

Bettina

post110763: Re: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915

Leo Xu(deleted) — Thu, 19 Jun 2014 14:28:01 GMT

You should run drm server (drm-intel) first before running screen.

post110745: running openGLES2 apps with screen-api on generic x86 desktop pc with intel i915

Bettina Kurz-Kalweit(deleted) — Wed, 18 Jun 2014 12:50:44 GMT

Hello 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 & Regards

post110271: qnx car 2.1 opengles 2

Rohit Nandan(deleted) — Mon, 12 May 2014 11:57:10 GMT

I 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.

post109855: RE: Screen on Kontron nanoETXexpress-TT

Joel Pilon(deleted) — Tue, 08 Apr 2014 17:35:55 GMT

The 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.com

post109847: Screen on Kontron nanoETXexpress-TT

Alexander Lipin(deleted) — Tue, 08 Apr 2014 12:59:50 GMT

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.

post109838: OpenGL ES 2.0 performance issues on 6.6.0

Alexander Lipin(deleted) — Tue, 08 Apr 2014 07:07:52 GMT

Hi, 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.

post109668: RE: Multy display opengl es 660

Joel Pilon(deleted) — Fri, 28 Mar 2014 15:01:01 GMT

The 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.com

post109657: Multy display opengl es 660

Eugene Strizhov(deleted) — Fri, 28 Mar 2014 07:08:45 GMT

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?

post106088: Intel GMA 3150/devg-i830/OpenGL ES support

Jim Douglas — Mon, 21 Oct 2013 10:24:44 GMT

Hi,

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.

Jim

post104914: eglCreateWindowSurface returns EGL_BAD_MATCH - GLESv2

denis demidov — Sat, 07 Sep 2013 12:10:35 GMT

target: 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.

post104103: pbuffer on OpenGL ES 2.0

Philip Endaya — Mon, 12 Aug 2013 13:01:54 GMT

Hello,

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,

Philip

post103415: RE: RE: Open GL ES 1.4

Derek Leach — Mon, 22 Jul 2013 13:50:57 GMT

Please 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.com

post103414: Re: RE: Open GL ES 1.4

sankari G(deleted) — Mon, 22 Jul 2013 13:49:24 GMT

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

post103410: RE: Open GL ES 1.4

Derek Leach — Mon, 22 Jul 2013 13:12:15 GMT

Are 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.com

post103385: Open GL ES 1.4

sankari G(deleted) — Sat, 20 Jul 2013 07:22:58 GMT

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

post103166: Graphics driver for Freescale IM51 EVK

sankari G(deleted) — Sat, 13 Jul 2013 12:10:30 GMT

Hello 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)).

post102930: opengl ES based on screen and screen high cpu lord

Zhan Chunhuan — Fri, 05 Jul 2013 02:28:59 GMT

Hello,

     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 & Regards

post102727: Re: OpenGL es2.0 question

Etienne Belanger(deleted) — Thu, 27 Jun 2013 15:58:24 GMT

You 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.

post102685: Re: OpenGL es2.0 question

Shawn Zhang(deleted) — Wed, 26 Jun 2013 14:06:59 GMT

Hi 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.

Shawn

post102457: Re: OpenGL es2.0 question

Etienne Belanger(deleted) — Wed, 19 Jun 2013 21:53:14 GMT

You 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.com

post102449: OpenGL es2.0 question

Shawn Zhang(deleted) — Wed, 19 Jun 2013 17:56:58 GMT

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

post96334: Re: OMAP3730 / OpenGL ES

gao yuan(deleted) — Mon, 15 Oct 2012 15:39:41 GMT

I think the graphics_root is wrong.

maybe is

GRAPHICS_ROOT=/usr/lib/graphics/devg/omap3530

post96333: Re: OMAP3730 / OpenGL ES

gao yuan(deleted) — Mon, 15 Oct 2012 15:37:46 GMT

I run the example successed in beagleboard.

post95832: Re: RE: RE: Doesn't compile demos of GF 3D for a Photon

Vadim V — Wed, 26 Sep 2012 12:07:43 GMT

Just it needed some extra libraries. Sorry.

post95579: Re: RE: RE: Doesn't compile demos of GF 3D for a Photon

Vadim V — Fri, 14 Sep 2012 07:57:16 GMT

I 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?

post95527: Re: RE: RE: Doesn't compile demos of GF 3D for a Photon

Vadim V — Wed, 12 Sep 2012 14:09:52 GMT

OK. 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...

post95354: RE: RE: Doesn't compile demos of GF 3D for a Photon

Derek Leach — Tue, 04 Sep 2012 13:11:55 GMT

No, 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.com

post95329: Re: RE: Doesn't compile demos of GF 3D for a Photon

Vadim V — Mon, 03 Sep 2012 07:38:05 GMT

> 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?

post95015: RE: Doesn't compile demos of GF 3D for a Photon

Derek Leach — Wed, 22 Aug 2012 12:39:06 GMT

You 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.com

post95009: Doesn't compile demos of GF 3D for a Photon

Vadim V — Wed, 22 Aug 2012 07:58:18 GMT

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 .

post94278: QT with OpenGL ES on Beagle board

dang tri — Tue, 17 Jul 2012 07:03:58 GMT

Hello 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,

DQT

post93222: Re: FBO flushing

Joel Pilon(deleted) — Sun, 20 May 2012 01:55:17 GMT

That 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.com

post93221: Re: FBO flushing

Chris Keating(deleted) — Sun, 20 May 2012 00:20:17 GMT

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?

post93220: Re: FBO flushing

Joel Pilon(deleted) — Sat, 19 May 2012 23:53:49 GMT

That'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.com

post93219: Re: FBO flushing

Chris Keating(deleted) — Sat, 19 May 2012 23:03:28 GMT

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

post93142: Unable to run gf-egl-vsync Sample on QNX 6.5.0 on VmWare

Arun Krishnan Padmakumar(deleted) — Wed, 16 May 2012 20:18:24 GMT

I 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 Krishnan

post93141: Unable to run gf-egl-vsync Sample

Arun Krishnan Padmakumar(deleted) — Wed, 16 May 2012 20:17:48 GMT

I 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 Krishnan

post93060: Re: glScissor and tiling memory on SGX

Joel Pilon(deleted) — Mon, 14 May 2012 18:00:50 GMT

Keep 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.com

post93056: RE: glScissor and tiling memory on SGX

Chris Keating(deleted) — Mon, 14 May 2012 17:34:42 GMT

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

post93049: Re: glScissor and tiling memory on SGX

Joel Pilon(deleted) — Mon, 14 May 2012 14:18:24 GMT

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

post93046: RE: glScissor and tiling memory on SGX

Derek Leach — Mon, 14 May 2012 13:52:47 GMT

You 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.com

post93044: glScissor and tiling memory on SGX

Chris Keating(deleted) — Mon, 14 May 2012 13:41:10 GMT

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?

post92999: Re: imx53 Quickstart GLES failure

Alberto Fontan — Thu, 10 May 2012 13:54:15 GMT

Hello,

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,

post92930: Re: FBO flushing

Joel Pilon(deleted) — Tue, 08 May 2012 18:48:44 GMT

I'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.com

post92929: Re: FBO flushing

Brian Edmond(deleted) — Tue, 08 May 2012 13:52:04 GMT

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?

post92928: Re: FBO flushing

Joel Pilon(deleted) — Sun, 06 May 2012 20:28:29 GMT

I'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.com

post92927: Re: FBO flushing

Brian Edmond(deleted) — Sun, 06 May 2012 17:25:29 GMT

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

post92926: Re: FBO flushing

Joel Pilon(deleted) — Sun, 06 May 2012 16:47:37 GMT

This 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.com

post92925: FBO flushing

Brian Edmond(deleted) — Sun, 06 May 2012 16:33:02 GMT

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

post92692: run egl-configs: both gles1 and gles 2 are 0

peng liu(deleted) — Mon, 23 Apr 2012 08:39:28 GMT

I 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.

post91825: OMAP3730 / OpenGL ES

Alex Pavloff — Mon, 27 Feb 2012 22:48:28 GMT

Using 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?

post91387: imx53 Quickstart GLES failure

Brian Edmond(deleted) — Tue, 07 Feb 2012 18:56:55 GMT

I 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

Brian

post91285: glBindFramebuffer blocked on pvrsrvd

Brian Edmond(deleted) — Wed, 01 Feb 2012 21:34:59 GMT

I 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?

Brian

post90887: FBO issue on SGX

Brian Edmond(deleted) — Tue, 10 Jan 2012 15:13:41 GMT

Hi,

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?

Brian

post89514: eglChooseConfig unable to find compatible frame buffer configuration

Tony Mahieu(deleted) — Thu, 20 Oct 2011 19:53:51 GMT

I'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.

post89006: Re: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.

Felipe Santana — Wed, 21 Sep 2011 15:54:38 GMT

Hi,

Did you solve that problem, about libGLES and libEGL?

I am facing it right now, and just dont know what to do anymore.

Thx!

post88836: Re: Performace on i.MX53 using OpenGL ES 1.1

John Edwards — Thu, 15 Sep 2011 02:05:10 GMT

Thanks 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.

--john

post88835: Re: Performace on i.MX53 using OpenGL ES 1.1

Jason Mawdsley(deleted) — Thu, 15 Sep 2011 01:00:00 GMT

You 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

>

post88832: Re: Performace on i.MX53 using OpenGL ES 1.1

John Edwards — Wed, 14 Sep 2011 22:12:14 GMT

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

post88369: Invert display

Brian McLaughlin — Thu, 25 Aug 2011 18:31:41 GMT

Our mechanical designer wants to invert the LCD display. Is there a way to invert everything sent to the display?

post88288: EGL and GL has R8 and RG88 definitions. Can we have the similar matching definitions in screen.h?

Leon Xia(deleted) — Tue, 23 Aug 2011 13:52:14 GMT

If 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.

post87959: Unable to compile with openGL ES 2

Mikko Alaluusua — Wed, 10 Aug 2011 08:00:26 GMT

Hi,

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?

post87138: Re: RE: RE: GLES 2.0 on the iMX5x

Stephen Bashford — Wed, 06 Jul 2011 14:53:24 GMT

I 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,

Stephen

post87127: RE: RE: GLES 2.0 on the iMX5x

Gaétan Noël — Wed, 06 Jul 2011 13:53:32 GMT

Can 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/post87074

post87074: Re: RE: GLES 2.0 on the iMX5x

Stephen Bashford — Tue, 05 Jul 2011 15:25:08 GMT

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

post86790: Re: RE: GLES 2.0 on the iMX5x

Brian Edmond(deleted) — Thu, 23 Jun 2011 01:15:59 GMT

Thanks 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,

Brian

post86759: RE: GLES 2.0 on the iMX5x

Gaétan Noël — Tue, 21 Jun 2011 17:14:12 GMT

Hi 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/post86729

post86729: GLES 2.0 on the iMX5x

Brian Edmond(deleted) — Tue, 21 Jun 2011 01:38:12 GMT

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

post86725: Using OpenGL ES

Guido Carballo — Mon, 20 Jun 2011 20:55:37 GMT

Hello;

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

XMobots

post79595: Re: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.

trevor fu — Tue, 21 Dec 2010 16:23:31 GMT

> 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.

post79577: Re: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.

Etienne Belanger(deleted) — Tue, 21 Dec 2010 15:23:50 GMT

There is currently no OpenGL ES 2 support on VMWare.

post79571: help, urgent! - eglChooseConfig works while linking with libGLES_CM but fails while linking with libEGL.

trevor fu — Tue, 21 Dec 2010 15:11:50 GMT

After 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.

post78410: Is this the future of Open GL/ES and QNX ?

Armin Steinhoff — Sun, 12 Dec 2010 15:47:21 GMT

http://www.telecomtv.com/comspace_newsDetail.aspx?n=47024&id=e9381817-0593-417a-8639-c4c53e2a2a10#

post75815: GL Studio support

Alan Zhang(deleted) — Wed, 24 Nov 2010 16:18:45 GMT

Hello,

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,

Alan

post74494: Performace on i.MX53 using OpenGL ES 1.1

Howard Smith(deleted) — Fri, 12 Nov 2010 17:37:20 GMT

Hello,

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,

Howie

post71671: Performance of using VBO in windowless plugin

Yang Jiao — Thu, 21 Oct 2010 08:55:44 GMT

I 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?

post70003: Re: RE: SVN check out ID and Password

JIN YOUNC CHEON — Thu, 07 Oct 2010 23:08:39 GMT

Thank you, Max.

post69857: RE: SVN check out ID and Password

Max Feil — Wed, 06 Oct 2010 22:00:34 GMT

Please 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/post69851

post69851: SVN check out ID and Password

JIN YOUNC CHEON — Wed, 06 Oct 2010 21:15:41 GMT

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.

post69701: Please grant my membership request.

JIN YOUNC CHEON — Wed, 06 Oct 2010 10:12:55 GMT

Hello.

I hope to join the Graphics Project. I am waiting for you grant.

Thanks.

Jin Young.

post67544: RE: the differnce between libgf.so and libgf.so.1

Derek Leach — Thu, 16 Sep 2010 12:08:44 GMT

In 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/post67537

post67537: the differnce between libgf.so and libgf.so.1

Kailen High — Thu, 16 Sep 2010 10:03:10 GMT

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!

post64958: how to dump PbufferSurface into an image file

Ahsan Habib — Mon, 30 Aug 2010 08:09:08 GMT

I want to dump PbufferSurface or GFSurface into a jpeg or bmp format image.

Can someone give demo or example?

Thanks.

post64927: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Pavel Khart — Sat, 28 Aug 2010 20:11:34 GMT

My 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!

post64729: OpenGL ES rendering to memory glReadPixels

Ahsan Habib — Fri, 27 Aug 2010 10:29:17 GMT

Hi 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!

post64722: Re: Frame Buffer creation

Armin Steinhoff — Fri, 27 Aug 2010 07:47:24 GMT

Hi 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/post64701

post64701: Frame Buffer creation

Ahsan Habib — Thu, 26 Aug 2010 22:39:57 GMT

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

post64384: Problem with glTexSubImage2D() creating texture of size 8x32

Glenn Schmottlach — Wed, 25 Aug 2010 18:04:05 GMT

This 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....

post63744: RE: Hardware support for OpenGL ES?

Derek Leach — Fri, 20 Aug 2010 15:30:08 GMT

What 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/post63743

post63743: Hardware support for OpenGL ES?

Michael Kerpan — Fri, 20 Aug 2010 15:28:28 GMT

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?

post63452: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Tom Freedy — Wed, 18 Aug 2010 18:42:00 GMT

I am interested also.

Thanks,

Thomas

post62889: opengl es in browser plugin

Ahsan Habib — Fri, 13 Aug 2010 02:29:12 GMT

I 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.

post62014: Re: RE: eglChooseConfig always get 0 in 4th parameter

Xiongwei Huang — Fri, 06 Aug 2010 14:15:50 GMT

Hi

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 .

post61995: RE: eglChooseConfig always get 0 in 4th parameter

Derek Leach — Fri, 06 Aug 2010 13:11:40 GMT

Is 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/post61943

post61943: Re: eglChooseConfig always get 0 in 4th parameter

Xiongwei Huang — Fri, 06 Aug 2010 01:32:08 GMT

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 .

post61725: Re: eglChooseConfig always get 0 in 4th parameter

Derek Leach — Thu, 05 Aug 2010 13:24:22 GMT

ok, 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?

post61662: eglChooseConfig always get 0 in 4th parameter

Xiongwei Huang — Thu, 05 Aug 2010 01:21:03 GMT

Hi

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 regards

post56358: Re: How to display OpengGL Demos with VMware

Chen ShunLi — Wed, 09 Jun 2010 05:06:19 GMT

More 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.

---------------------------------------------------------------------------------------------------

post56354: Re: How to display OpengGL Demos with VMware

Chen ShunLi — Wed, 09 Jun 2010 04:08:34 GMT

Thanks 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.

---------------------------------------------------------------------------------------------------

post56352: RE: How to display OpengGL Demos with VMware

Joel Pilon(deleted) — Wed, 09 Jun 2010 02:56:14 GMT

The 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/post56350

post56350: How to display OpengGL Demos with VMware

Chen ShunLi — Wed, 09 Jun 2010 02:29:09 GMT

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.
---------------------------------------------------------------------------------------------------

post54916: None

ShanShan Qiao — Tue, 18 May 2010 04:28:13 GMT

post54138: Re: Need some documentation on Composition Manager!

Jason Mawdsley(deleted) — Tue, 11 May 2010 01:59:07 GMT

Hi 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

>

>

post53659: Need some documentation on Composition Manager!

chiranjeevi kinnera — Thu, 06 May 2010 12:24:17 GMT

Hi all,

I am a newbie to QNX, please share some documentation for io-winmgr and composition manager.

Thanks

Chiranjeevi

post50658: questions about opengl es on qnx

ivan chen — Mon, 29 Mar 2010 06:43:23 GMT

Hi, 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!

post49784: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Christian Leutloff — Wed, 17 Mar 2010 18:47:56 GMT

I am interested in your modification to build Qt. How are the programs running?

Thanks

Christian

post46059: Re: No GL_IMG/GL_ARB extensions found in OpenGL 1.4

Marton Torok — Wed, 27 Jan 2010 16:06:58 GMT

Hi 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,

Marton

post46022: Re: No GL_IMG/GL_ARB extensions found in OpenGL 1.4

Etienne Belanger(deleted) — Wed, 27 Jan 2010 13:26:10 GMT

Right 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.

post46018: RE: No GL_IMG/GL_ARB extensions found in OpenGL 1.4

Derek Leach — Wed, 27 Jan 2010 12:53:17 GMT

Hi 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/post46011

post46011: No GL_IMG/GL_ARB extensions found in OpenGL 1.4

Marton Torok — Wed, 27 Jan 2010 11:38:51 GMT

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

post45379: RE: Anti-aliasing in openGLES 1.1

Derek Leach — Mon, 18 Jan 2010 13:07:38 GMT

Hi 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/post45364

post45364: Anti-aliasing in openGLES 1.1

Sachin Rastogi — Sun, 17 Jan 2010 13:02:13 GMT

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

post45117: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Istvan Balazs — Wed, 13 Jan 2010 05:46:09 GMT

Wow, 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.

post45077: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Etienne Belanger(deleted) — Tue, 12 Jan 2010 17:22:17 GMT

6.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.

post44995: Re: RE: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Istvan Balazs — Tue, 12 Jan 2010 10:00:00 GMT

Thanks 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.

BR

post44993: RE: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Mate Szarvas(deleted) — Tue, 12 Jan 2010 09:42:37 GMT

Hello 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/post44870

post44992: Re: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Istvan Balazs — Tue, 12 Jan 2010 09:24:04 GMT

Ok, 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.

post44870: Configuring Qt 4.6 opensource for qnx SDP-6.4.1-200905201802-nto

Istvan Balazs — Mon, 11 Jan 2010 12:28:59 GMT

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

post43147: Re: io-display pends on a mutex indefinitely

Mario Mastrodicasa — Thu, 03 Dec 2009 21:22:07 GMT

Attached 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       1

post42679: Re: io-display pends on a mutex indefinitely

Mario Mastrodicasa — Thu, 26 Nov 2009 16:10:58 GMT

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       1

post42662: Re: io-display pends on a mutex indefinitely

Colin Burgess — Thu, 26 Nov 2009 14:46:56 GMT

The __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.com

post42622: io-display pends on a mutex indefinitely

Mario Mastrodicasa — Thu, 26 Nov 2009 09:03:24 GMT

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.

post40598: RE: RE: RE: RE: RE: New with QNX OpenGL ES

Derek Leach — Fri, 23 Oct 2009 12:23:09 GMT

I 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/post40572

post40597: RE: RE: RE: RE: New with QNX OpenGL ES

Derek Leach — Fri, 23 Oct 2009 12:21:45 GMT

from 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/post40580

post40580: Re: RE: RE: RE: New with QNX OpenGL ES

Praveen VS — Fri, 23 Oct 2009 03:26:07 GMT

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.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

>

>

post40572: Re: RE: RE: RE: RE: New with QNX OpenGL ES

Mitchell Schoenbrun — Thu, 22 Oct 2009 23:59:30 GMT

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

post40544: RE: RE: RE: RE: New with QNX OpenGL ES

Derek Leach — Thu, 22 Oct 2009 20:46:43 GMT

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

post40504: Re: RE: RE: RE: New with QNX OpenGL ES

Mitchell Schoenbrun — Thu, 22 Oct 2009 15:30:43 GMT

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.

post40489: RE: RE: RE: New with QNX OpenGL ES

Derek Leach — Thu, 22 Oct 2009 13:02:40 GMT

Hi 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/post40473

post40473: Re: RE: RE: New with QNX OpenGL ES

Mitchell Schoenbrun — Thu, 22 Oct 2009 01:11:12 GMT

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?

post40444: RE: RE: New with QNX OpenGL ES

Michael Van Reenen — Wed, 21 Oct 2009 16:34:44 GMT

I 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/post40239

post40239: Re: RE: New with QNX OpenGL ES

Mitchell Schoenbrun — Mon, 19 Oct 2009 15:37:43 GMT

> 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

post40207: Re: RE: New with QNX OpenGL ES

Michael Van Reenen — Mon, 19 Oct 2009 12:31:17 GMT

Sorry 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   12K

post39859: Re: Getting started with OpenGL

Robert Valler — Wed, 14 Oct 2009 10:40:14 GMT

OK, thanks again for all your support.

All the best,

Rob

post39762: Re: glLineWidth()

Etienne Belanger(deleted) — Tue, 13 Oct 2009 13:22:38 GMT

In 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.

post39758: Re: Getting started with OpenGL

Etienne Belanger(deleted) — Tue, 13 Oct 2009 12:50:08 GMT

There is no hardware acceleration of OpenGL ES on the iMX35.

post39747: Re: Getting started with OpenGL

Robert Valler — Tue, 13 Oct 2009 08:18:17 GMT

Hello 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,

Rob

post39740: Re: Getting started with OpenGL

Joel Pilon(deleted) — Mon, 12 Oct 2009 19:07:04 GMT

Unfortunately, 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.

post39738: Getting started with OpenGL

Robert Valler — Mon, 12 Oct 2009 14:57:13 GMT

Hello,

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,

Rob

post39708: glLineWidth()

li xiuhui — Sat, 10 Oct 2009 09:35:04 GMT

Hi 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()?

post39410: Re: RE: New with QNX OpenGL ES

Mitchell Schoenbrun — Tue, 06 Oct 2009 01:29:44 GMT

>

> 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   12K

post39381: RE: New with QNX OpenGL ES

Michael Van Reenen — Mon, 05 Oct 2009 15:03:53 GMT

Unfortunately 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/post38933

post38933: New with QNX OpenGL ES

Mitchell Schoenbrun — Tue, 29 Sep 2009 06:00:04 GMT

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.

post38524: glQueryMatrixxOES is broken in QNX 6.4.1

Mike Gorchak — Wed, 23 Sep 2009 07:39:01 GMT

While 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.

post36253: Re: Software Rasterizer vs. Coral?

Malte Mundt(deleted) — Wed, 19 Aug 2009 13:02:55 GMT

So it actually does use the hardware to render, only prints out wrong information? Ok, glad to hear this. Thanks.

- Malte

post36251: Re: Software Rasterizer vs. Coral?

Etienne Belanger(deleted) — Wed, 19 Aug 2009 12:45:19 GMT

There 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.

post36243: Software Rasterizer vs. Coral?

Malte Mundt(deleted) — Wed, 19 Aug 2009 11:37:13 GMT

Hi,

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'?

- Malte

post31192: Bug with alpha blending with lighting enabled and enabled GL_COLOR_MATERIAL

Mike Gorchak — Tue, 09 Jun 2009 12:42:35 GMT

Sample 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.

post30666: Bug in the glTexImage2D() with UNSIGNED_SHORT_5_5_5_1 and UNSIGNED_SHORT_4_4_4_4

Mike Gorchak — Wed, 03 Jun 2009 12:45:15 GMT

glTexImage2D() 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).

post30167: Re: Bug in the glCopyTexImage2D() implementation

Mike Gorchak — Wed, 27 May 2009 18:03:49 GMT

> 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.

post30125: Re: Bug in the glCopyTexImage2D() implementation

Etienne Belanger(deleted) — Wed, 27 May 2009 12:42:56 GMT

It 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.

post30106: Bug in the glCopyTexImage2D() implementation

Mike Gorchak — Wed, 27 May 2009 05:11:11 GMT

As 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.

post29619: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Mike Gorchak — Mon, 18 May 2009 13:54:48 GMT

By 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.

post29336: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Wed, 13 May 2009 11:53:57 GMT

> If I set material settings (AMBIENT and DIFFUSE) to default values, shading

> begins to work correctly.

Any news ?

post29245: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Tue, 12 May 2009 12:33:20 GMT

> 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.

post29243: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Etienne Belanger(deleted) — Tue, 12 May 2009 12:18:36 GMT

What happens if you manually set the light and material state to the default values ?

post29220: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Mike Gorchak — Tue, 12 May 2009 04:31:30 GMT

I'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.

post29219: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Tue, 12 May 2009 04:16:32 GMT

Etienne, could you comment this issue, because problem still persist.

post28910: Re: VBO and VA limits

Mike Gorchak — Thu, 07 May 2009 13:59:36 GMT

> 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 ?"

post28907: Re: glGetString(GL_VERSION) do not conforms to OpenGL ES 1.0 specification !

Mike Gorchak — Thu, 07 May 2009 13:55:23 GMT

> 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.pdf

post28896: Re: glGetString(GL_VERSION) do not conforms to OpenGL ES 1.0 specification !

Etienne Belanger(deleted) — Thu, 07 May 2009 13:29:08 GMT

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.

post28891: Re: VBO and VA limits

Etienne Belanger(deleted) — Thu, 07 May 2009 13:21:02 GMT

glVertexPointer 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.

post28882: Re: OpenGLES possible with my configuration?

Frank Maier — Thu, 07 May 2009 12:49:36 GMT

Thx for this info ... but i cannot found a AGTDK package only patches for IDE 6.3.2 ...

Can you give me a link?

post28880: Re: OpenGLES possible with my configuration?

Etienne Belanger(deleted) — Thu, 07 May 2009 12:27:11 GMT

You 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.

post28873: OpenGLES possible with my configuration?

Frank Maier — Thu, 07 May 2009 11:27:26 GMT

Hi,

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?

Frank

post28842: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Etienne Belanger(deleted) — Wed, 06 May 2009 18:04:23 GMT

They 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.

post28840: Re: Stencil problem with devg-extreme2 on 82852GM

Mike Gorchak — Wed, 06 May 2009 17:33:38 GMT

My 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.

post28839: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Mike Gorchak — Wed, 06 May 2009 17:14:57 GMT

> 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.

post28821: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Etienne Belanger(deleted) — Wed, 06 May 2009 15:17:07 GMT

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...

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.

[...]

post28810: VBO and VA limits

Mike Gorchak — Wed, 06 May 2009 14:14:04 GMT

if 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.

post28802: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Mike Gorchak — Wed, 06 May 2009 13:55:16 GMT

> 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.

post28781: Re: GL_OES_vertex_buffer_object extension incorrect defines.

Etienne Belanger(deleted) — Wed, 06 May 2009 12:44:44 GMT

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.

post28780: Re: glNewList(), glCallList(), glDeleteLists() in 6.4.1

Etienne Belanger(deleted) — Wed, 06 May 2009 12:38:45 GMT

glGetFloatv 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.

post28772: glNewList(), glCallList(), glDeleteLists() in 6.4.1

Mike Gorchak — Wed, 06 May 2009 11:24:56 GMT

Just 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 ?

post28762: GL_OES_vertex_buffer_object extension incorrect defines.

Mike Gorchak — Wed, 06 May 2009 06:56:25 GMT

GLES/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.

post28699: Re: Double buffering in OpenGL ES

Mike Gorchak — Tue, 05 May 2009 14:36:44 GMT

> > 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 ?

post28688: Re: Double buffering in OpenGL ES

Etienne Belanger(deleted) — Tue, 05 May 2009 13:24:12 GMT

> 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.

post28684: Re: Double buffering in OpenGL ES

Mike Gorchak — Tue, 05 May 2009 13:10:01 GMT

Etienne, could you comment the described issue with eglSwapInterval(0) ?

post28633: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Mike Gorchak — Mon, 04 May 2009 15:36:31 GMT

> 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.

post28632: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Mike Gorchak — Mon, 04 May 2009 15:23:33 GMT

I 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.

post28631: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Etienne Belanger(deleted) — Mon, 04 May 2009 15:20:12 GMT

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.

post28630: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Mike Gorchak — Mon, 04 May 2009 15:05:59 GMT

> 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.

post28623: Re: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2

Mike Gorchak — Mon, 04 May 2009 14:28:36 GMT

> Was this measured using devg-extreme2 ?

Yes.

post28614: Re: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2

Etienne Belanger(deleted) — Mon, 04 May 2009 13:34:08 GMT

I 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 ?

post28608: Re: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Etienne Belanger(deleted) — Mon, 04 May 2009 13:26:44 GMT

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.

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.

post28579: RE: OpenGL ES Tutorials/Lessons/Codesamples

Derek Leach — Mon, 04 May 2009 06:43:16 GMT

very 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/post28559

post28562: GL_SHININESS material parameter dramatically affects perfomance using devg-extreme2

Mike Gorchak — Sat, 02 May 2009 17:26:38 GMT

If 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 ?

post28561: It seems as if glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ...) is interpreted incorrectly

Mike Gorchak — Sat, 02 May 2009 17:14:58 GMT

Default 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.

post28559: OpenGL ES Tutorials/Lessons/Codesamples

Mike Gorchak — Sat, 02 May 2009 05:42:05 GMT

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 :) !

post28299: Fog and devg-extreme2

Mike Gorchak — Wed, 29 Apr 2009 04:28:04 GMT

While 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.

post28108: Re: Any comments on OpenGL ES issues ?

Mike Gorchak — Mon, 27 Apr 2009 07:30:47 GMT

> 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 ? :)

post27828: Re: devg-extreme2 is omitting points when glDrawArrays() is executing.

Logan Fraser — Wed, 22 Apr 2009 20:14:39 GMT

Hi 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  = 5h

post27571: glClear(GL_COLOR_BUFFER_BIT) using devg-i830 graphics driver

Mike Gorchak — Tue, 21 Apr 2009 08:23:08 GMT

If 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.

post27318: Re: Double buffering in OpenGL ES

Mike Gorchak — Fri, 17 Apr 2009 05:59:38 GMT

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.

post27225: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 13:59:28 GMT

I'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 ...

post27214: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 13:30:28 GMT

cpu 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;

}

post27212: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 13:26:40 GMT

ok, I will debug devg-vmware.so ... to see what I can do, because it's the only option I have at the moment ...

-Derek

post27211: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 13:24:37 GMT

> 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 ?

post27204: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 12:59:24 GMT

The flags are GF_SURFACE_CREATE_2D_ACCESSIBLE | GF_SURFACE_CREATE_3D_ACCESSIBLE | GF_SURFACE_CREATE_SHAREABLE

post27203: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 12:53:37 GMT

> 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 ...

post27202: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 12:48:18 GMT

What are you passing for the flags value to gf_surface_create_layer()? This is rather odd ... hmmm ...

post27198: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 12:43:28 GMT

> 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().

post27197: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 12:30:35 GMT

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 ...

post27196: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 12:25:35 GMT

> 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.

post27195: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 12:10:35 GMT

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 ...

post27191: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 16 Apr 2009 11:54:49 GMT

Yes, this issue could be reproduced on any hardware, including software renderer.

post27190: Re: Double buffering in OpenGL ES

Derek Leach — Thu, 16 Apr 2009 11:51:41 GMT

Mike, do you see similar issues using devg-soft3d.so? I only have access to that renderer at the moment.

-Derek

post27189: RE: Any comments on OpenGL ES issues ?

Derek Leach — Thu, 16 Apr 2009 11:49:54 GMT

I 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/post27184

post27186: Re: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!

Derek Leach — Thu, 16 Apr 2009 11:37:05 GMT

Ok, 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 ...

-Derek

post27184: Re: Any comments on OpenGL ES issues ?

Mike Gorchak — Thu, 16 Apr 2009 11:34:34 GMT

> 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

post27182: Re: Any comments on OpenGL ES issues ?

Derek Leach — Thu, 16 Apr 2009 11:18:38 GMT

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 ...

Thanks,

-Derek

post27181: Any comments on OpenGL ES issues ?

Mike Gorchak — Thu, 16 Apr 2009 11:16:30 GMT

Sorry for useless topic, but maybe someone will comment issues which I've found ?

post26742: Re: Stencil problem with devg-extreme2 on 82852GM

Mike Gorchak — Mon, 13 Apr 2009 10:53:43 GMT

Forgot to mention, that stencil in software OpenGL ES implementation is also broken, not only using devg-extreme2 driver.

post26741: Re: Stencil problem with devg-extreme2 on 82852GM

Mike Gorchak — Mon, 13 Apr 2009 10:51:26 GMT

I 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 ...

post26498: Re: devg-extreme2 is omitting points when glDrawArrays() is executing.

Mike Gorchak — Thu, 09 Apr 2009 08:53:43 GMT

Additional 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.

post26483: devg-extreme2 is omitting points when glDrawArrays() is executing.

Mike Gorchak — Thu, 09 Apr 2009 05:01:12 GMT

Kevin 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.

post26267: Re: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!

Mike Gorchak — Tue, 07 Apr 2009 18:26:37 GMT

Looks 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.

post26266: Initial texture parameters do not conforms to OpenGL ES 1.0 specification!

Mike Gorchak — Tue, 07 Apr 2009 18:20:21 GMT

Quote 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.

post26039: Re: Stencil problem with devg-extreme2 on 82852GM

Mike Gorchak — Mon, 06 Apr 2009 08:56:34 GMT

Does 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 ...

post26038: Re: GLU 1.3 for OpenGL ES

Mike Gorchak — Mon, 06 Apr 2009 07:00:46 GMT

An updated version of GLU ES is located here: http://glues.googlecode.com

post26002: Stencil problem with devg-extreme2 on 82852GM

Mike Gorchak — Fri, 03 Apr 2009 17:48:55 GMT

Does 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.

post25956: RE: GLU 1.3 for OpenGL ES

Derek Leach — Fri, 03 Apr 2009 11:02:27 GMT

Hey 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/post25955

post25955: GLU 1.3 for OpenGL ES

Mike Gorchak — Fri, 03 Apr 2009 10:59:12 GMT

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.

post25755: Re: Double buffering in OpenGL ES

Mike Gorchak — Wed, 01 Apr 2009 13:53:21 GMT

Maybe 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.

post25754: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Wed, 01 Apr 2009 13:45:39 GMT

Argh, 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.

post25751: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Wed, 01 Apr 2009 13:35:03 GMT

> 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.

post25741: Re: Something wrong with default Materials settings in QNX's OpenGL ES

Etienne Belanger(deleted) — Wed, 01 Apr 2009 12:39:49 GMT

Can 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 disabled

post25740: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Etienne Belanger(deleted) — Wed, 01 Apr 2009 12:32:39 GMT

Unfortunately, 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.

post25729: Re: Double buffering in OpenGL ES

Mike Gorchak — Wed, 01 Apr 2009 05:32:44 GMT

How 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.

post25727: Re: Double buffering in OpenGL ES

Mike Gorchak — Wed, 01 Apr 2009 04:44:00 GMT

> 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.

post25726: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Mike Gorchak — Wed, 01 Apr 2009 04:36:13 GMT

> 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 ?

post25719: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Etienne Belanger(deleted) — Tue, 31 Mar 2009 19:24:36 GMT

gf-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.

post25710: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Misha Nefedov — Tue, 31 Mar 2009 18:38:43 GMT

Your 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.

post25709: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Mike Gorchak — Tue, 31 Mar 2009 18:09:09 GMT

Maybe 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.

post25594: Re: devg-extreme2 on 82852GM Intel integrated graphics device

Michael Van Reenen — Mon, 30 Mar 2009 18:10:27 GMT

We've filed a PR for this issue on your behalf. (PR # 66876)

post25521: Re: GL_RENDERER in my application and in the egl-gears

Etienne Belanger(deleted) — Mon, 30 Mar 2009 13:17:08 GMT

There 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.

post25507: devg-extreme2 on 82852GM Intel integrated graphics device

Mike Gorchak — Mon, 30 Mar 2009 06:10:35 GMT

I 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.

post25504: Something wrong with default Materials settings in QNX's OpenGL ES

Mike Gorchak — Mon, 30 Mar 2009 05:17:39 GMT

When 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.

post25497: GL_RENDERER in my application and in the egl-gears

Mike Gorchak — Sat, 28 Mar 2009 12:14:57 GMT

I'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.

post25446: Re: Switch between accelerated and unaccelerated OpenGL ES implementations

Mike Gorchak — Fri, 27 Mar 2009 13:11:42 GMT

Yes, 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.

post25443: Re: Switch between accelerated and unaccelerated OpenGL ES implementations

Etienne Belanger(deleted) — Fri, 27 Mar 2009 13:04:12 GMT

Is there a specific reason for wanting to switch between accelerated and non-accelerated rendering ?

post25441: Re: eglChooseConfig and vmware

Etienne Belanger(deleted) — Fri, 27 Mar 2009 13:01:14 GMT

EGL_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.

post25417: Feature request: GL_BGR/GL_BGRA/GL_ABGR extensions for OpenGL ES

Mike Gorchak — Fri, 27 Mar 2009 05:41:30 GMT

It 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.

post25407: eglChooseConfig and vmware

Mario Mastrodicasa — Thu, 26 Mar 2009 21:16:47 GMT

I'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.

post25334: Re: Double buffering in OpenGL ES

Etienne Belanger(deleted) — Thu, 26 Mar 2009 14:04:40 GMT

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.

post25323: Re: Double buffering in OpenGL ES

Mike Gorchak — Thu, 26 Mar 2009 13:41:56 GMT

Strange, but I can see full buffer clearence while double buffer is on. I'll check my code of buffers creation one more.