[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JavaFX SDK 8 on BeagleBoard
From:       David Hill <David.Hill () oracle ! com>
Date:       2013-01-30 22:27:10
Message-ID: 51099E3E.1060300 () Oracle ! com
[Download RAW message or body]

On 1/30/13 Jan 30, 11:04 AM, David Hill wrote:

Wow. It was just pointed out to me I just answered an email from Dec 24th.... one \
that just popped up to day in my inbox. And I forgot I responded to this before when \
Richard asked me to. Would appear the original got stuck on a server somewhere and \
just got unstuck. Very strange.... :-)

Dave
> On 12/24/12 Dec 24, 7:05 AM, Conrad Winchester wrote:
> > Hi,
> > 
> > I have been experimenting with JavaFX on the Beagleboard xM for a while now. I \
> > also have a raspberry Pi, but find it's power supply instabilities and weaknesses \
> > very frustrating, and so much prefer the more stable beaglebord for tinkering. In \
> > particular I am working with Tinkerforge equipment that really makes the poor old \
> > Pi expire :-( 
> > The JDK8 JavaFX ARM Preview has just been released for the Raspberry Pi. I have \
> > it running, but , as stated above, using the raspberry pi with anything attached \
> > to the USB without a powered hub is nigh on impossible and so I would love to use \
> > it on the Beagleboard. 
> > Unfortunately it does not seem to work. In fact the Beagleboard does not even \
> > recognise any of the executables as files in the JDK8 JavaFX ARM release. If I cd \
> > /opt/jdk1.8.0/bin and do a ./java -version I get the following error message 
> > -sh: ./java: No such file or directory
> > 
> > even though if I do an ls, I can definitely see it there.
> > 
> > Is this a sign of things to come? Are the various linux/arm chip configurations \
> > so different that there will always be a multitude of different Java ARM installs \
> > to cater for every combination? Or is there a magic thing that I can do to solve \
> > the issue? 
> > Any help would be greatly appreciated.
> 
> Conrad,
> 
> There are several issues with embedded hardware, so bear with me as I explain some \
> things (if only to get the terminology straight :-). While I suspect you know some \
> of this, perhaps some of the others on the list will enjoy a read. 
> Before I get to graphics - there is the hard float/soft float ABI issue. Most \
> platforms right now use the older soft float ABI. A few have moved the hard float \
> ABI (the PI provides downloads for both). One problem for the hard float is often \
> there is a hard float OS disto available, but the black box vendor graphics drivers \
> are not available yet - meaning you only get the much, much slower graphics. The \
> two ABI are not interchangeable. Interestingly - on the PI where I have the ability \
> to directly compare hard/soft performance - the hard float distro (wheezy) is about \
> 20% faster in some of our rendering benchmarks. This increase is probably not just \
> the cleaner ABI in our code, but likely the result of the GLES drivers and all of \
> the FP values it throws around. 
> The Beagle JFX preview is soft float. I am not aware of a full up hard float distro \
> AND graphics drivers for the Beagle (yet). This preview is dated now, and will only \
> be updated through the SE8 beta. 
> The PI JFX preview (now part of the SE8 beta) uses the hard float ABI. This beta \
> will not work on the Beagle. 
> There is a bandwidth crunch in engineering, and so for now, the SE8 beta is \
> available in the hard float ABI only. This means that at least for the next couple \
> of months - the PI is the only way to get the newer drops of JFX. 
> On to graphics.
> 
> There are several logical paths for us to get pixels on the screen, and here are \
> four of them: 
> * Direct to Framebuffer, using OpenGLES v2, or software only rendering
> * Via X11 using OpenGLESv2 or client side software only rending.
> 
> We believe our primary market in embedded is for OpenGLESv2 "Direct to Framebuffer" \
> (FB). Taking X11 out of the path reduces overhead, and speeds rendering. The \
> applications we are likely to see from vendors using the product would be "full \
> screen". The challenge for FB rendering is how to get to the FB. 
> The problem with GLES drivers is that they are platform specific, and not all of \
> them support EGL/GLESv2 direct to the FB. Even on "the same family" GPUs, you will \
> find differences in support, for example direct to FB is supported on the Beagle, \
> but not on the Panda (at least last I looked), even though both use PVR drivers. \
> Different GPU "families" can have different EGL startup sequences - as the EGL \
> standard does not specify the startup sequence for FB, only for X11. Each of the \
> "families" seem to have a slightly different way of doing those first few steps - \
> some requiring platform specific calls to do so. (Beagle xM, I can use a \
> "EGL-NULL", passing in NULL to a couple of calls and the right thing happens, for \
> PI, there are several "dispman" calls that are needed. 
> In addition to the EGL/GLES, there are a number of other things we need to be able \
> to do to get support right. These involve things like overlaying a mouse cursor for \
> example. So far, none of these additional items seem to be common across hardware \
> vendors. 
> At least input is common across Linux. For our non-X11 paths - we rely on directly \
> detecting/reading the input devices. A challenge there is that not all touch \
> devices behave the same, and we are still learning there. 
> For our initial SE8 release we have been concentrating on Beagle xM and PI. I have \
> other boards I would like to be able to say are "Known to work". but that would \
> require engineering bandwidth (and I am including SQE) that can be easily stretched \
> when you start laying out the number of boards I want :-). 
> In the case of the "software only", we are talking about our common software \
> rendering path, which does not use any platform specific calls for rendering except \
> to upload a fully rendered "texture" (basically the contents of a window to the \
> display. This "fallback" rendering is good enough for simple scene graphs, but \
> would not be my first choice. 
> The embedded team has designed our "Glass" implementation (the layer that interacts \
> with the window manager, or in our case *is* the window manager) and our "Prism" \
> implementation (the rendering engine) with a certain amount of flexibility in mind, \
> hoping that we can continue to add detection/initialization paths for hardware as \
> we get them, and have time to implement them. We are looking forward to the OSS of \
> this code, because we know that there are a number of people out there who will be \
> willing and able to help up add new platforms to our framework. 
> As much as I want to have one of every board out there - we know that is \
> impossible. And there are so many nifty new boards out there... I love browsing \
> though the catalogs and reviews, and seeing a "HDMI stick" for example, and wishing \
> I had one, and the time to port JFX to it. 
> Hope that helps,
> Dave
> 
> PS. to help with PI power issues, start with a powered USB hub, and then add a \
> beefier power supply. The powered hub took away most of my stability issues, the 2A \
> ps the rest. 
> 
> 
> 
> 


-- 
David Hill <David.Hill@Oracle.com>
Java Embedded Development

"640K ought to be enough for anybody."
-- Bill Gates


[prev in list] [next in list] [prev in thread] [next in thread]