Features on OpenVG next Releases

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Features on OpenVG next Releases

1,657 Views
ioseph_martinez
NXP Employee
NXP Employee

I would also use this thread to gather any ideas or suggestions or features you would like to see on the coming releases. No promises they will be included but definitely will be considered.


This is the list of features on the next releases of OpenVG for Vybrid from Freescale.

It may change, but is the plan so far...


Release 0.5.0

1. Support MQX 4.0.2 Alpha2 (on TWR and AutoEVB) and 4.0.1 Beta3(on TWR)

2. Redefine the API architecture

  1. make MQX_template_list available to the application
  2. add fbdev abstraction on DCU
  3. write simple “fbws” window system on MQX to support EGL window surface
  4. make eglfsl private extension obsolete

3. Merge vivante 4.6.9p11 release

4. Enable openvg trace info for debuggin

Details on future releases are just general:

Release 0.6.0

- Conformance Test Compliance

Release 0.7.0

- Performance Improvements

Message was edited by: Ioseph Martinez Pelayo

Tags (2)
0 Kudos
5 Replies

1,181 Views
jasonwilliamson
Contributor II

We are currently using the eglfsl extensions in eglfsl.h.  Is item 2.4 above intended to remove the eglfsl.h extensions entirely?

0 Kudos

1,181 Views
ioseph_martinez
NXP Employee
NXP Employee

To be honest I don't know the details but we should be able to provide a different mechanism to provide a physical address to the DCU Layer to point to the rendering buffer.

I think that is on points 2.2 and 2.3 write simple “fbws” window system on MQX to support EGL window surface

Feng Wei, can you confirm this is true?

0 Kudos

1,181 Views
jasonwilliamson
Contributor II

We need more than the physical address of the surface buffer.  We need the stride, height, and color format as well.  This is important for setting the DCU layer registers.  It's also important for buffer synchronization when double-buffering the surfaces.

We've tried using our own internal calculations for these values, but that causes problems every time the OVG driver is updated because there have been changes to surface stride and height requirements.  Also driver may create a different OVG format identifier than we assume.

0 Kudos

1,181 Views
fengwei
NXP Employee
NXP Employee

EGL has three kind of surfaces support: Window Surface, Pixmap Surface and Pbuffer Surface. Window and Pixmap Surfaces are native display system related. That's why in 0.5.0 DCU is hidden behind the EGL and application could ignore display details and just use eglSwapBuffers to have VG render buffer displayed.

There's quite a lot of driver code in EGL and HAL levels to handle display system stuffs, so for special use case from yours, I think we could make a tiny driver that be display unawareness, and only keep Pbuffer Surface. If you agree, I plan to add one build option to generate the tiny driver for you in release 0.6.0. Before that, I will just provide a patch on 0.5.0 to make your program work, after Ioseph verifies it.

0 Kudos

1,181 Views
ioseph_martinez
NXP Employee
NXP Employee

eglfsl will be removed in the future because it will be not necessary anymore with the new native window system being created: FBWS on 0.5.0

According to R&D, pixmap can be used to gather the required information to configure the DCU and the effort to port the code to use pixmap should not be complex.

The plan so far is just making it obsolete so we will not remove it until you are fully migrated to the latest new release.

0 Kudos