Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: The New Linux OpenGL ABI Is Nearing Reality

  1. #11

    Default Its all ridiculous

    Quote Originally Posted by mark45 View Post
    Which is what I'm saying, without crappy workarounds and knowing where stuff is located (since it's not standardized) is a pita and doesn't work at all if you haven't invested a lot of time in figuring a working workaround out. It's like X11 which basically works but is crappy as hell and anyone wants to get rid of it except a few folks that are conservative (read "with down syndrome") who like it.
    I really can't come up with a legitimate reason something like this:
    https://github.com/mirrors/linux/blo...o/skeletonfb.c
    cannot just be extended to say: .../drivers/video/skeletonGL.c[/url]
    so that vendors could just write one good set of drivers and userspace would have a single, solid, simple API to deal with
    you get /dev/GL[0-9] and things just work like they do with /dev/fb[0-9]

  2. #12
    Join Date
    Aug 2011
    Posts
    542

    Default

    I guess this is not related to the GL GLX separation, right?

  3. #13

    Default

    It could turn Xorg to a relic, with xfbdev being all that is required for X and GLX. The framebuffer already provides device specific functions for things like copyarea, blit, etc... If a device specific version is not provided there is a generic implementation. Now if you extend the framebuffer with GL extensions, the same could be accomplished for GL functions using Fabrice Bellard's TinyGL as the generic implementation fallbacks.

    This can significantly reduce desktop startup time compared to Xorg (my Intel cards takes 4-10 seconds to initialize with Xorg vs ~0.2s with xfbdev) One other simple thing that is missing from the kernel is automatic resolution and bpp for fb devices (its only ~10-20 LOC to implement)

    For these kinds of things, it is imperitive to ask why these things were separated in the first place and reevaluate base on current conditions.

  4. #14

    Default

    Quote Originally Posted by blackout23 View Post
    Does that mean, that SteamOS can just preinstall NVIDIA, Catalyst and intel-dri and some clever code will just detect the hardware and work out-of-the-box with the proper drivers?
    You don't remember the Kororaa Compiz LiveCD? They loaded the proprietary drivers at boot time for whatever hardware you had.

    The project was axed though after much speculation of GPL and/or driver license violation only to return without the proprietary blobs pre-installed.

  5. #15
    Join Date
    Jan 2009
    Posts
    1,438

    Default

    Quote Originally Posted by mark45 View Post
    Afaik today only one GL implementation can be used at a time, the one which last created the /usr/lib/libGL.so, if you wanna use another implementation you have to run some filesystem utility to remove/overwrite the current GL implementation at /usr/lib/libGL.so (say the nouveau one) with another driver (say Nvidia's proprietary one).

    The new ABI allows many drivers to coexist in peace and the runtime is agnostic of which drivers exist in the OS and chooses which driver to use without any hacks whatsover, e.g. you can have in the same application window a GL context running on nouveau and the other one running on Nvidia's proprietary driver. Not that you need this, it just shows that the infight between GL drivers should be over, plus some provisions for future non-GL based solutions.

    But since it's not final yet, we don't know exactly what it will be.
    Plan9 should be able to run both with its namespacing. I'm not sure if Linux's implementation is as thorough.

  6. #16
    Join Date
    Aug 2011
    Posts
    542

    Default

    Quote Originally Posted by Thodmas View Post
    different libraries and hoping that nothing collides.


    These spambots are getting more intelligent by the day... scary.

Posting Permissions

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