Vivante binaries in L3.0.35 source - hard-float or soft-float ?

cancel
Showing results for 
Search instead for 
Did you mean: 

Vivante binaries in L3.0.35 source - hard-float or soft-float ?

2,258 Views
EinarMar
Contributor IV

I am wondering if the Vivante binaries in the L3.0.xxx source is compiled with hard-float or soft-float support ?

if compiled with soft-float is it possible to get a hard-float version ?

I'm working on SabreLite (i.MX6Q) and I'm trying to cross-compile QT with openGl support.

Regards

Einar

Labels (3)
16 Replies

222 Views
EinarMar
Contributor IV

ok, now I've finished setting up our distro for armhf with the vivante gpu modules I acquired from here. I'm using the Boundary device linux kernel that has the vivante modules in it. When I now start up the board I can see /dev/galcore exists.

I have compiled one QT program that I intended to test with OpenVG and another program for testing the OpenGL (using the OpenGL QT API).

My question is how do I start them up so they will use the acceleration ?

I'm struggling to figure out if a regular QT application (not using the OpenGL) will use use the OpenVG is instructed when started. If so then what are the parameters to use ? what do I set in QWS_DISPLAY and such.

hope somebody can assist me in this.

regards

Einar

0 Kudos

222 Views
EinarMar
Contributor IV

We are using our own distro based on ubuntu/debian with QT 4.8. I have compiled the whole thing with hardfloat compiler from Linaro. Everything is running fine except when I try to run the QT application which is supposed to use the Vivante binaries for acceleration. It just crashes there when it is trying to locate the device.

I was wondering if anyone had tried to run QT application with accelerated graphics and if so, how are the display settings (QWS_DISPLAY or -display) ??

0 Kudos

222 Views
OtavioSalvador
Senior Contributor II

Are your GPU binaries hardfp as well? or it will fail.

0 Kudos

222 Views
EinarMar
Contributor IV

Yes they should be. They where provided by someone named Mcfrisk on the 23th of January.

222 Views
EdWhite
NXP Pro Support
NXP Pro Support

To offer "hardFP" version of the i.MX6 GPU library, it must consider the windowing system.  Is it acceptable if it only supports FBdev and DirectFB?  Is anyone using X11 or Wayland?  What is needed to support QT?

Thanks!

0 Kudos

222 Views
jameslaird
Contributor I

Is there any chance that hardfp X11 binaries will be released officially (or even unofficially)? There are some leaked hardfp binaries floating around, but only framebuffer ones.

0 Kudos

222 Views
JasonDavis
Contributor II

We use X11 as well.

0 Kudos

222 Views
mtx512
Contributor V

We use X11, so we require hardfp versions.

Isn't it just a case of re-compiling the closed source libraries with a hardfp compiler?

0 Kudos

222 Views
mwsealey
Contributor II

Just FYI some Freescale customers (Genesi for example) can help other Freescale customers with custom builds of the GPU (i.MX3x, 5x, 6x) libraries and optimization and support as subcontracting work.

I think Ed is asking because DirectFB and fbdev are basically constant and unchanging APIs that aren't about to move around and no matter which customer of Freescale you pick out, one binary will support everybody.

The problem with X11 and Wayland and Qt rather than DirectFB and fbdev is depending on your target Linux, ABIs and functionality changes too much to generate a single set of binaries that will work. If you use Ubuntu Lucid or Maverick or Precise or Oneiric, that's softfloat (armel repos are still available for all of them) vs. hardfloat (Precise onwards IIRC) AND at least 3 Xorg ABI changes for the X driver.


Wayland is in flux and it will probably be 9 months before anyone uses it in any realistic capacity - building Vivante support for Wayland is going to need something to target. As far as I can tell it would be simply done, the driver support is there minus a few possible support libraries which are totally opensource. Most of the work is in Wayland itself since it is arduous and relies mostly on the way Mesa handles DRM because this is all the opensource guys have access to within reason. Getting an accelerated display driver (on GLES2) is totally, 100% modifications required inside Wayland, maybe libgbm.

That is on the assumption you just want accelerated compositing display manager; running a OpenGLES app on top of it requires EGL support which needs coding (but then again, Wayland support is rather trivial in this regard) and when they finally stabilize the ABI (I believe they just did, it seems to actually be in the Khronos EGL headers now) and extensions, and someone gives it a shake (i.e. some distro picks it up or Linaro launches headlong into it), it will be worth supporting.

Qt is not the kind of thing most customers of Freescale just use a ready-made accelerated driver. There are many, many ways to accelerate what Qt does using GPU, IPU, VPU, different display backends (X11, fbdev, DirectFB etc.) or software techniques (for instance do you use old-skool QPainter, or the new QML models? The rendering model is completely different and the acceleration path should be optimized per use-case) and other hardware acceleration opportunities inside the i.MX6 - what you actually use is nearly always down to your specific application and it would be better to leave this to subcontractors or do it yourself against the binary drivers (Qt offers decent OpenGLES acceleration) than expect Freescale to try and support every possibility.

222 Views
ericmolitor
Contributor II

Thank you for a very good explanation of the state of supporting closed source GPU's on Linux. Your assessment is spot on and one of the reasons why I expect HW vendors to support FBDev/DirectDB with EGL and GLES support. It's the lowest common denominator with the fewest moving pieces.

Regarding X11 I do believe things are starting to change. The armsoc driver has paved the way to show how you can correctly abstract away the library/platform/dependency nightmare that has traditionally encumbered proprietary embedded GPU support on Linux. Tom Cooksey from ARM has worked up most of this plan and it would be good for Vivante and Freescale to reach out to him and understand how they could greatly simplify supporting X11.

0 Kudos

222 Views
mwsealey
Contributor II

Eric Molitor wrote:

Regarding X11 I do believe things are starting to change. The armsoc driver has paved the way to show how you can correctly abstract away the library/platform/dependency nightmare that has traditionally encumbered proprietary embedded GPU support on Linux. Tom Cooksey from ARM has worked up most of this plan and it would be good for Vivante and Freescale to reach out to him and understand how they could greatly simplify supporting X11.

That's not entirely true; the armsoc driver is really pretty ugly when it comes down to it and is just a hack around getting certain DRM drivers working without duplicating too much code. At the end of the day, they end up sharing a good set of really poor functionality, and for instance the OMAP and Exynos stuff works okay but the Mali support is absolutely dire (since Mali doesn't really use DRM precisely). I think the binary Vivante driver is much better from this point of view, if only not open-source.

If the Xorg ABI changes again (and I am sure it will for some magic new composition method or to support something for DRI3 or something) then one build of armsoc will not run on another build of Xorg, and maybe not against another version of the kernel (this is another dependency I should have noted..) just like the situation we have now with 'closed' binary drivers.

All drivers are binary eventually, so this could be called a "distro problem" in the mainstream consumer Linux space, but as subcontractors and software developers and engineers it is actually our problem at the end of the day. Unfortunately we all run different software, but providing binaries that are closed source is not much worse than providing binaries of an open-source package in a Linux distribution. If you end up changing something so huge you have to recompile your graphics drivers, you have become a singularity which is hard to support.

222 Views
EdWhite
NXP Pro Support
NXP Pro Support

Hi Jas,  Please "follow" me so I can send you a direct message.  Thank you,

0 Kudos

222 Views
OtavioSalvador
Senior Contributor II

The binaries are build with softfp so you cannot use them in a hardfp system. This is the reason why we don't use hardfp in Yocto (even it having the support for it) for FSL SoCs.

0 Kudos

222 Views
JasonDavis
Contributor II

I too would like hard-float GPU binaries!

0 Kudos

222 Views
mcfrisk
Contributor I

I would also like to get Vivante GPU binaries compiled for hard float.

0 Kudos

222 Views
EinarMar
Contributor IV

Can anybody comment on that !

Is Freescale the middle man in that or is necessary to talk directly to Vivante ?

0 Kudos