Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Benchmarking The Intel Ivy Bridge Gallium3D Driver

  1. #1
    Join Date
    Jan 2007
    Posts
    15,697

    Default Benchmarking The Intel Ivy Bridge Gallium3D Driver

    Phoronix: Benchmarking The Intel Ivy Bridge Gallium3D Driver

    While Intel only supports their classic Mesa DRI driver when it comes to their open-source 3D driver on Linux, developed independently is also a Gallium3D driver for Sandy Bridge and Ivy Bridge generations of Intel graphics processors. In this article are benchmarks of the new Intel (i965) Gallium3D driver with Ivy Bridge HD 4000 hardware.

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

  2. #2
    Join Date
    Dec 2009
    Location
    Italy
    Posts
    176

    Default

    These results are impressive. They managed to achieve 30 to 70% speed with 1/10th or less of the manpower and only a few months of development... I wonder what this could become with 20+ full time developers working on it.

  3. #3
    Join Date
    Jul 2010
    Posts
    545

    Default

    The question is whether this perf difference is really due to gallium or the driver backend pieces? And if it is gallium, this project can be a great opportunity to identify and fix those slow paths. I know, not so exciting for Intel, as they've got nothing to gain here.

  4. #4
    Join Date
    Jan 2013
    Posts
    1,096

    Default

    Quote Originally Posted by log0 View Post
    The question is whether this perf difference is really due to gallium or the driver backend pieces? And if it is gallium, this project can be a great opportunity to identify and fix those slow paths. I know, not so exciting for Intel, as they've got nothing to gain here.
    This.
    The perfomance difference looks nearly same as radeon vs catalyst; nouveau vs nvidia. The same 50%.
    I really wonder if radeon and nouveau are actually slower due to gallium?!

  5. #5
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    884

    Default

    Quote Originally Posted by brosis View Post
    This.
    The perfomance difference looks nearly same as radeon vs catalyst; nouveau vs nvidia. The same 50%.
    I really wonder if radeon and nouveau are actually slower due to gallium?!
    Doubtful. I believe Nouveau is usually slower mostly due to re-clocking issues, and when it comes to R300-R500, the Gallium driver can beat the final catalyst driver that was released for those cards.

    There may be a CPU-usage issue for faster cards, but there's ongoing optimization work to also improve the Gallium layer to reduce unnecessary/redundant work.

  6. #6
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    138

    Default

    Quote Originally Posted by log0 View Post
    The question is whether this perf difference is really due to gallium or the driver backend pieces? And if it is gallium, this project can be a great opportunity to identify and fix those slow paths. I know, not so exciting for Intel, as they've got nothing to gain here.
    If I had to hazard a guess, I'd say it's because of the shader compiler backend. Note that it's TGSI-based and named "toy compiler":
    https://github.com/olvaffe/mesa/tree...rs/i965/shader

    Now that Gallium supports both TGSI and LLVM IR (i.e. more than one kind), it probably wouldn't be too hard to add support for GLSL IR and drop in the classic driver's compiler backend. Less than a week, I'd imagine.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,340

    Default

    OA 0.8.5 uses fixed function rendering. Surely the shader compiler has little effect there?

  8. #8
    Join Date
    Jul 2010
    Posts
    545

    Default

    Quote Originally Posted by curaga View Post
    OA 0.8.5 uses fixed function rendering. Surely the shader compiler has little effect there?
    On that hardware the fixed function path will be implemented using shaders. The question is whether this shaders are compiled at runtime or are available in some intermediate/assembly form, bypassing the compiler.

  9. #9
    Join Date
    Oct 2008
    Posts
    3,251

    Default

    Quote Originally Posted by Kayden View Post
    If I had to hazard a guess, I'd say it's because of the shader compiler backend. Note that it's TGSI-based and named "toy compiler":
    https://github.com/olvaffe/mesa/tree...rs/i965/shader

    Now that Gallium supports both TGSI and LLVM IR (i.e. more than one kind), it probably wouldn't be too hard to add support for GLSL IR and drop in the classic driver's compiler backend. Less than a week, I'd imagine.
    Yep, I'm pretty sure that's it, and plumbing GLSL IR though Gallium would allow it to reuse the existing shader compiler backend that Intel has spent so much time optimizing.

    However, i don't think Gallium support would be that easy. Right now i don't think it supports LLVM IR directly, it just allows translating TGSI into that before it goes to the driver. I don't think you'd want to go from GLSL IR -> TGSI -> GLSL IR inside gallium, which means you'd have to add the ability to remove TGSI from the pipeline altogether, and i think that's still quite a bit of work to be done before that can happen. Maybe not, though.

    Quote Originally Posted by curaga
    OA 0.8.5 uses fixed function rendering. Surely the shader compiler has little effect there?
    Gallium tries to translate everything into shaders. The fixed function calls get translated into TGSI, and then the driver is responsible for calling into the hardware correctly, which is generally going to be by creating shaders.

    Quote Originally Posted by kbios
    These results are impressive. They managed to achieve 30 to 70% speed with 1/10th or less of the manpower and only a few months of development... I wonder what this could become with 20+ full time developers working on it.
    This does build on top of quite a bit of work already done by the Intel devs. For example, it shares all the same kernel driver code, and i imagine quite a bit of the hardware driver code was just copied out of the i965 driver.
    Last edited by smitty3268; 04-16-2013 at 03:39 PM.

  10. #10

    Default I told you so!

    Quote Originally Posted by log0 View Post
    The question is whether this perf difference is really due to gallium or the driver backend pieces? And if it is gallium, this project can be a great opportunity to identify and fix those slow paths. I know, not so exciting for Intel, as they've got nothing to gain here.
    Intel has some "egg on their face" and "foot in their mouth" to gain here:
    1. if someone can finally prove that Gallium architecture is performant.
    2. leveraging gallium allowed 1/2 guys to do what took 20 Intel engineers.

    And users have much less chance of being denied features
    simply because Intel chooses not to implement them.

    Ah, the sweet satisfaction that comes from those simple words: "I told you so!".
    It almost makes it worth the wait!

Posting Permissions

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