Announcement

Collapse
No announcement yet.

Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

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

  • #41
    Originally posted by smitty3268 View Post
    There's not much reason not to, once you've got the support for GL_ARB_get_program_binary present.

    Mesa had some patches to do this as well, although they never got committed.
    The docs have this marked as done. Are you sure it wasnt commited?

    Edit: Ahh I realise now you are talking about the caching.

    Comment


    • #42
      Originally posted by GreatEmerald View Post
      Depends on what you call "open source" (Unreal series games have open-source game logic, for example, and some come with the C++ headers), and no AAA game has ever tried to use the fully open engine + proprietary content way up to now, as far as I know. So you can't say "It's never worked" when nobody ever tried it to begin with.
      Quake engines (IdTech ones) were opensourced at times. And they were good to create OpenArena and such, but they were not necessarily good for id, they got some hires, but not so many contributions back (look for Doom3 engine for example).

      Comment


      • #43
        Originally posted by tarceri View Post
        The docs have this marked as done. Are you sure it wasnt commited?

        Edit: Ahh I realise now you are talking about the caching.
        The docs also state "(0 binary formats)", which very likely means that even though all the API entry points are implemented,
        no driver backend actually exposes the functionality. I recall hearing that especially for the llvm based drivers, implementing
        compiled binary export is a huge headache and likely not worth the effort.

        Comment


        • #44
          Originally posted by ciplogic View Post
          Quake engines (IdTech ones) were opensourced at times. And they were good to create OpenArena and such, but they were not necessarily good for id, they got some hires, but not so many contributions back (look for Doom3 engine for example).
          What contribution back?

          O_O

          All those moves where performed when IdSoftware had no further commercial use for those codebases. (Movied to newer tech)

          "Hires" is all one could reasonably expect from such moves

          Comment


          • #45
            Is there a reason why that functionality is not enabled by default?

            I mean why not parallelize all compilation and then block execution of code that actually do anything with results?

            That should be transparent to the app, and should provide none to some to a lot improvements, but never any regressions.


            So why its not default?

            Comment


            • #46
              Originally posted by przemoli View Post
              Is there a reason why that functionality is not enabled by default?

              I mean why not parallelize all compilation and then block execution of code that actually do anything with results?

              That should be transparent to the app, and should provide none to some to a lot improvements, but never any regressions.


              So why its not default?
              Overhead. If 99% of apps do

              Code:
              for () {
                  compile
                  check result
              }
              Then automatically starting and waiting for a thread is going to slow that app down.

              Comment


              • #47
                Originally posted by curaga View Post
                Overhead. If 99% of apps do

                Code:
                for () {
                    compile
                    check result
                }
                Then automatically starting and waiting for a thread is going to slow that app down.
                Driver already have pool of threads (and not that Linux have some heavy threads anyway). And initial state should be identical to all of them. So resource usage when no additional threads are used (beyond first) should be very very minimal. (Linux have that layzy copy-on-write approach)

                Comment


                • #48
                  Originally posted by GreatEmerald View Post
                  Depends on what you call "open source" (Unreal series games have open-source game logic, for example, and some come with the C++ headers), and no AAA game has ever tried to use the fully open engine + proprietary content way up to now, as far as I know. So you can't say "It's never worked" when nobody ever tried it to begin with.
                  "It's never worked this way" is not "It's never worked".

                  Comment


                  • #49
                    Originally posted by DaVince View Post
                    "It's never worked this way" is not "It's never worked".
                    I don't see the difference in the context.

                    Comment


                    • #50
                      if you two have gotten to the point that you are argueing semantics, then it is safe to say that all meaningful conversation is over. Abort Thread.

                      Comment

                      Working...
                      X