This is a retarded workaround and we should really figure out why EGL breaks down the V8 Context on raspberry pi.
maanantai, 3. syyskuuta 2012 9.53.39 UTC+3 Luis Reis kirjoitti: > > Hi again, > > I've found a solution to this problem, so, for anyone interested in > running node with OpenVG / OpenGL ES on the Raspberry Pi: > > The problem with EGL initialization is that it messes up V8 contexts. I've > found out that if EGL is initialized before V8 boots, everything seems to > run fine. > > The trick I've used is to use LD_PRELOAD to load a library that will > preinitialize broadcom's video core and EGL before node boots. This code is > already published at the github project mentioned in the previous message. > > I don't know for now if this solution is insufficient further down the > road (eg, instantiating buffers), but I'll stick to it for now. > > Thanks to anyone who spent time on this, > Best, > Luis > > On Sunday, September 2, 2012 2:49:29 AM UTC+1, Luis Reis wrote: >> >> Hi guys, >> >> I've just created this repository on github: >> https://github.com/luismreis/node-openvg >> >> I'm attempting to create bindings for OpenVG to get access to hardware >> acceleration. DirectFB seems slow at higher resolutions, and initial tests >> with SDL (using node-sdl) weren't very conclusive. >> >> I'm facing this problem: I can call broadcom's init function, but, as >> soon as I call the EGL (bindings between window system and OpenVG/Open GL >> ES) apis, I get stuck on an internal V8 function. >> >> The stack trace for my main thread is: >> >> #0 0x002a719c in >> v8::internal::JSReceiver::LocalLookup(v8::internal::String*, >> v8::internal::LookupResult*) () >> #1 0x002a7ce4 in v8::internal::JSReceiver::Lookup(v8::internal::String*, >> v8::internal::LookupResult*) () >> #2 0x003d9614 in >> v8::internal::LookupForRead(v8::internal::Handle<v8::internal::Object>, >> v8::internal::Handle<v8::internal::String>, v8::internal::LookupResult*) >> [clone .constprop.66] () >> #3 0x003db7ec in >> v8::internal::LoadIC::Load(v8::internal::InlineCacheState, >> v8::internal::Handle<v8::internal::Object>, >> v8::internal::Handle<v8::internal::String>) () >> #4 0x003dbe80 in v8::internal::LoadIC_Miss(v8::internal::Arguments, >> v8::internal::Isolate*) () >> #5 0x2d30a09c in ?? () >> #6 0x2d30a09c in ?? () >> >> The output of my hello.js app is: >> >> Waiting 4 seconds >> Calling init. >> Calling eglGetDisplay... >> eglGetDisplay returned: 0x00000001. >> vgInit done! >> openvg::Init done! >> >> If this didn't halt that output should be followed by something similar >> to: >> >> Got back from init. >> Waiting 3 seconds >> Waiting 2 seconds >> Waiting 1 seconds >> Calling finish. >> Got back from finish. >> >> "openvg::Init done!" is the last thing executed in my native code. So, my >> conclusion is that my code runs successfully but it somehow breaks >> something internal to V8/node. Notice that the waiting function (triggered >> by a setTimeout) also gets stuck. >> >> Broadcom's init function (bcm_host_init()) starts something like 4 or 5 >> threads related to processing remote control commands and multimedia >> functions, but, if it's the only thing executed the test script runs fine. >> >> Any hints ? >> >> Note 1: I'm trying to build node with debug support. With my standard >> configuration gdb breaks with "Illegal instruction" reading SSL related >> libraries before running anything. >> >> Note 2: This may be of interest to anyone implementing OpenGL ES bindings >> on the raspberry. I think the same sequence of going through EGL is also >> required. >> >> Thanks, >> Luis >> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
