[Papervision3D] PapervisionX, CS4 Branch of Papervision3D, and GPUs
Paul Andrews
paul at ipauland.com
Mon Sep 21 14:35:36 PDT 2009
ash davis wrote:
> I like the sound of that, Brainwave API!
>
There are some people whose brainwaves I'd rather not see visualised..
>
> --- On *Mon, 21/9/09, Nick Collins /<ndcollins at gmail.com>/* wrote:
>
>
> From: Nick Collins <ndcollins at gmail.com>
> Subject: Re: [Papervision3D] PapervisionX, CS4 Branch of
> Papervision3D, and GPUs
> To: papervision3d at osflash.org
> Date: Monday, 21 September, 2009, 7:24 PM
>
> "I would be more concerned with HTML5; if the browser
> manufacturers ever get their shit together and standardize then
> Flash will have a much stronger competitor in my view."
>
> LOL, like that'll ever happen. By the time a mainstream,
> cross-platform browser is 100% standards compliant, we'll be on
> Flash 20 and have full hardware accelerated 3D in Flash, that will
> be controlled by mere thought.
>
> On Mon, Sep 21, 2009 at 12:09 PM, Mark I. Ross
> <nospam at therossman.org </mc/compose?to=nospam at therossman.org>> wrote:
>
> It doesn't matter if Silverlight is faster, if no-one has or
> will install the plug-in; or if no developers pick it up and
> develop killer apps for it.
> Silverlight is interesting but it's still not any threat to
> flash as far as I can tell.
>
> I would be more concerned with HTML5; if the browser
> manufacturers ever get their shit together and standardize
> then Flash will have a much stronger competitor in my view.
>
> Just my 2 cents,
> mark
>
>
> John McCormack wrote:
>
> Thanks Mark. It's that hardware again!
>
> I don't seek to "blame", I get the performance I need for
> my applications, but I am curious.
>
> With Windows you have that common code offered by the
> drivers complying with Microsoft's requirements. Anything
> running on a PC would have that available. Macs probably
> have something similar. If they don't, the VM would call
> appropriate code. I guess we are not talking about that
> many different functions anyway: send data to video ram;
> copy between banks of ram; etc.
>
> I just think that with Microsoft's ability to write the
> specs that Silverlight will, no doubt, get what it needs.
> They will have the problem with Macs of course. For
> "non-GPU accelerated platforms" they could just drop down
> to their own software renderer, as you suggest.
>
> So it all seems possible!
>
> John
>
>
> Yes I can see that
>
> Mark I. Ross wrote:
>
> This comes down to platform dependance.
>
> Yes Adobe could make a call to DirectX to draw
> something faster. But then what happens when they are
> on Linux, or Mac? DirectX is not available on those
> platforms, so they would need to do something
> different. That windows, mac, and linux all have
> different graphics subsystems is where the problems
> start. Additionally, what about platforms (mobile or
> low-end) that don't have GPU's? In this case they need
> a software fallback.
>
> Unfortunately it's not as simple as just blaming them
> for not having GPU hardware acceleration, if they
> suddenly enabled GPU support but still had to fall
> back to a software renderer for platforms without
> GPU's, what happens then? Should it be ok for
> something written on high end windows hardware in
> flash to run like 1fps on a mobile, non-GPU
> accelerated platform?
>
> I don't know the answers to these things but I assume
> Adobe has a strategy of some kind!
>
> Cheers,
> mark
>
> John McCormack wrote:
>
> Yes, I can see that Alchemy can only give you the
> same AS compiled byte code but behind that byte
> code is real hardware dependent machine code. I
> assume that the virtual machine takes the byte
> code and uses equivalent machine code to do the
> byte code task requested.
>
> If so, it seems a small jump to then call specific
> functions that transfer data more quickly, such as
> for DirectX, OpenGL etc.
>
> Is there some inherent reason why a byte code
> sequence cannot be interpreted as a particular
> function call? After all, the virtual machine
> itself was probably written with C/C++ and the
> byte code decoder just needs to read the code and
> call the function. I am still missing something.
>
> John
>
> Aleksandar Mancic wrote:
>
> Alchemy does nothing more than compiling C/C++
> to FVM bytecode, so everything you write in
> C++ you can write as well in AS, or better -
> what AS cannot do, your C++ code wont be able
> to do as well. It's essentially a tool to
> allow you to write code for FVM in other
> language than AS, and alleged speed gains are
> not from the direct system calls (your C++
> `code` still executes within FVM sandbox) but
> from more optimized calls to the FVM internals
> as it does not need to support AS heuristics.
> Due to that avoidance (ommited constructors,
> data types etc.), in most cases you need to
> rely on ByteArray for data exchange between
> your C++ and AS code, which in turn, if not
> used wisely, can actually make your imported
> C++ libs even slower than re-writing them in
> pure AS.
>
> I've tried to port some of the crucial
> calculations of PV3D into C++ and then use it
> through Alchemy - it ended up considerably
> slower due to the loss in data exchange. So,
> no, Alchemy is not a magic wand that could
> make PV3D any faster than it already is, nor
> it can do any kind of system calls that you
> cannot do through AS. From personal
> experience, it's only useful for porting some
> large libs that are not called frequently (or
> at least don't need to exchange data
> frequently with the rest of the applications),
> otherwise it doesn't bring anything new to the
> Flash platform.
>
>
> On Mon, Sep 21, 2009 at 10:43 AM, John
> McCormack <john at easypeasy.co.uk
> </mc/compose?to=john at easypeasy.co.uk>
> <mailto:john at easypeasy.co.uk
> </mc/compose?to=john at easypeasy.co.uk>>> wrote:
>
> Ah, so Alchemy is from C to byte code and not
> the reverse.
>
> It must be true to say that byte code in the
> virtual machine must
> result in system calls to the same functions
> called from C. If
> not, how else can they transfer data for an
> image across to the
> graphics driver? If those can be done why
> can't they also use
> calls that write to the hardware directly?
>
> I must be missing something.
> Puzzled!
>
> John
>
>
> Stig Kristiansen wrote:
>
> No, you cannot.
>
> Alchemy just compiles C/C++ into the same byte
> code that
> Actionscript 3 does and runs in the same
> virtual machine in
> the Flash Player as Actionscript 3 does.
> Alchemy C/C++ cannot
> access any more hardware than you can with
> Actionscript 3.
>
> Access to the API's like DirectX, OpenGL etc
> is not possible
> just because you use C/C++ but because your
> source code
> compiles to native code that have access to
> the supporting
> libraries supplied by the operating system.
> This can as easily
> be done with any language and could even be
> done in theory
> with Actionscript 3 if someone made a compiler
> that compiles
> to native machine code and not code for the
> Flash Players
> virtual machine.
>
> The most likely way for hardware accelerated
> rendering in
> Flash to happen would be for Adobe to build
> this into the
> Flash Player themself. I do not think this is
> likely to happen
> anytime soon because that would up the minimum
> hardware
> requirements for the Flash Player to a level I
> suspect is
> unacceptable for Adobe.
>
> John McCormack wrote:
>
> Adobe can make calls to C++ with Alchemy and
> C++ has links
> to the hardware through HAL, the Hardware
> Abstracted
> Layer, which provides a common set of API calls to
> different hardware.
> What we get with HAL is Direct X, etc., and
> hardware
> independence.
> I would think that Adobe will manage it soon
> since the
> system and bodies of code are there already.
>
> John
>
> Mark I. Ross wrote:
>
> Using the native 3D calls in flash 10 isn't
> the same
> as GPU acceleration.
>
> They will of couse be faster versus something
> written
> in actionscript (ie. PV3D) because Adobe will have
> optimized the Flash Player runtime to execute
> their 3D
> transforms/3D math as fast as possible within
> the core
> flash player. Again, this is not the same as GPU
> acceleration. This is Adobe giving us optimized 3D
> math functions basically, which isn't a bad
> thing, to
> be sure, and don't think of this post as me taking
> anything away from what they are doing, I'm
> all for
> it. I just wish they could give us some real GPU
> acceleration so we'd have a flash player that
> could
> compete with Unity3D in terms of graphics
> capability.
> It's harder for them because no doubt
> Win/Mac/Linux
> all use different graphics subsystems.
>
> Again, as far as I am aware, there is no
> actual GPU
> acceleration support in the flash player for
> bitmap
> drawing and/or rendering. They do use some
> hardware
> scaling for video and also have the gpu browser
> compositing feature, but they still have a
> long way to
> go :)
>
> Cheers,
> mark
>
>
More information about the Papervision3D
mailing list