Page 1 of 5 123 ... LastLast
Results 1 to 10 of 48

Thread: Lightspark May Work Towards A Gallium3D State Tracker

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,788

    Default Lightspark May Work Towards A Gallium3D State Tracker

    Phoronix: Lightspark May Work Towards A Gallium3D State Tracker

    With the Gallium3D driver architecture there's state trackers for Mesa, OpenVG, OpenGL ES 1.1/2.0, and even most recently one for exposing Direct3D 10.0/11.0 on Linux. These state trackers are then what can run on the Gallium3D hardware drivers or even on the CPU in the case of Softpipe and the much more interesting LLVMpipe. There's even now a new Gallium3D state tracker being contemplated by the Lightspark Flash Player project...

    http://www.phoronix.com/vr.php?view=ODY0Ng

  2. #2
    Join Date
    Jul 2009
    Posts
    47

    Default

    Yay, let's do state trackers for every program, so all of my desktop relies on the latest version of Mesa/Gallium, the Kernel and libdrm.

    Seriously, it's just flash, not rocket science. Just simply use one of the existing backends for gpu-offloading, try to get the flash-API right and it'll work. I have nearly no CPU/GPU-workload while playing 1080p-Videos on Windows, just get to that state instead of trying insane perfomance enhancement schemes.

    Also I bet having Mesa-invasive changes as a dependency will be hell to package, but seeing how Lightspark doesn't even have the goal of fully supporting the Flash-spec(that would be Gnash, which actually works okay, thank you very much fsf), but rather "modern features" of the language, aka whatever the devs feel like that won't matter that much. Gnash ftw.

  3. #3
    Join Date
    Oct 2009
    Posts
    60

    Default

    Quote Originally Posted by fabiank22 View Post
    Seriously, it's just flash, not rocket science.
    Flash will begin to die as soon as Firefox 4 is released and HTML5 <video> tag support is out in the wild. Nobody will need Flash to play H.264 videos any longer, and lots of other services (e.g. browser games) implement effects on top of <canvas> and JavaScript. Even Internet Exlorer 9 is there.

    If people want to work on Gallium state trackers, please focus on OpenCL. It is the correct and portable way to implement stuff like this. A Gallium state tracker specifically for Lightspark will require multiple code paths to support other environments besides Linux. Gallium3D is no standard subsystem on the majority of operating systems.

  4. #4
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,142

    Default

    The fact that everyone seems to be considering the raw Gallium3d API for acceleration goes to show how much OpenGL sucks. Think about it for a moment.

  5. #5
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by BlackStar View Post
    The fact that everyone seems to be considering the raw Gallium3d API for acceleration goes to show how much OpenGL sucks. Think about it for a moment.
    Keep trolling...

  6. #6
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,142

    Default

    Quote Originally Posted by Svartalf View Post
    Quote Originally Posted by BlackStar
    The fact that everyone seems to be considering the raw Gallium3d API for acceleration goes to show how much OpenGL sucks. Think about it for a moment.
    Keep trolling...
    You, of all people, should understand how ill-suited OpenGL is for the short of work Lightspark is doing. For instance, efficient DMAs to VRAM are essential. In OpenGL you can:

    a. set up an async transfer through a PBO (if that's available)
    b. use glTexImage2D(..., null) discarding the previous data (requires efficient garbage collection inside the driver)
    c. use glTexSubImage2D and ping-pong between two or more textures
    d. use glTexSubImage2D alone
    e. use glDrawPixels with an FBO
    f. invoke Cthulu(*)

    Each method may be faster or slower depending on the hardware and driver configuration. Testing this falls somewhere between "nightmare" and "impossible".

    Then you have to generate OpenGL shaders on the fly (ugh(**)), read back to system memory if necessary (double ugh(***)), compose, re-upload, display. And all this in OpenGL 2.1 with 1.x fallbacks for older hardware.

    [Add obligatory joke how Adobe's engineers *still* haven't managed to get this right after so many years]

    I can see the appeal of Gallium for these tasks. Can't you? Off-hand: dead-simple DMA, sane, low-level shader instructions, efficient software fallback if the hardware is not up to the task.

    (*) this is said to increase upload speeds but I haven't confirmed. Use at your own risk.
    (**) GLSL isn't really suited to this task and ARB programs are deprecated and stuck to 2004-level capabilities.
    (***) Think texture uploads, only more random. For example, Nvidia 480 achieves half the download speed of 280. Why? Noone knows, have fun optimizing your code.

  7. #7
    Join Date
    Jan 2010
    Posts
    159

    Default

    If everyone likes Gallium that much you could also expose it as a new api like OGL and let applications handle this like they want because it wouldn't be necessary to move every state tracker directly into mesa.

    I don't know if that's feasible but that would be my Idea on this point without having too much knowledge on this.
    To the experts, would it be Possible to do something like that?

  8. #8
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,142

    Default

    Quote Originally Posted by Ragas View Post
    If everyone likes Gallium that much you could also expose it as a new api like OGL and let applications handle this like they want because it wouldn't be necessary to move every state tracker directly into mesa.

    I don't know if that's feasible but that would be my Idea on this point without having too much knowledge on this.
    To the experts, would it be Possible to do something like that?
    I'm pretty sure you can build a new state tracker without modifying mesa.

  9. #9
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,142

    Default

    Quote Originally Posted by sturmflut View Post
    Flash will begin to die as soon as Firefox 4 is released and HTML5 <video> tag support is out in the wild. Nobody will need Flash to play H.264 videos any longer, and lots of other services (e.g. browser games) implement effects on top of <canvas> and JavaScript. Even Internet Exlorer 9 is there.
    Firefox doesn't support H.264 video. You'll still need flash for that.

    If people want to work on Gallium state trackers, please focus on OpenCL. It is the correct and portable way to implement stuff like this.
    So the Lightspark developers should abandond their project and go to work on OpenCL? Why would they do that?

    Or do you mean they should try to use OpenCL to accelerate Lightspark? This would be completely unproductive:
    - OpenCL requires binary drivers and a brand new GPU
    - Getting good performance out of OpenCL is very very difficult
    - You'd need separate codepaths for each GPU vendor (otherwise you can get lower performance than using just the CPU)
    - OpenCL tools suck

    A Gallium state tracker specifically for Lightspark will require multiple code paths to support other environments besides Linux. Gallium3D is no standard subsystem on the majority of operating systems.
    So what? They can always ship Gallium softpipe for those operating systems. (Provided they actually give a damn in the first place.)

  10. #10
    Join Date
    May 2010
    Posts
    6

    Default

    Quote Originally Posted by BlackStar View Post
    Firefox doesn't support H.264 video. You'll still need flash for that.
    No need for H.264.

    With the next generation Android OS and devices the WebM format will not only work on desktop computers (Firefox 4.0, Opera 10.6, Chrome 6, Internet Explorer 9) but also on mobile devices and Google TV sets.

    Anything GNU and or *nix or even browser capable will eventually support it. Dedicated decode/encode hardware is being developed as we speak.
    Quote Originally Posted by BlackStar View Post
    So the Lightspark developers should abandond their project and go to work on OpenCL? Why would they do that?
    Clean code. You don't want hundreds of state trackers.

    Using an abstract, open, multiplatform umbrella API you don't have to complicate things by building your own API.
    Even if it's more cumbersome to develop due to the lack of tools and documentation.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •