Page 4 of 4 FirstFirst ... 234
Results 31 to 40 of 40

Thread: TitaniumGL: A Faster Multi-Platform Graphics Driver Architecture?

  1. #31
    Join Date
    Nov 2007
    Posts
    209

    Default

    Quote Originally Posted by siride View Post
    Who's gonna hire him?
    um.. hire him for galium/mesa/llvmpipe/x11 devs?

  2. #32
    Join Date
    Feb 2012
    Posts
    111

    Default

    Quote Originally Posted by Geri View Post
    vertexSymphony: well, actually, writing a programmable pipeline is mutch easyer.
    When I referred to complexity I was talking about computational complexity ... having fixed functions with only a couple of parameters tunables is way more easier to optimize and to make shorcuts than having more stages in the pipeline, and those not being "fixed", but programmable (specially 3.x, that's designed around shaders)
    Of course is going to be fast with OpenGL 1.x, when he implements 2.x or better yet, 3.x then I'll get amazed if he gets a similar performance to this or llvmpipe.
    but yes, this does have a niche use case, but there's too much hype for what this actually is.

    Regards.

  3. #33
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by vertexSymphony View Post
    When I referred to complexity I was talking about computational complexity ... having fixed functions with only a couple of parameters tunables is way more easier to optimize and to make shorcuts than having more stages in the pipeline, and those not being "fixed", but programmable (specially 3.x, that's designed around shaders)
    Of course is going to be fast with OpenGL 1.x, when he implements 2.x or better yet, 3.x then I'll get amazed if he gets a similar performance to this or llvmpipe.
    but yes, this does have a niche use case, but there's too much hype for what this actually is.

    Regards.
    I agree with you. This is especially true because compositing window managers these days have a hard dependency on OpenGL 2.x, with GL 1.4 fallback paths quickly disappearing due to maintenance and performance issues. Some people, e.g. the kwin maintainer, even wants to require GL 3.x support, though I imagine that's still a little ways off from being implemented (in the sense that the GL 1.x AND 2.x renderers will be removed).

    The other aspect that reduces the utility of any potential optimizations you'd see in TitaniumGL is that these optimizations won't work for any hardware accelerated 3d paths on modern cards. Modern cards are all fully programmable and likely do not even have fixed function code paths, so the optimization techniques are completely different in order to achieve respectable GL 2.x performance on, say, Nvidia Fermi (GTX400 series) or ATI Evergreen (HD5000) or later. And since GL 3.x / 4.x is much newer, it's pretty much a trade secret within the halls of ATI and Nvidia as to how to make these new APIs fast.

    What I'm saying is that, in the best case, TitaniumGL would be open sourced and we could draw some useful algorithms from it, for doing GL 1.4 on the CPU. Since these algorithms likely wouldn't be compatible with LLVM, they would only be able to affect the performance of the softpipe driver. And we'd have to somehow re-architect softpipe to use these faster algorithms for GL 1.4, while switching over to the slow old way for GL 2.x, because it's programmable, and TitaniumGL offers no advice on how to optimize a programmable pipeline.

    This best case is not reality, though, because it's closed source and likely doesn't offer any truly novel algorithms.
    Last edited by allquixotic; 03-11-2012 at 05:41 PM.

  4. #34
    Join Date
    Oct 2008
    Posts
    3,027

    Default

    Quote Originally Posted by allquixotic View Post
    Some people, e.g. the kwin maintainer, even wants to require GL 3.x support, though I imagine that's still a little ways off from being implemented (in the sense that the GL 1.x AND 2.x renderers will be removed)
    I don't think that's accurate. Have a link?

    What I understood, was that he wants the code kwin uses to run in the core profile without having to use any of the functionality that was deprecated in 3.x. So that it's simple to use the same code in GL2, GL3, and GL ES contexts. I don't think I ever heard of a plan to get rid of GL2 support, though.

  5. #35
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote Originally Posted by smitty3268 View Post
    I don't think that's accurate. Have a link?

    What I understood, was that he wants the code kwin uses to run in the core profile without having to use any of the functionality that was deprecated in 3.x. So that it's simple to use the same code in GL2, GL3, and GL ES contexts. I don't think I ever heard of a plan to get rid of GL2 support, though.
    By the time kwin supports OpenGL 3, the majority of free and open source video card drivers will support it too.

    It still has OpenGL 1.5 support for crying out loud, and he's only NOW talking about killing that off. OpenGL 1 is ancient and it's pretty hard to justify continuing to support it when almost nobody has hardware that old and its only other job is to be there to work around AMD's utterly craptastic proprietary driver.

    I'm not sure the proprietary "TitaniumGL" malware (it opens sites full of ads every time something invokes it) which isn't even properly compliant with OpenGL 1 is even worth paying any consideration to.

  6. #36
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    Well maybe take a look at the OpenGL version string of a standard Intel netbook...

  7. #37
    Join Date
    Oct 2008
    Posts
    3,027

    Default

    Quote Originally Posted by Kano View Post
    Well maybe take a look at the OpenGL version string of a standard Intel netbook...
    Even those have some (limited) support for GLSL shaders through an extension which should be sufficient for kwin's purposes.

  8. #38
    Join Date
    Oct 2010
    Posts
    305

    Default

    Quote Originally Posted by Kano View Post
    Well maybe take a look at the OpenGL version string of a standard Intel netbook...
    I tried activating kwin compositing on my Eeepc 901 before it broke down completely, turned the entire desktop into a slide show. Unless the "standard" improved significantly over the Eeepc 901, Intel notebooks just can't handle compositing.

  9. #39
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by Ansla View Post
    I tried activating kwin compositing on my Eeepc 901 before it broke down completely, turned the entire desktop into a slide show. Unless the "standard" improved significantly over the Eeepc 901, Intel notebooks just can't handle compositing.
    The Eeepc 901 is not a "notebook"; it's a netbook. Although it uses a similar Intel-manufactured GPU (not Imagination Technologies) to the ~2006 era laptops, it is slower for these reasons:

    1. The memory in the netbook is slower/cheaper than laptop memory. It's DDR2, where you can expect DDR3 on a real laptop.

    2. The Atom processor could be a bottleneck, since the CPU is heavily involved in graphics processing for such a small device. Atom processors are pathetic -- they don't hold a candle to something as "revolutionary" as a first-gen Core 2 from ~2007.

    3. The mobo used is going to have a slower FSB and less bandwidth for transferring data between the GPU and the CPU and RAM.

    I have a ThinkPad X61 which uses an Intel integrated GPU which is one generation newer than yours -- instead of 945, it's 965. By today's standards, it's still quite old. The CPU is a low-power Core 2 Duo. Even with these fairly pedestrian specs, I get extremely smooth performance with any compositor I can throw at it on Windows or Linux: Aero, Mutter, Cinnamon, Kwin, whatever. To put it simply, this is a 3 or 4 year old integrated graphics chip that's now 2 micro-architecture generations behind (it'll be 3 generations behind when Ivy Bridge hits later this year) and compositing is simply perfect.

    Granted, any more advanced 3D on this hardware is going to get badly bogged down. But hardware-accelerated compositing for workloads like web browsing and office applications, works GREAT.

    So saying "Intel's hardware makes compositing a slideshow" is a gross understatement. I can only imagine how fast it is with Sandy Bridge graphics, which you can buy today; or Ivy Bridge graphics, which you'll be able to buy later this year.

  10. #40
    Join Date
    Oct 2010
    Posts
    305

    Default

    Quote Originally Posted by allquixotic View Post
    The Eeepc 901 is not a "notebook"; it's a netbook.
    It was a typo, both Kano and I were actually talking about netbooks, not notebooks.

Posting Permissions

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