Announcement

Collapse
No announcement yet.

Khronos Releases OpenGL 3.3 & OpenGL 4.0

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

  • #31
    Originally posted by BlackStar View Post
    Intel's OSS drivers are OpenGL 2.1 with GLSL 1.2 - when they work. That's, ugh let's see, around 7 years behind the curve? Remember, OpenGL 4.0 with GLSL 4.0 were just released.
    Yeah, but let's remember that they still have a limiting factor to all of that - Mesa. Not to bash Mesa(or the kernel, or tungsten) here, but it took years to get even a reasonable implementation of memory management, which is a prerequisite of OpenGl>1.x, and even that needed the Intel guys to do it themselves.

    The next thing I was slightly confused of - does their hardware even have support for OpenGL 3.0(do they have the parts necessary)? Because Wikipedia is saying no, which would any work on OpenGL done by Intel-guys slightly useless, and would make this not exactly their fault.
    Originally posted by BlackStar View Post
    Even if Intel's OSS are great, this doesn't get them of the hook for their atrocious closed-source driver. Remember that Intel's OSS marketshare is tiny compared to their closed-source install base (which is larger than either Nvidia or Ati). It is this huge marketshare that makes it impossible to deliver a modern 3d application (game, UI, whatever) without a D3D code-path.
    I don't want to start a discussion about the need and don't needs of users here, but as far as I'm concerned if you want fast(read: plays games that are not over 5 years old) gaming/3D Intel isn't what you want. I mean why should they invest anything in OpenGL-performance? 90% of their userbase probably wants Win7/OSX/Linux compositing working okay and that's it.

    Comment


    • #32
      Originally posted by fabiank22 View Post
      Yeah, but let's remember that they still have a limiting factor to all of that - Mesa. Not to bash Mesa(or the kernel, or tungsten) here, but it took years to get even a reasonable implementation of memory management, which is a prerequisite of OpenGl>1.x, and even that needed the Intel guys to do it themselves.
      Their closed-source drivers were still at GLSL 1.1 last time I checked, and those aren't constrained by Mesa. It's a matter of policy, not lack of manpower, funds or hardware capabilities (see below).

      The next thing I was slightly confused of - does their hardware even have support for OpenGL 3.0(do they have the parts necessary)? Because Wikipedia is saying no, which would any work on OpenGL done by Intel-guys slightly useless, and would make this not exactly their fault.
      All DX10-capable hardware is able to support OpenGL 3.x. Intel ships DX10 drivers, so...

      I don't want to start a discussion about the need and don't needs of users here, but as far as I'm concerned if you want fast(read: plays games that are not over 5 years old) gaming/3D Intel isn't what you want. I mean why should they invest anything in OpenGL-performance? 90% of their userbase probably wants Win7/OSX/Linux compositing working okay and that's it.
      As a developer, all I want is a sane, stable driver implementation, that supports a minimal set of functionality (at least GL 2.1 + GLSL 1.2 + FBO + NPOT textures, but higher versions can make a developer's life much easier). I don't care about raw performance all that much: tuning visuals for performance is an order of magnitude easier than working around driver bugs for NxM driver combinations (where N is the number of video cards and M is the number of drivers for each card.)

      The current driver situation means that you cannot ship a modern, cross-platform 3d application without writing a Direct3D code-path. The reason is that Intel's drivers (a) are very buggy and (b) they do not expose the hardware's actual capabilities. For example, the all too common 915 chips don't expose FBOs on OpenGL (but do on Direct3D) - why?(*)

      You don't have to take my word on it - just take a look at the OpenGL 3.3/4.0 discussion over at opengl.org to see what developers think about Intel and how it hurts the OpenGL ecosystem.

      (*) to translate this in concrete terms, Intel holds around 50% of the GPU market. If you try to use modern OpenGL features, you can be certain that at least half your users won't be able to use your program (not talking specifically about games!) If you use Direct3D 9, you'll be able to reach out to the complete Windows ecosystem (maybe 80-85%). This difference is so great, that almost no major game or 3d application has relied on OpenGL exclusively for *years* (the only major OpenGL-only app I am aware of is Blender3d. And guess what? I've only seen a single Intel IGP capable of running it - HD4500 on Win7. Older IGPs tend to fail horribly.)

      Comment


      • #33
        Originally posted by BlackStar View Post
        Finally, if there's anyone who is fucking up with OpenCL support, it is (surprise) Intel, who is refusing to implement the spec and distribute a runtime to its users. This means that at least 60% of all OpenCL-capable PCs will never see OpenCL support.
        That is incorrect. ATI Stream SDK supports all "X86 CPU w/ SSE 3.x or later" and I tried it. It works also nice on Intel CPUs.

        Btw. I like AMD's compile log for OpenCL way more than Nvidia's, less uneccessary stuff.

        Comment


        • #34
          Originally posted by mat69 View Post
          That is incorrect. ATI Stream SDK supports all "X86 CPU w/ SSE 3.x or later" and I tried it. It works also nice on Intel CPUs.

          Btw. I like AMD's compile log for OpenCL way more than Nvidia's, less uneccessary stuff.
          I know, I use it myself. However, how many end-users will download and install Ati's 120MB SDK (there's no redist yet) on their Intel system? How are you supposed to market an application that requires this?

          Personally, I don't care whether Intel writes their own implementation or they license Ati's one or whatever. I just need something users can install and use without too much hassle. Right now, this only works on Mac OS X (which comes with the runtime pre-installed) and Nvidia's newest closed-source drivers (which also come with a runtime). Ati can be expected to do the same in the near future - guess who's the odd one out (again)?

          Comment


          • #35
            Maybe AMD will offer a small driver and installing that is not too much to ask customers for. Just look at most PC games, they usually also ship DirectX if the needed version is not installed on the system.

            I guess this won't really be a problem in the future [1], the users who want fast caluclations will install the needed drivers and the others will have to live with compatibility code that won't use all the capabilities of their hardware.

            [1] OpenCL is still very new and drivers not that mature imo.

            Comment


            • #36
              Originally posted by BlackStar View Post
              Right now, this only works on Mac OS X (which comes with the runtime pre-installed) and Nvidia's newest closed-source drivers (which also come with a runtime). Ati can be expected to do the same in the near future - guess who's the odd one out (again)?
              S3 also has openCL 1.0 support in their drivers as well.

              Comment


              • #37
                Originally posted by mat69 View Post
                [1] OpenCL is still very new and drivers not that mature imo.
                How do you draw your conclusion that openCL support isn't mature in drivers already? That maybe the case on ATI cards but others have had it available for a while.

                Comment


                • #38
                  Originally posted by deanjo View Post
                  S3 also has openCL 1.0 support in their drivers as well.
                  Had no idea, this is very good!

                  Personally, I've found Nvidia's OpenCL implementation to be somewhat more immature than Ati's. There's stuff, like async readbacks, that just plainly doesn't work on Nvidia right now. Add the general lack of good tools and it's true that OpenCL is still somewhat immature. The situation is slowly getting better, however (it's already much better compared to 3 months ago).

                  Comment


                  • #39
                    Originally posted by deanjo View Post
                    How do you draw your conclusion that openCL support isn't mature in drivers already? That maybe the case on ATI cards but others have had it available for a while.
                    By using them.

                    And just because Nvidia has released OpenCL support earlier does not neccessarily mean that their drivers are more mature. It's about quality, not who is first.

                    What you also should not forget is the time it needs to optimize drivers, it just takes a while to get great speed out of drivers. That is also what some AMD devs admitted [1] -- that there are many areas of improvements.

                    [1] Do not take that negatively, that is natural -- for every "driver"-maker -- at this early stage of OpenCL support.

                    Comment


                    • #40
                      Originally posted by mat69 View Post
                      By using them.

                      And just because Nvidia has released OpenCL support earlier does not neccessarily mean that their drivers are more mature. It's about quality, not who is first.

                      What you also should not forget is the time it needs to optimize drivers, it just takes a while to get great speed out of drivers. That is also what some AMD devs admitted [1] -- that there are many areas of improvements.

                      [1] Do not take that negatively, that is natural -- for every "driver"-maker -- at this early stage of OpenCL support.

                      Can you please be specific about what openCL bug you have found? I've been using them for quite some time and have yet to come across an issue with them in openCL development.

                      Comment


                      • #41
                        Originally posted by deanjo View Post
                        Can you please be specific about what openCL bug you have found? I've been using them for quite some time and have yet to come across an issue with them in openCL development.
                        "Real" bugs I have found is memleaking of the AMD driver, did not try that with the NVida though.

                        Problems I have found are different handling of implicit conversions of AMD and Nvidia. AMD converts implicitly (allowed in the spec) e.g. cos(2) works, while Nvidia does not do that, here you have to convert that yourself.

                        Further AMD converts vectors explicitly e.g.
                        uint 4 u; ...
                        float4 f; ...
                        (float4)(u);
                        I guess this is wanted behaviour though I would consider it a bug since it is (specifically) forbidden in the spec.

                        Just these two examples result in code that will work with AMD devices or Intel CPUs yet not on Nvidia GPUs and that is bad.

                        In fact if one knows that Nvidia does no implicit converting and that AMD ignores the spec at that example above one can easily not use these features. Though still that leaves a bad taste in the mouth and makes me wonder what else of the spec is not suppoted by whichever implementation or what is ignored.

                        Comment


                        • #42
                          We have been having problems getting async readbacks to work on Nvidia, too. They seem to work fine on AMD's implementation, but Nvidia blocks as if it was a blocking (synced) readback.

                          Not good.

                          Comment


                          • #43
                            Another minor thing is that at least here Nvidia does often not return correct error codes as defined in the header file.

                            Comment


                            • #44
                              Why am I getting a vibe that Nvidia is trying to shoehorn their OpenCL implementation on top of CUDA, similar to what they did with GLSL on top of Cg? Their GLSL compiler used to be god-awful and has caused lots of pain to developers and especially users. It used to accept D3D/HLSL code without an error or warning for god's sake!

                              "(user) Hey, your game doesn't work on my Ati card."
                              "(dimwitted dev) I don't test on Ati cards, Ati sucks. They don't support GLSL."
                              "(user) Well, games X, Y and Z work and they do use GLSL."
                              "(dimwitted dev) So what, the code runs fine here."
                              "(smart dev) Let me take a look. Hey, you are using saturate(), implicit casts and other HLSL stuff in GLSL. What the hell is wrong with you?"
                              "(dimwitted dev) Err... Ati sucks?"
                              "(user) Well, uh, ok I'll go play some other game. Thanks anyway!"

                              I just hope they know better this time and this is simply caused by immature drivers.

                              Comment


                              • #45
                                Also

                                float4 array[2] = {(float4)(0.0f), (float4)(0.0f)};

                                works for AMD but does not for Nvidia.

                                Comment

                                Working...
                                X