Announcement

Collapse
No announcement yet.

Intel OpenGL Performance: OS X vs. Windows vs. Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by pingufunkybeat View Post
    Because the Linux stack is based on the in-kernel DRM and Mesa, and others aren't?

    Intel is doing the Right Thing here.
    They could have probably gone Gallium3D which is cross platform and have the "same" driver on all 3 OSes (+benefit from other peoples work) but probably they have their reasons for not doing it.

    Comment


    • #17
      Originally posted by Phoronix
      When moving to the latest OpenArena release (v0.8.8) that now takes advantage of GLSL shaders, bloom, and other more modern OpenGL features, the Windows 7 and Linux performance was close at a low resolution of 1280 x 1024.
      *Casts a weary eye at Micheal*

      Comment


      • #18
        Originally posted by johnc View Post
        But why would that matter? They can use the Linux infrastructure while keeping the core driver stuff the same. Unless they insist that the Windows version be closed source -- which makes no sense since it's 100% open on the Linux side.
        1.) probably will take more time to make their winblob use linux stack than write the OSS driver from scratch
        2.) they will have to deal as nvidia/amd blob with a hell of dependencies issues and refactor a freaking bunch of LOC
        3.) intel rightfully believe is better to exploit the native graphic system instead of make frankesteins to go in the cheap
        4.) its excellent to test new techniques that can be ported from linux to windows/mac
        5.) is a great way to push linux native stack to the next level
        6.) they trully believe in the kill da blobs mantra
        7.) using the native graphic system allow them use and test and support emerging technologies like wayland in real time that later can be profitable for the mobile division[tizen/x86 mobile combo]

        "They can use the Linux infrastructure while keeping the core driver stuff the same" no. a gpu driver is a massive massive endeavor and the complexity of doing that is plainly insane[just modify the windows code that handle FB memory can affect millions of LOC just to make it compile lets not go to the grimmy scenario of optimizations] and if you take the nvidia/AMD case that after 10+ years making this transition and you still find many many issues[amd more nvidia but the latter is not problem free either]. sure but nvidia/amd gpus are better/faster/etc so the driver should be simpler, right? no, basically all the infrastructure is the same just the device specifics ASM are different[1-5% of the code maybe] and couple of other very small subsystems, regardless the GPU the infrastructure is equally massive

        and like i said a zillion times already linux native drivers and gallium promise a very bright future[gallium design is quite a killer actually] but the problem is not linux is lack of developers. so linux have like 10 guys rewriting an entire graphic stack and making the drivers at the same time[before any dumb question no you have circular dependencies between an stack and the drivers so you can write one before the other], if we had like 100 developers probably linux would murder anything else in FPS and we will be loling khronos cuz we have opengl5 working before the draft but sadly this work is too complex and require a hell of expertise in electronics and that kind of developer just don't grow in trees

        Comment


        • #19
          The amount of work done by Intel to advance the Linux graphics stack is very commendable! These tests show; however, there is yet more performance work to be done. I really hope the Intel Linux Graphics team is able to catch up to, and even surpass the Windows team in performance and features.

          Being that the HD3000/4000 IGP is not the fastest GPU to begin with, in this case, every frame does count. Especially if we will be running some AAA titles (ie. from Valve). Here's hoping we start seeing performance (and feature) payout in coming releases due to the collaboration with Valve!

          Thanks Michael for these very useful Linux vs Windows comparisons. It lets us know that much more work needs to be done.

          Comment


          • #20
            Originally posted by pingufunkybeat View Post
            I don't know if opening up their Windows driver and completely bypassing Mesa and parts of the kernel and X.org would be a better way to go, especially considering that Intel has been one of the primary drivers behind all recent developments: GLSL compiler, DRI2/GEM/KMS. AMD didn't go that way either.
            Look at this the way I do:

            The driver is processing some data passed in by some game. That data should be the same regardless of the host platform. As such, the processing within the driver should be identical across all platforms. The ONLY parts of the driver that should be different across OS's are any calls that use OS API's, which ideally would be replaced in a 1:1 manner.

            ...then you get into things OS A supports that OS B doesn't, and you start to see a lot of kludges in the code base to make things work. OS A supports created a thread in a suspended state; OS B doesn't. And so on and so forth.

            For example: My driver needs to create a thread in a suspended state. On Windows, simply invoke CreateThread() with the CREATE_SUSPENDED flag. Done.

            On Linux, pthread_create() is the obvious choice...except there's no way to suspend the thread on thread creation. So now you need to kludge the code to approximate the same behavior, often at a performance loss. And of course, its non-standard behavior between different devs, which can (and will) lead to issues when drivers start talking to eachother...[Seriously, POSIX needs to add a parameter to pthread_create() to allow for a suspended startup. Causes too many headaches, espeically in languages like Ada that separate thread creation from thread start.]

            Now, when you run into problems like that a couple hundred times while writing the driver...you get the idea. The driver can be no better then the interface to the OS.

            Comment


            • #21
              Originally posted by 89c51 View Post
              They could have probably gone Gallium3D which is cross platform and have the "same" driver on all 3 OSes (+benefit from other peoples work) but probably they have their reasons for not doing it.
              DX on Windows may have something to do with it

              Also, the Windows team is much bigger but also produces a worse driver. If that team were to start coding for the lin driver too, I'm very afraid the lin driver quality would take a nosedive to the win driver levels.

              Comment


              • #22
                STOP DOING TEST JUST IN MAC AND DO IT IN PC AND MAC IF YOU WANT OSX VS WINDOWS VS LINUX.

                and please stop telling me that its the same hardware because i know it same hardware BUT this is not true benchmarks

                and why dont you create a benchmarks between windows and linux in PC and install nvidia or ati official drivers (NOT MESA) ??
                Last edited by nir2142; 08-29-2012, 01:10 PM.

                Comment


                • #23
                  Originally posted by nir2142 View Post
                  and why dont you create a benchmarks between windows and linux in PC and install nvidia or ati official drivers (NOT MESA) ??
                  Because he already has - not recently, but he has in the past.

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    DX on Windows may have something to do with it
                    Almost 2 years ago...
                    http://cgit.freedesktop.org/mesa/mes...09c1b8903d438b

                    Comment


                    • #25
                      Originally posted by gamerk2 View Post
                      Look at this the way I do:

                      The driver is processing some data passed in by some game. That data should be the same regardless of the host platform. As such, the processing within the driver should be identical across all platforms. The ONLY parts of the driver that should be different across OS's are any calls that use OS API's, which ideally would be replaced in a 1:1 manner.

                      ...then you get into things OS A supports that OS B doesn't, and you start to see a lot of kludges in the code base to make things work. OS A supports created a thread in a suspended state; OS B doesn't. And so on and so forth.

                      For example: My driver needs to create a thread in a suspended state. On Windows, simply invoke CreateThread() with the CREATE_SUSPENDED flag. Done.

                      On Linux, pthread_create() is the obvious choice...except there's no way to suspend the thread on thread creation. So now you need to kludge the code to approximate the same behavior, often at a performance loss. And of course, its non-standard behavior between different devs, which can (and will) lead to issues when drivers start talking to eachother...[Seriously, POSIX needs to add a parameter to pthread_create() to allow for a suspended startup. Causes too many headaches, espeically in languages like Ada that separate thread creation from thread start.]

                      Now, when you run into problems like that a couple hundred times while writing the driver...you get the idea. The driver can be no better then the interface to the OS.
                      1.) no, in the case of DX is quite different[most drivers] and in the opengl cases you have many variants with specific custom extension [AGL,WGL,GLX among others] and in the case of WGL depending the driver its emulated over DX. so it takes some analisys depending from and destination of the port[this should not happen but it is like that for many reason]

                      2.) no, data[api calls but whatever] from a game is not os independant at all[maybe textures] nor is tool independant nor is OS graphic stack independant because you somehow assume opengl is a language or some sort of proto IR language but in the real world is a library that is amazingly flexible and is used in conjuctions many languages[mostly C++/ASM(x86/arm)] and the driver need to be very smart to know what it can do and can't do[or emulate] in each OS. even if is true every OS can manage the hardware they do it extremely different[1:1 translate yeah in movies <-- id4 comes to my mind] sometimes it helps sometimes that force you to rethink a million lines of code.

                      Additionally you assume somehow every gl api call is a direct ASM gpu function, no opengl is hardware agnostic[which make it more complex tho] so you can use CPU/GPU/preprocessors/clusters/etc and many of those are not possible on windows while on linux are perfectly standard[no in OSS drivers for now tho] you also wrongly assume that every OS api call do the same is called the same and perform the same which neither is true[is like saying an F35 and helicopter should be the same cuz both fly] [there are many good sites that explain this very deeply and easy to understand google it] and even an algorithm that is efficient in windows can be terribly slow on linux/mac compared to a modified algorithm using the techs in that native OS[many many examples of this | google is your friend] and this mostly drive you to rewrite half of your glsl interpreter to try to find a mid point between OSes.

                      and just to name few more factors that make this ridiculous that would force you to rethink most of that code to meet an performance expectation filesystem, cpu scheduler, vectorization, I/O subsystem, latency, memory handling, interrupt handling/OS flexibility[windows pretty much allow any dirty hack you can think of where linux abort compilation or sigsegv your ass out] and many more

                      3.) please explain to me this suspend thread thing[why you think is so important] cuz you have like 6 posts getting IANAL about it and after 10 years of developing threaded apps[c++] for linux i never have found a technical reason to suspend threads in efficient code[i always design my apps to be thread safe/small portion/atomics type/etc] and in my windows time i don't remember using them either, so i would like some example or something to get your point here

                      Comment


                      • #26
                        Originally posted by nir2142 View Post
                        STOP DOING TEST JUST IN MAC AND DO IT IN PC AND MAC IF YOU WANT OSX VS WINDOWS VS LINUX.

                        and please stop telling me that its the same hardware because i know it same hardware BUT this is not true benchmarks

                        and why dont you create a benchmarks between windows and linux in PC and install nvidia or ati official drivers (NOT MESA) ??
                        because is an intel i5 OSS driver vs other OS intel drivers benchmarks??? too much weed??

                        Comment


                        • #27
                          1. Intel HD 4000 is fast. 16cores*4shaders64bit or 8shaders32bit*FMAC*1.25ghz = 170gflops64bit(nvidia comparison) or 340gflops32bit(AMD comparison) or 500macGflops(AMD 6000 and less without FMAC).

                          2. On Linux is a little slower. Not because of Linux but because of OpenGL version support that is newer on Windows.

                          3. On Windows its only a little newer: yes can do OpenGL 3.1 and 4.0, but not 3.2, 3.3, 4.1, 4.2, 4.3. And its not a year away, Intel works faster now.

                          4. Prefer free software. That way all of them will submit to as.

                          Comment


                          • #28
                            Originally posted by jrch2k8 View Post
                            1.) no, in the case of DX is quite different[most drivers] and in the opengl cases you have many variants with specific custom extension [AGL,WGL,GLX among others] and in the case of WGL depending the driver its emulated over DX. so it takes some analisys depending from and destination of the port[this should not happen but it is like that for many reason]

                            2.) no, data[api calls but whatever] from a game is not os independant at all[maybe textures] nor is tool independant nor is OS graphic stack independant because you somehow assume opengl is a language or some sort of proto IR language but in the real world is a library that is amazingly flexible and is used in conjuctions many languages[mostly C++/ASM(x86/arm)] and the driver need to be very smart to know what it can do and can't do[or emulate] in each OS. even if is true every OS can manage the hardware they do it extremely different[1:1 translate yeah in movies <-- id4 comes to my mind] sometimes it helps sometimes that force you to rethink a million lines of code.

                            Additionally you assume somehow every gl api call is a direct ASM gpu function, no opengl is hardware agnostic[which make it more complex tho] so you can use CPU/GPU/preprocessors/clusters/etc and many of those are not possible on windows while on linux are perfectly standard[no in OSS drivers for now tho] you also wrongly assume that every OS api call do the same is called the same and perform the same which neither is true[is like saying an F35 and helicopter should be the same cuz both fly] [there are many good sites that explain this very deeply and easy to understand google it] and even an algorithm that is efficient in windows can be terribly slow on linux/mac compared to a modified algorithm using the techs in that native OS[many many examples of this | google is your friend] and this mostly drive you to rewrite half of your glsl interpreter to try to find a mid point between OSes.

                            and just to name few more factors that make this ridiculous that would force you to rethink most of that code to meet an performance expectation filesystem, cpu scheduler, vectorization, I/O subsystem, latency, memory handling, interrupt handling/OS flexibility[windows pretty much allow any dirty hack you can think of where linux abort compilation or sigsegv your ass out] and many more

                            3.) please explain to me this suspend thread thing[why you think is so important] cuz you have like 6 posts getting IANAL about it and after 10 years of developing threaded apps[c++] for linux i never have found a technical reason to suspend threads in efficient code[i always design my apps to be thread safe/small portion/atomics type/etc] and in my windows time i don't remember using them either, so i would like some example or something to get your point here

                            I agree to the most.

                            Comment


                            • #29
                              Originally posted by artivision View Post
                              1. Intel HD 4000 is fast. 16cores*4shaders64bit or 8shaders32bit*FMAC*1.25ghz = 170gflops64bit(nvidia comparison) or 340gflops32bit(AMD comparison) or 500macGflops(AMD 6000 and less without FMAC).

                              2. On Linux is a little slower. Not because of Linux but because of OpenGL version support that is newer on Windows.

                              3. On Windows its only a little newer: yes can do OpenGL 3.1 and 4.0, but not 3.2, 3.3, 4.1, 4.2, 4.3. And its not a year away, Intel works faster now.

                              4. Prefer free software. That way all of them will submit to as.
                              So higher opengl version = higher performance? I see...

                              Comment


                              • #30
                                Originally posted by nir2142 View Post
                                STOP DOING TEST JUST IN MAC AND DO IT IN PC AND MAC IF YOU WANT OSX VS WINDOWS VS LINUX.

                                and please stop telling me that its the same hardware because i know it same hardware BUT this is not true benchmarks

                                and why dont you create a benchmarks between windows and linux in PC and install nvidia or ati official drivers (NOT MESA) ??
                                My hope is that Michael is doing it to annoy you, so that you move to another forum. I hear that the anandtech forums are full of like-minded individuals. You could go there. Let me help you. Here's a link. See you around.

                                F

                                Comment

                                Working...
                                X