JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20130222 05:05:13 (UTC)

20130222 05:05:13 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130221050600.html
20130222 05:05:13 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130222050513.html
20130222 05:39:17 * hharrison (~chatzilla@anon) has joined #jogamp
20130222 06:49:07 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130222 07:27:47 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 256 seconds)
20130222 07:59:29 * [Mike] (~Mike]@anon) Quit (Ping timeout: 256 seconds)
20130222 08:08:23 * [Mike] (~Mike]@anon) has joined #jogamp
20130222 08:50:06 * hharrison (~chatzilla@anon) Quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130206104040])
20130222 10:04:29 <xranby> (22:25:14) odin_: I am trying to understand the issue with razdroid, this is android on RPi, it works unaccelerated but not accelerated and I think the whole low level API is OpenGL ES2 + EGL <-- the key to understand the issue is that libEGL that you need to use in order to initialize the native surface used by OpenGL ES require platform dependent code
20130222 10:06:32 <xranby> odin_: the open source of the userland side driver part on the raspberry pi may make it possible to create a new libEGL for the Pi that accepts an android "ANativeWindow*" datastructure pointer.
20130222 10:06:44 <xranby> EGL API background:
20130222 10:06:44 <xranby> It is common that libEGL EGLNativeWindowType differ for OpenGL ES implementations across operating systems, for example:
20130222 10:06:50 <xranby> On Windows EGLNativeWindowType is a "HWND" datastructure.
20130222 10:06:50 <xranby> On Linux/Android EGLNativeWindowType is a "ANativeWindow*" datastructure pointer.
20130222 10:06:50 <xranby> On Linux/X11 EGLNativeWindowType is a "Window" datastructure.
20130222 10:06:50 <xranby> and so on...
20130222 10:06:50 <xranby> On The Raspbeery Pi using a Linux/Broadcom Videocore IV EGLNativeWindowType is a "EGL_DISPMANX_WINDOW_T" datastructure.
20130222 10:07:34 <xranby> this is the reason why we have android specific and x11 specific opengl es drivers because the libEGL differs
20130222 10:08:32 <xranby> unfortunally on the raspberry pi, the GPU firmware, that is running on the turning complete raspberry pi GPU do most of the logic
20130222 10:08:45 <xranby> and this firmware blob is still not opensource
20130222 10:09:07 <xranby> so in practise its still hard/impossible to create a new libEGL for the raspberry pi
20130222 10:09:15 <xranby> but ners are unstoppable like you know
20130222 10:09:16 <xranby> nerds
20130222 10:09:31 <xranby> and today we have a quite large reverse engineering team
20130222 10:09:43 <xranby> working on liberating the raspberry pi firmware
20130222 10:10:38 <xranby> https://github.com/hermanhermitage/videocoreiv/wiki
20130222 10:11:17 <xranby> this github account hold all the current bits to liberate the GPU
20130222 10:11:19 <xranby> https://github.com/hermanhermitage/binutils-vc4
20130222 10:11:48 <xranby> look at that they have even written a binutils that allows you to compile an all opensource firmware!
20130222 10:11:55 <xranby> so whats next?
20130222 10:12:10 <xranby> i think the goal is to port linux to run on the GPU instead of the CPU
20130222 10:12:35 <xranby> and then let this new linux "distribution" implement the firmware
20130222 10:15:31 <xranby> libv have summarized the Broadcom Video Code IV reverse engineering effort and his view of the "open-source" driver http://youtu.be/W-HCb55X_XU?t=24m17s
20130222 10:15:41 <xranby> that is a must watch
20130222 10:15:52 <[Mike]> very interesting
20130222 10:17:12 <xranby> [Mike]: thank you, feel free to share, the URL to this IRC conversation is: http://jogamp.org/log/irc/jogamp_20130222050513.html#l9
20130222 10:18:39 <xranby> [Mike]: inside JogAmp NEWT we have hidden all the platform specific libEGL initialization code so that applications using OpenGL do not have to care how the native surface got initialized
20130222 10:19:32 <xranby> thats why we can have a platform agnostic API to let end user JogAmp NEWT applications initialize OpenGL on all platforms without any platform specific code.
20130222 10:26:50 <odin_> morning all
20130222 10:26:56 <[Mike]> morning
20130222 10:29:25 <odin_> host_applications/linux/apps/hello_pi/libs/vgfont/graphics_x_private.h: EGL_DISPMANX_WINDOW_T egl_win;
20130222 10:30:15 <odin_> why do I need to create a new EGL for RPi when raspbian has a working one
20130222 10:30:38 <odin_> android uses GCC as well, but sure linked to bionic (not glibc) and the rest of its userland
20130222 10:30:46 <xranby> odin_: http://jogamp.org/log/irc/jogamp_20130222050513.html#l9
20130222 10:30:46 <[Mike]> xranby: I was more active on the jabber channel as notturno. I've been quite busy as of late and haven't had the time to log into jabber. Very nice to see that you are active in IRC. I would like to become more active in the JOGL community as I'm very interested in the project.
20130222 10:31:01 <odin_> but what prevent me from using raspbian libEGL on android ?
20130222 10:31:25 <odin_> I have written ABI shims before to allow symbol linkage and a quick look on RPi :
20130222 10:31:46 <odin_> nm /opt/vc/lib/libEGL.so | grep " U " | grep GLI | wc -l => 34
20130222 10:31:56 <xranby> odin_: google have persuaded all GPU driver makers to create a libEGL where EGLNativeWindowType is a "ANativeWindow*" datastructure pointer.
20130222 10:32:04 <odin_> just 34 symbols and well known ones, very standard implemewntations of stdio/memcpy/etc...
20130222 10:32:26 <xranby> odin_: the libEGL on the raspberry pi EGLNativeWindowType is a "EGL_DISPMANX_WINDOW_T" datastructure.
20130222 10:32:53 <odin_> and ?
20130222 10:33:01 <odin_> we can relink android userspace
20130222 10:33:10 <xranby> if you try to pass the android native window pointer to the raspberry pi libEGL you will get an unsupported type error
20130222 10:33:23 <odin_> but you don't do that
20130222 10:33:24 <xranby> yes, it may be possible to recompile the libEGL now
20130222 10:33:40 <xranby> by altering the opensource userspace part of the driver
20130222 10:34:03 <odin_> what is the difference between these pointers? are they opaque or is data directly accessed in client side usage ?
20130222 10:34:12 <odin_> still reading your many comments btw...
20130222 10:34:16 <xranby> one is a pointer and the other one is a structure
20130222 10:34:26 <odin_> well that is good
20130222 10:34:56 <odin_> the userspace of android is using apointer, this is perfect, this means userspace might treat is as opaque and never access it directly
20130222 10:35:24 <odin_> should be easy enough to look over android userspace usage of ANativeWindow*
20130222 10:35:53 <xranby> yes that is the key to get razdroid hardware accelerated
20130222 10:35:58 <odin_> for example in libc some implementations provides "fgetc" as a macro, doing direct access into FILE*, so this usage is not using an opaque pointer
20130222 10:36:39 <odin_> but other implementations provide a real symbol for fgetc to make it link to symbol, now FILE* can change size and providers between versions
20130222 10:36:54 <xranby> you may use the condensed self contained header used by JogAmp NEWT to initialize the broadcom "EGL_DISPMANX_WINDOW_T" datastructure.
20130222 10:36:54 <odin_> I bet android use opaque points, the 2nd option of the above for ANativeWindow*
20130222 10:37:07 <odin_> and this is great for forward/backwards compatibility
20130222 10:37:36 <odin_> s/points/pointers/
20130222 10:38:00 <xranby> odin_: https://github.com/JogAmp/jogl/blob/master/src/newt/native/bcm_vc_iv.h
20130222 10:38:09 <odin_> huh its is very easy to go from a pointer client API to making it the address of a structure
20130222 10:38:25 <odin_> it is very difficult to go the other way, where userspace API uses strctures back to a point
20130222 10:38:35 <xranby> i think you will have a lot easier time to link against this header compared to using the broadcom headers
20130222 10:38:43 <odin_> because if it uses a strcture this means the client API knows the size of it so that can not change between compatible releases
20130222 10:39:06 <odin_> but if you always use a pointer (aka a handle) you can do what you want with the structure even between patch-level release updates
20130222 10:39:15 <odin_> reading your comments
20130222 10:40:09 <odin_> to me... ANativeWindow* == address-of & EGL_DISPMANX_WINDOW_T
20130222 10:40:28 <odin_> and writing a shim layer to do that should be easy
20130222 10:40:36 <xranby> sounds plausible :)
20130222 10:41:25 <odin_> the thing I wish to know is can I use the raspbian libEGL and /opt/vc/lib/* as-is on android
20130222 10:41:42 <odin_> or rather on razdroid
20130222 10:41:57 <xranby> i think you may, both are linux, the only thing you need to add for razdroid is the android security patches
20130222 10:42:03 <odin_> because this razdroid always get a new release when they do
20130222 10:42:12 <xranby> since the android security model differs a bit from traditional linux
20130222 10:42:40 <xranby> so i guess the razdroid kernel already include the andoid security patches
20130222 10:45:50 <xranby> [Mike]: this IRC channel is the new HUB :D welcome
20130222 10:46:48 <odin_> I only started looking yesterday, as I wanted Android on RPi to find out it isn't released yet, there is gamma non-accelerated release
20130222 10:47:04 <xranby> [Mike]: feel free to help out inside the forum https://forum.jogamp.org , help clean up the wiki https://wiki.jogamp.org/ help patch spelling mistakes inside the source repositorys etc.
20130222 10:47:38 <xranby> odin_: i belive broadcom themself are working on a hardware accelerate release but they will only release it if its good enough
20130222 10:47:56 <xranby> odin_: so yeah, right now its community done or nothing
20130222 10:48:31 <odin_> hmm.. I'm informed that broadcom may only release after a community one
20130222 10:48:37 <xranby> odin_: the raspberry pi foundation themself are not interested in android because they belive its consuming oriented and prefer GNU/Linux where you have to learn technology in order to use the Pi
20130222 10:48:55 <xranby> odin_: interesting do you have an url for this broadcom statement?
20130222 10:49:02 <odin_> not sure on the politics of this but maybe they don't really want android to take hold and/or have no real funding for it
20130222 10:49:23 <xranby> all i have read is that they will not rush a release
20130222 10:49:24 <odin_> maybe also that is community release a h/w accelerated version and it is poor, maybe they will step in on marketing front
20130222 10:49:37 <odin_> because maybe they dont wish their chipset/GPU/tech to look bad
20130222 10:49:43 <xranby> exactly
20130222 10:49:58 <odin_> hence why it might not get released until a poor community version is
20130222 10:50:04 <xranby> well the community unaccelerated release have been out for half a year+ now
20130222 10:50:05 <odin_> this is all speculation
20130222 10:50:28 <xranby> so hmm that did not make the cut to push broadcom to release their private accelerated version
20130222 10:50:37 <odin_> yes but unaccelerated, so not a concern for marketing types
20130222 10:50:56 <xranby> broadcom do have an hardware accelerated version today, its been demoed on youtube for months
20130222 10:50:57 <odin_> but to announce an accelerated version that performs poorly, that maybe a concern for marketing types
20130222 10:51:12 <odin_> if it gets uptake and reputation based on it
20130222 10:51:28 <odin_> so why has it not been released in any form?
20130222 10:53:51 <odin_> yes I suspect the RPi Foundation statement is part of the cause of the we shall no rush (i.e. we'll spend a day a month thinking about it)
20130222 10:54:21 <odin_> so to me making the Raspbian EGL DSO and blobs work as-is would be part of the solution
20130222 10:54:36 <odin_> no special build/recompile or anything necessary to get the same updates
20130222 10:55:35 <odin_> this is the VideoCore tree the Raz leader is working on git://github.com/Razdroid/userland.git
20130222 10:56:26 <odin_> lots of churn in it, like unwanted stuff checked in but not too many commits... 41 (some are from upstream raspberrypi/userland.git)
20130222 10:57:02 <odin_> at the moment the doesn't even display any video, but maybe by end of weekend I shall be setup to run it myself
20130222 10:57:55 <xranby> The first valid reason for a broadcom raspberry pi port is.. to run netflix :) http://www.raspberrypi.org/phpBB3/viewtopic.php?p=234080#p234080
20130222 10:59:15 <odin_> does it need a "valid reason" ? android is technically open-source as well, even if it is closed steering and not pushing useful improvements/fixes upstream
20130222 10:59:46 <xranby> "Android isn't a priority. I've always said that. The Foundation has NEVER give any information on an Android release date, so people should not be relying on one. If you really want Android, I'd would take Ray's advice and get something else. The Raspi is not an Android device." http://www.raspberrypi.org/phpBB3/viewtopic.php?p=248295#p248295
20130222 11:00:35 <xranby> jamesh: "if Android were available, the Foundation would sell hat loads more devices. BUT, the Foundations priority is on education, not just selling more devices. If the Foundation were a for profit company, Android would be a higher priority. But it's not, it's an educational charity, where the aims of the Foundation rather than profits, come first."
20130222 11:01:27 <xranby> This is the only and last? video of Android running hardware accelerated on the Pi http://www.raspberrypi.org/archives/1700
20130222 11:01:57 <xranby> 31st of July 2012 by eben
20130222 11:02:07 <odin_> yes indeed 7 months
20130222 11:02:49 <xranby> so all in all they are just smuch and sit on the code untill people have polished rasbian in shape i think :)
20130222 11:03:18 <xranby> then when GNU/Linux performs better compared to android they may release it
20130222 11:03:27 <xranby> so that people dont jump ship
20130222 11:03:49 <odin_> I really don't get the concern, maybe it is more about Android taking over their Education show, than of their focus being on education ?
20130222 11:04:01 <xranby> odin_: i belive that IS the reason
20130222 11:04:12 <xranby> they dont want android to eat the edu cake
20130222 11:04:22 <odin_> i.e. people using android for education, not raspbian for education, I fail to understand how raspbian has performance issues
20130222 11:04:47 <xranby> most of GNU/Linux applications are designed around the idea that the main CPU is powerfull
20130222 11:05:07 <xranby> so it will take time to re-write all the important applications to offload tasks to the GPU
20130222 11:05:28 <xranby> when GPU offloading is in place then GNU/Linux will perform better
20130222 11:05:29 <odin_> huh... you mean non-graphical taks ?
20130222 11:05:36 <xranby> for all kinds of tasks
20130222 11:05:38 <xranby> audio
20130222 11:05:40 <xranby> graphic
20130222 11:05:44 <xranby> video
20130222 11:05:48 <xranby> and like you say processing
20130222 11:05:49 <odin_> huh... you mean non-media tasks ?
20130222 11:06:03 <odin_> to me they are all the same bag
20130222 11:06:11 <xranby> processing is mostly compute
20130222 11:06:21 <xranby> realtime FFT etc
20130222 11:06:29 <xranby> for this we may need OpenCL on the Pi
20130222 11:06:39 <odin_> is this actually being worked on?
20130222 11:06:47 <xranby> because this is not something OpenGL ES shaders are suitable to do
20130222 11:06:49 <odin_> the video core is set in stone now, and new stuff comes out everyday
20130222 11:07:25 <xranby> well. hmm we may create OpenCL libraries using the video core IV reverse engineering effort using the video core iv binutils
20130222 11:07:31 <xranby> but that is a *HUGE* work
20130222 11:07:33 <odin_> whilst the current application might not be driving the VC as well as they could, they can not change the hardware performance and features
20130222 11:07:42 <odin_> and new boards come out every month
20130222 11:08:06 <odin_> you are reverse engineering right ?
20130222 11:08:08 <xranby> the video core iv is an general purpose CPU
20130222 11:08:14 <odin_> this is no a broadcom assisted effort ?
20130222 11:08:17 <xranby> no i am not involved in the reverse engineering
20130222 11:08:23 <xranby> but i try to keep myself informed
20130222 11:08:27 <xranby> on the current progress
20130222 11:08:36 <xranby> no its all community effort
20130222 11:08:42 <xranby> broadcom do not release documentation
20130222 11:08:48 <xranby> unless you sign a NDA
20130222 11:08:49 <odin_> this is an independent matter that is not part of the education vision goals
20130222 11:09:05 <xranby> so the only sane way is to reverse engineer the GPU and release free documentation
20130222 11:09:21 <xranby> it would been great if broadcom opened up
20130222 11:09:31 <xranby> and started to contibute towards a free firmware
20130222 11:09:36 <xranby> but they dont
20130222 11:10:20 <[Mike]> xranby: are there any hardware manufacturers that have an open firmware?
20130222 11:10:34 <xranby> [Mike]: only intel
20130222 11:10:50 <xranby> intel have dumped all their opengl es 3 drivers into mesa
20130222 11:11:05 <odin_> intel have open drivers to hardware interface, the firmware and chip internal is still closed
20130222 11:11:09 <xranby> so linux have opengl es 3 support for intel chips
20130222 11:11:24 <xranby> something that the closed source systems dont have (windows)
20130222 11:11:35 <xranby> odin_: true
20130222 11:12:03 <odin_> the problem is GPU moves so fast, no one want to document it anyway for the cost
20130222 11:12:04 <xranby> odin_: the main difference is
20130222 11:12:14 <xranby> that the shader compiler for the intel chips is inside mesa
20130222 11:12:25 <xranby> while the shader compiler for the broadcom chips is hidden inside the firmware
20130222 11:12:35 <odin_> it is not like a CPU that is well thought out
20130222 11:13:35 <odin_> how big are these binary blobs and isn't there straight *.so to *.c/*.cpp decompiler these days
20130222 11:13:40 <xranby> odin_: the developement of GPU silicon happens soo fast that if you start to study the designs you have in the latest GPU cores you find new kind of architecture that you cant read about in university
20130222 11:14:15 <xranby> for example the ARM MALI 604-t GPU got a FIFO to store the register output after executing instructions
20130222 11:14:32 <xranby> this means that the registers can be pushed into the future
20130222 11:14:45 <xranby> we thus have a multiple instructions single data architecture
20130222 11:14:51 <xranby> something unheard of
20130222 11:15:06 <xranby> and we dont even have models how to write an compiler for this kind of processor
20130222 11:15:09 <odin_> hmm I'm not sure I agree
20130222 11:15:19 <xranby> you cant model this GPU using LLVM
20130222 11:15:21 <xranby> for example
20130222 11:15:24 <odin_> the basic math concepts will already have been used in software for a loooong time
20130222 11:16:10 <odin_> whilst I do not understand the details of the claim there
20130222 11:16:31 <odin_> I look at a database that stores a FIFO queue of data, that can batch process multiple things at once, as being the same kind of system
20130222 11:16:46 <odin_> just in software not hardware, but anything make in software can be converted to hardware, this is a known-known
20130222 11:16:59 <xranby> odin_: Connor Abbott raised this issue in front of the FOSDEM 2013 audience https://fosdem.org/2013/schedule/event/maliisa/
20130222 11:17:19 <xranby> he is working on a ARM MALI command stream compiler for opengl es sl
20130222 11:17:49 <xranby> if you can find a video recording of this talk i am interested
20130222 11:18:16 <odin_> which angle on the issue was raised ?
20130222 11:18:24 <odin_> nothing new, just doing it faster in silicon
20130222 11:19:00 <xranby> well like he put it, he had some issues writing a compiler for this architecture because no previous books described how to do it
20130222 11:19:17 <xranby> he had to write an all custom compiler
20130222 11:19:42 <xranby> maybe you know of litterature that do cover this design
20130222 11:19:52 <xranby> fell free to update connor if you do
20130222 11:20:26 <odin_> I don't know the design, I am not so sure Connor does (know the entire design)
20130222 11:20:40 <odin_> but a compiler is a specific kind of data processor
20130222 11:21:03 <odin_> human managable input data => best format for use on silicon
20130222 11:22:21 <odin_> what maybe better is to model the GPU in software, in the goal to understand it
20130222 11:38:49 <xranby> This was the Raspberry Pi foundations "confession" for pushing closed source code to the educaiton market: Raspberry Pi’s Secret: ‘Sell Out a Little to Sell a Lot’ http://www.wired.com/opinion/2012/09/raspberry-pi-insider-exclusive-sellout-to-sell-out/
20130222 11:40:49 <xranby> and this was their attempt to clense their consiousness: http://www.raspberrypi.org/archives/2221 it do open up the ARM userland and that is a good thing, but like you can see in the comments, devs are not impressed by the closed source Videocore IV GPU firmware that still do all the compilation.
20130222 11:51:31 <odin_> Hmm I don't have a problem, the RPi foundation had to make a lot of choices and if picking a closed source VC blob is the worst they did really well to help educate people no computers
20130222 11:52:08 <odin_> I understand Mr Upton has an interest in broadcom but still I don't believe any other vendor would have given him as good a deal
20130222 11:52:49 <xranby> From JogAmp's perspective the RPi is great, its a platform where you have to offload to the GPU in order to win and this favours solutions like JogAmp JOGL JOAL and JOCL
20130222 11:52:53 <odin_> it is not like there is an obvious open alternative hardware implementation to use, so one blob had to be picked
20130222 11:53:07 <xranby> what we have to do is improving OpenMAX support and then we are basically set
20130222 11:54:27 <xranby> the nice thing about the RPi is that its crystal clear that you cant spend money on an properitary optimized JVM to solve the engineering needs
20130222 11:55:03 <xranby> the only way to get the speed you expect out of the board is to start get used to offload tasks using the dedicated silicon
20130222 11:56:37 <xranby> thus if you use JogAmp to offload tasks to the GPU instead of only using the JVM running on the CPU you can solve the engineering tasks you face
20130222 11:56:59 <xranby> and the choice of JVM dont really matter that much
20130222 11:58:03 <odin_> the JVM matter will be history in 3 years, with the arm64 port and Red Hat's pledge to make it work
20130222 11:58:20 * limbo (jonas@anon) has joined #jogamp
20130222 11:58:23 <odin_> mobile handset will then start to come out with amd64 CPU in 64bit OS and 32bit userspace mode
20130222 11:58:39 <odin_> s/amd64/arm64/
20130222 11:59:08 <odin_> must retrain that typing muscle memory now
20130222 11:59:25 <[Mike]> haha
20130222 12:01:06 <xranby> limbo: welcome to the JogAmp community http://jogamp.org/log/irc/jogamp_20130222050513.html#l9
20130222 12:01:56 <[Mike]> odin_: whats this port you speak of?
20130222 12:02:01 <xranby> limbo: i know you like perl a lot, here we make java work as intended, history and events from 2008-2013 http://labb.zafena.se/?p=656
20130222 12:02:08 <limbo> xranby: cheers, found the discussion interesting but reloading the webpage was annoying, so came here to follow it instead. I probably won't have much relevant input however.
20130222 12:02:25 <odin_> Red Hat have big interest in J2SE Java and the "server" market, so they have pledged to write an ARM64 JIT for OpenJDK
20130222 12:02:39 <odin_> since it will be important to sell servers, software and consulting to them
20130222 12:02:43 <[Mike]> oh very cool
20130222 12:04:26 <odin_> the current mobile market is already pushing the bounds on what ARM can produce, so while the server market will be the focus of initial ARM64 CPUs (since plenty of money per unit to recoup investment, when compared against Intel/AMD pricing)
20130222 12:05:14 <odin_> ultimately mobile will demand that performance too and end up with ARM64 versions for designed a mobile feature set
20130222 12:05:15 <xranby> odin_: an interesting turn of events is that since Oracle finally see the need of a scaled down JRE for mobile use they will reduce the amount of classes needed to maintain for a TCK compatible JRE. David Holmes - JEP 161 Java SE Compact Profiles has been pushed to jdk8/build forest http://bit.ly/Xl2dWb #java #embedded
20130222 12:05:56 <odin_> well project "Coin" is the one meant to do this?
20130222 12:05:58 <xranby> so by compiling OpenJDK 8 we can finally have a core modular JRE without the legacy fluff
20130222 12:06:10 <xranby> odin_: project coin never managed to do this
20130222 12:06:46 <xranby> but now with this JEP 161 in place will make Oracle cut down the burden for implementors to create a fully "Java"(tm) compatible runtime environment
20130222 12:07:11 <odin_> they should release Java8 with working version (with deprecated workarounds in place) and announce in Java9 to remove those to clean entire API
20130222 12:07:16 <xranby> and this may allow JogAmp to compile build a new JRE (JogAmp runtime environment) that is Oracle patent safe
20130222 12:07:47 <xranby> so that we may deploy JogAmp on any device with minimal TCK teting burden
20130222 12:08:04 <odin_> so it will be like the Java5 split where things are generally still java 1.4 or 5 compatible
20130222 12:08:21 <odin_> the same will be true of QtJambi :)
20130222 12:08:33 <xranby> yep, a QRE :D
20130222 12:08:48 <odin_> Qt is already modular feature set, and one of the future issues it getting Mb's on disk footprint down
20130222 12:09:04 <xranby> http://openjdk.java.net/jeps/161 "The TCK’s test agent must not require the use of any APIs outside of the compact1 Profile."
20130222 12:09:12 <xranby> that is the sweet part!
20130222 12:09:26 <odin_> it needs very little of the Java API itself maybe just 6 packages
20130222 12:09:48 <odin_> yes for Compact profile compliance but there will be a "Full J2SE TCK" as before surely
20130222 12:10:12 <xranby> compact1 includes java.io java.lang java.math java.net java.nio and some extra security fluff
20130222 12:10:14 <odin_> having a sub-set profile is fine to me, I am considering that for future of Qt Jambi, as full API maybe just too big and not needed
20130222 12:10:17 <xranby> but basically all you need
20130222 12:10:39 <odin_> that does look like all we need :) if not we make minor change in the areas
20130222 12:10:47 <xranby> *high five*
20130222 12:11:12 <xranby> so we can have reduced footprint and perhaps dont even need to compress everything inside a zip jar
20130222 12:11:18 <xranby> so that we can have faster startup time
20130222 12:11:25 <odin_> 75% of QtJambi on disk size, is ELF symbol and relocation data
20130222 12:11:27 <odin_> get that
20130222 12:11:36 <xranby> sweet
20130222 12:11:49 <xranby> i look forward to QTJambi + JOGL integration
20130222 12:11:53 <odin_> JNI is not efficient for linking and I have idea to modify OpenJDK (or some JDK) to support a new annotation to allow jump-table linking
20130222 12:12:02 <xranby> so that you can have QT5 UI and JOGL OpenGL ES
20130222 12:12:21 <odin_> we're talking over 15Mb of ELF symbol and relocation data
20130222 12:12:53 <odin_> but new annotation @JNI(table=1, id=1023)
20130222 12:13:05 <odin_> will put the data into discardable (at runtime) *.class data
20130222 12:13:26 <odin_> and may only cost the 8 bytes per ELF relocation slot entry in the resulting DSO file size
20130222 12:13:51 <odin_> right now we have symbol data like: Java_com_trolltech_qt_gui_QGraphicsTextItem__1_1qt_1paint_1QPainter_1nativepointer_1QWidget__JJLcom_trolltech_qt_gui_QStyleOptionGraphicsItem_2J
20130222 12:14:40 <xranby> odin_: this is of course allw elcome
20130222 12:14:41 <odin_> that is a string eating cache space during linking, when ELF still support classic ordinal tables
20130222 12:16:01 <odin_> I am thinking it would work with a post compile pass, i.e. with output *.so and output *.class and edit both
20130222 12:16:23 <odin_> also probably work with minimal effort on all ELF systems
20130222 12:16:55 <xranby> odin_: JogAmp gluegen can be easily adopted to use new JNI calling conventions
20130222 12:17:21 <xranby> we re-create the binding using gluegen from opengl c header files on each build
20130222 12:17:39 <xranby> so that we dont have to do manual work writing the opengl <-> java binding
20130222 12:18:39 <xranby> do use the same GlueGen trick to bind OpenAL into JOAL and OpenCL into JOCL etc...
20130222 12:18:46 <xranby> automagically
20130222 12:18:53 <xranby> so that we have free time sit here and chat ;)
20130222 12:19:12 <odin_> same in QtJambi but it support C++ API and various additions to C++ that Qt provides (it uses a tool moc.exe to build type data into a descriptor, it has a runtime type system, not using RTTI)
20130222 12:19:21 <xranby> oh interesting
20130222 12:19:31 <xranby> GlueGen is currently only a C header parser
20130222 12:20:24 <xranby> https://jogamp.org/gluegen/www/
20130222 12:20:54 <xranby> https://jogamp.org/gluegen/doc/manual/
20130222 12:21:11 <odin_> this all integrated with Java nicely, hence C++, QML, JS (via webkit) and all 3rd party *.so modules all work with Java
20130222 12:22:08 <xranby> odin_: feel free to post links to the QTJambi C++ generator
20130222 12:22:09 <odin_> the QtJambi "generator" as it is called, understand C++ stuff like inheritance, interfaces, they (TrollTech) did a good job in all
20130222 12:23:37 <odin_> http://qt-jambi.org/doc/generator (the PDF link in page is an article they did on it, but that link probably broken in Nokia => Digia move 3 months ago)
20130222 12:24:36 <xranby> http://web.archive.org/web/20120412190606/http://doc.trolltech.com/qq/QtQuarterly29.pdf
20130222 12:25:17 <odin_> http://doc.qt.digia.com/qq/QtQuarterly29.pdf the code is at http://qt.gitorious.org/qt-jambi/qtjambi-community/trees/master/generator
20130222 12:26:01 * [Mike] (~Mike]@anon) Quit (Read error: Connection reset by peer)
20130222 12:26:29 <xranby> odin_: thank you
20130222 12:27:07 <odin_> it is based on the KDE development C++ parser and AST tokenizer from ~2009ish
20130222 12:27:44 <odin_> but I would like to re-write on top of Eclipse CDT parser with C++1x support and also in Java
20130222 12:27:46 <xranby> hehe its like all projects became forks and opensource in the large finance crisis of 2009
20130222 12:27:47 <odin_> but might never happen
20130222 12:28:24 <odin_> well no the KDE development IDE still goes on just no one updated the parser used in generator
20130222 12:28:27 <xranby> This is my favourite view on how global economics affects opensoure http://www.ohloh.net/languages/compare?measure=contributors&percent=false
20130222 12:28:55 <xranby> i belive ohloh have screwed up the 2013 stats :3
20130222 12:29:43 <odin_> interesting that it peaked at the crisis and obviously since many people not in full employment and have time to contribute
20130222 12:29:51 <xranby> yup
20130222 12:30:09 <odin_> maybe the upturn is a good crisis indicator ?
20130222 12:30:30 <xranby> yes, since at the peak a lot of code became forks
20130222 12:30:43 <xranby> and people left and took the source with them
20130222 12:30:48 <odin_> when the chart start moving upwards, take your investments out of risk stuff and put into assets
20130222 12:31:10 <xranby> how to win on the stock market opensource trend style
20130222 12:31:22 <xranby> hehe
20130222 12:31:49 <xranby> well now when all the peaks are at the bottom all we can go from now is up? :3
20130222 12:31:51 <odin_> obscene symbols !! Java_com_trolltech_qt_gui_QGraphicsLayoutItem__1_1qt_1getContentsMargins_1nativepointer_1nativepointer_1nativepointer_1nativepointer__JLcom_trolltech_qt_QNativePointer_2Lcom_trolltech_qt_QNativePointer_2Lcom_trolltech_qt_QNativePointer_2Lcom_trolltech_qt_QNativePointer_2
20130222 12:31:59 <xranby> OMG :D
20130222 12:32:29 <limbo> that almost looks like it could be a function name in php
20130222 12:33:30 <odin_> libcom_trolltech_qt_gui_debuglib.so.1 110,041,142 bytes, size libcom_trolltech_qt_gui_debuglib.so.1 => text=20667502, bss=394376
20130222 12:34:02 <xranby> limbo: Ermah-he-haha-hi-gerd!!!!
20130222 12:34:11 <odin_> luckily optimized version is more like 10Mb and 75% symbol and relocation data
20130222 12:34:25 <xranby> odin_: that sounds like a better way to invoke the function :D
20130222 12:35:07 <xranby> odin_: well i assume the linker will replace the symbol names with direct jumps
20130222 12:35:21 <xranby> so its only a startup overhead
20130222 12:35:25 <odin_> yes they are only used for lookup, there is still a PLT in there that is setup
20130222 12:36:32 <odin_> well I think lazy linking is the norm, but there is system relocation fixups these days with some randomization scheme
20130222 12:37:10 <xranby> odin_: jogamp are moving more and more towards lazy initialization as well
20130222 12:37:16 <xranby> it do speed up startup time
20130222 12:37:50 <odin_> I believe ELF can use ordinal offsets into tables with no related symbol pointer
20130222 12:38:26 <odin_> the problem mainly is making JVM be able to get function pointer
20130222 12:38:59 <xranby> will GCJ (static compilation) cut it?
20130222 12:39:07 <xranby> perhaps use RoboVM
20130222 12:39:22 <odin_> I tried GCJ before but I need some help to understand some things better
20130222 12:40:18 <xranby> http://labb.zafena.se/?p=673 - RoboVM compiles Java to native code
20130222 12:41:07 <xranby> odin_: GCJ usage examples http://www.raspberrypi.org/phpBB3/viewtopic.php?f=34&t=15745&p=159779&hilit=gcj#p159779
20130222 12:41:52 <odin_> now not time to look, must get stuff I have already merged on Jambi project before looking for new things
20130222 12:42:17 <xranby> odin_: good idea, i am known to inject distraction :D
20130222 12:42:34 <xranby> by handing out URL link leads
20130222 12:42:36 <odin_> it was more a test to see what GCJ made of Jambi and it took ages to run some pass and produced some huge files, but I need to understand GCJ internals
20130222 12:43:16 <xranby> odin_: yes thats usually the GCJ critique, but it have been known to compile native fast versions of eclipse
20130222 12:43:30 <xranby> but the compilation took indeed ages
20130222 12:44:13 <xranby> so GNU/Linux opted out in order to have a fast security patch workflow
20130222 12:44:24 <xranby> distributions like Debian that is
20130222 12:44:54 <xranby> When i benchmark GCJ it is still really good
20130222 12:45:14 <xranby> for example it can produce better code compared to Oracles properitary Hotspot on ARM
20130222 12:46:04 <xranby> the cons are that GCJ only work in combination with GNU Classpath that only implements Java 1.5 and not complete java.nio
20130222 12:46:23 <xranby> so if someone updated GCJ to use the OpenJDK 8 classes it would be great
20130222 12:47:52 <odin_> go to reboot (logout of desktop at least), some file-nr issue leaks over 2 weeks
20130222 12:47:56 <xranby> odin_: thank you for the fruitful discussion
20130222 12:48:01 <xranby> it was a pleasure
20130222 12:48:48 <odin_> cat /proc/sys/fs/file-nr => 193376 0 291350 .. can not find any process with /proc/<pid>/fd/* open maybe it is ipc handles
20130222 12:50:04 <xranby> limbo: GCJ is the GNU compiler collections java compiler that treats java classfiles and source like C and uses the same backend inside GCC to statically compile the code into native applications
20130222 12:50:46 <xranby> so by using it you basically gets all the benefits from coding in a high level language and the raw speed you are used from the c compiler
20130222 12:51:12 <xranby> there is still some cases where dynamic JIT compilation do generate better code
20130222 12:51:52 <xranby> for example the JIT compiler can remove all unlikely flows of execution and generate a reduced function that do run faster compared to the statically compiled version
20130222 12:52:11 <xranby> and then add hooks to de-optimize if the unlikely code paths are taken
20130222 12:54:15 <odin_> back in a moment
20130222 12:54:22 * odin_ (~Odin@anon) Quit (Quit: Leaving)
20130222 13:04:36 <xranby> http://forum.jogamp.org/Jogamp-and-Jazz-periments-td4028319.html - Jogamp and Jazz(periments) a nice read for any music lovers
20130222 13:05:18 <xranby> pidgin... irc client... please fix my grammar :)
20130222 13:17:43 * odin_ (~Odin@anon) has joined #jogamp
20130222 13:20:04 <xranby> wow the first java on raspberry pi post went online, i have now commented it to inform people about the jogamp GPU solutions http://www.raspberrypi.org/archives/3334
20130222 13:21:37 <xranby> my comment is still inside the review queue
20130222 13:21:43 <xranby> but it will get there eventually
20130222 13:31:18 <xranby> now online
20130222 13:33:55 <xranby> Matt H: Thanks! that’s extremely useful!
20130222 13:47:26 * xranby (~xranby@anon) Quit (Ping timeout: 252 seconds)
20130222 14:28:02 * juank_prada (~juank__@anon) has joined #jogamp
20130222 14:44:54 * juank_ (~juank__@anon) has joined #jogamp
20130222 14:48:17 * juank_prada (~juank__@anon) Quit (Ping timeout: 244 seconds)
20130222 15:04:59 * xranby (~xranby@anon) has joined #jogamp
20130222 15:13:06 * juank_ (~juank__@anon) Quit (Read error: Connection reset by peer)
20130222 15:13:32 * juank_ (~juank__@anon) has joined #jogamp
20130222 18:27:09 <xranby> http://www.raspberrypi.org/archives/3334#comment-40182
20130222 18:45:41 * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
20130222 18:54:43 * juank_prada (~juank__@anon) has joined #jogamp
20130222 18:56:11 <xranby> DemoscenePassiv: hi, have you got your hands on any OpenGL ES 2 hardware before revision?
20130222 18:56:40 <xranby> that you may use to shader render fill the compo screen
20130222 18:57:19 * juank_ (~juank__@anon) Quit (Ping timeout: 244 seconds)
20130222 18:57:39 <xranby> and perhaps implement a neat defered rendering demo on :D
20130222 19:27:17 * xranby_ac100 (~xranby@anon) has joined #jogamp
20130222 21:17:16 <odin_> woot I have successfully built raspberypi/userland.git using android-ndk-r8d/arm-linux-androideabi-4.4.3 (API level 9)
20130222 21:17:19 <odin_> also earlier raspberypi/userland.git native on raspbian to confirm it built
20130222 21:17:38 <xranby_ac100> odin_: how long did it take to compile?
20130222 21:17:51 <odin_> on my linux box not long
20130222 21:18:19 <xranby_ac100> all in all, nice
20130222 21:18:45 <odin_> ~3mins
20130222 21:19:21 <xranby_ac100> which cross compiler did you use?
20130222 21:19:22 <odin_> checking over it, it looks like to bionic/userspace ok
20130222 21:19:44 <odin_> android-ndk-r8d/arm-linux-androideabi-4.4.3 http://developer.android.com/tools/sdk/ndk/index.html
20130222 21:20:30 <xranby_ac100> what did you have to do to make the code armv6 optimized?
20130222 21:20:43 <odin_> android-ndk-r8d NDK release/revision "8d" and the toolchain inside it arm-linux-androideabi-4.4.3 (which is oldest) from 4.4.3, 4.7, 4.7 and clang3.1
20130222 21:21:45 <odin_> things like that I've really got to check, I have --sysroot as appropriate for API level 9 userspace (most recent API level is 14)
20130222 21:22:16 <odin_> -mcpu=arm1176jzf-s was used
20130222 21:22:38 <xranby_ac100> "— ARMv5TE is the default, but switching to ARMv7-A is as easy as adding a single line to the application'sApplication.mk file"
20130222 21:22:38 <xranby_ac100> ok nice
20130222 21:22:54 <odin_> raspberypi/userland.git in makefiles/cmake/toolchains/razdroid.cmake has -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard
20130222 21:23:10 <xranby_ac100> perfect
20130222 21:23:55 <odin_> opps thats the file I made but I meant copied from original
20130222 21:27:05 <odin_> I built a toolchain dir, like... http://pastebin.com/nLSbbiqA
20130222 21:27:31 <odin_> magic bash script to apply --sysroot=$SYSROOT
20130222 21:28:26 <odin_> must get food
20130222 21:40:02 <juank_prada> hi guys, any idea on how to use nifty gui with JOGL2?
20130222 21:58:43 <xranby_ac100> juank_prada: gouessej demoed nifty gui with JOGL2 at siggraph2012 http://jogamp.org/doc/siggraph2012
20130222 21:59:26 <xranby_ac100> juank_prada: thus i recommend you to ask him using the forum
20130222 21:59:31 <juank_prada> xranby, thanks
20130222 22:00:38 <juank_prada> xranby_ac100, ^
20130222 22:01:01 <xranby_ac100> juank_prada: youre welcome :)
20130222 22:05:10 <xranby_ac100> juank_prada: http://youtu.be/7mBi7psP7VM?t=3m29s you can see it running here at 3m29s into the siggraph 2012 jogamp teaser
20130222 22:05:59 <xranby_ac100> well it was a short clip hehe
20130222 22:11:43 <xranby_ac100> juank_prada: http://www.youtube.com/watch?v=gYoj2s18GxU?t=7m45s here is the nifty gui from the full session video with commentary
20130222 22:22:19 * hharrison (~chatzilla@anon) has joined #jogamp
20130222 22:26:51 * xranby_ac100 (~xranby@anon) Quit (Read error: Connection reset by peer)
20130222 23:01:58 * juank_prada (~juank__@anon) Quit (Quit: Leaving)
20130222 23:03:50 * [Mike] (~Mike]@anon) has joined #jogamp
20130222 23:05:08 * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 252 seconds)
20130223 05:05:27 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130223050527.html