gnash has an OpenGL output but do you think it will speedup something on our systems??
I don't have a clue how Gnash outputs, nor how it was adapted to work on AmigaOS4. If you reckon that OpenGL output would be worse, then I will take your word!
According to this post on the LLVM mailing list LightSpark uses LLVM's JIT as well as OpenGL. If the next version of the OS 4 SDK supports LLVM it might be possible to port to OS 4.
-edit- According to the LightSpark webpage it requrires GLSL shaders also. This means that until we get a full implementation of MESA or OpenGL, this product is a no-go. If the next version of the OS 4 SDK supports shaders then there is a chance.
LightSpark looks like a project that's worth keeping an eye on. IIRC, the biggest problem with Gnash is that its code is not reentrant. Added to that, the two hardware accelerated backends, Cairo and OpenGL, are incomplete, and not maintained as well as the software only one (whose name I have forgotten). If the Cairo backend worked fully, then Gnash might work faster on OS4 due to HW accelerated Cairo.
I'm still hoping that the Gnash development team will solve the issues, but LightSpark looks interesting. When we have the dependencies working I'd be okay with the Gnash bounty being modified to a LightSpark port. It's flash support that we want, not Gnash specifically.
@Samurai_Crow
Quote:
Samurai_Crow wrote: @ChrisH
According to this post on the LLVM mailing list LightSpark uses LLVM's JIT as well as OpenGL. If the next version of the OS 4 SDK supports LLVM it might be possible to port to OS 4.
What would be required to get LLVM's JIT running on OS 4?
I just had a quick look at the Lightspark code, and it's only 1.42 MiB (at the moment). It looks quite clean, but does suffer from the lack of comments/documentation that is typical of so many open-source projects.
I personally find that it is better to spend a little extra time documenting your code as you write it, then writing the code and telling yourself that "I'll get round to documentation later." Sure, if you rewrite something then you have to rewrite any associated documentation too, but it's hard to document (or use) code that you wrote so long ago that you've forgotten exactly how it works. This happens very easily on big projects.
What would be required to get LLVM's JIT running on OS 4?
Since the Apple people have already written a PowerPC backend for LLVM it shouldn't be too hard. There are some rough instructions about writing an LLVM backend so the work of writing an LLVM backend will mostly be related to porting the system class to do all of the things the Mac and Linux do.
The JIT part of it will have to be able to write to main memory with the executable bit set in AmigaOS so the memory allocation parts may need some tweaking. Keep in mind, though, that the LLVM JIT already runs on PPC Macs so it shouldn't need a whole lot of work.
I've been reading a little about LLVM and would like to know if I had undertand correctly.
With LLVM a developer, instead of releasing an executable, can release an intermediate code (or form or object) so the users can download it, and provided they have LLVM installed, the first time they "run" the program LLVM will finish compilation, providing the best executable for the machine type (combination of GFX and CPU for example). So the final executable would be different depending of your setup. Is that correct?
@emeck While what you state might be possible, I thought the general idea was simply to provide unified exectuable code generation (for both compilers & JIT). Rather than generating 68k or x86 or PPC assembler, you generate LLVM assembler, and it then does the job of creating an executable your CPU can understand.
I think one problem with your suggestion is that the LLVM "intermediate code" might be CPU independant, but it won't be OS independant!
ChrisH wrote: I think one problem with your suggestion is that the LLVM "intermediate code" might be CPU independant, but it won't be OS independant!
Ah, I see. That would be a problem. But in our case, gnash or lightspark (trying to stay on topic ) developer would be aiming at AOS4/PPC so that wouldn't be a problem. And that way, the best executable could be created for A1(G3/G4), SAM(440/460) and X1000.
Actually gnash is improving the speedup part but since it use VA-API to accelerate the playback, it is unusable on os4. so the only way to accelerate it is using a Cairo hw accelerated backend.
Ok Andrea but how about the network's problem ? I mean, for what I can see (I've try a lot of local files) the main issue (bug ?) of the actual Gnash implementation remaining the internet streaming.
Local files works (also good games!) at quite decent speed also on my slow Sam but for any other using (like streming in YouTube) is an hell, so do you think that the future Cairo acceleration can help also in this area ?
ChrisH wrote: @emeck While what you state might be possible, I thought the general idea was simply to provide unified exectuable code generation (for both compilers & JIT). Rather than generating 68k or x86 or PPC assembler, you generate LLVM assembler, and it then does the job of creating an executable your CPU can understand.
I think one problem with your suggestion is that the LLVM "intermediate code" might be CPU independant, but it won't be OS independant!
It all depends on which programming language you use to generate your IR code. Mattathias will be an install-script away from installing on any LLVM-supported OS but we'll have to write the installer scripts in a system-specific way. C++, on the other hand, compiles system-specific macros in its preprocessor headers making it difficult to write truly cross-platform IR code. Flash and Java players built on LLVM will be cross platform assuming that the player itself was written cross platform.
Lightspark seems to be written for Linux but if we can port it to AmigaOS then that would be great!
Lightspark seems to be written for Linux but if we can port it to AmigaOS then that would be great!
The code has Visual studio project files, so I'd say that it's multi-platform. I do hope that he changes it to a slightly more permissive license than GPLv3 though.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
) developer would be aiming at AOS4/PPC so that wouldn't be a problem. And that way, the best executable could be created for A1(G3/G4), SAM(440/460) and X1000.
