Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 65

Thread: Few notes about Carmack's keynote at QuakeCon 2009

  1. #41
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by Dragonlord View Post
    And here again we see why monolithic engine design is a relic of the past and not scalable enough to meet the needs of today and in the future.
    It's not so much the engine as the lack of consumer demand and the poor state of linux's chosen graphics subsystems. This does make something very clear though, the future of quality commercial games on linux rests solely on the efforts of projects like wine (sorry Svartalf, but it's true).

  2. #42
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Am I the only one who interpreted Carmack's response as primarily saying "new games cost a heck of a lot more to port than old games, and as far as we can see the market has grown but not enough for a port to make sense" ?

    The graphics subsystems are already being addressed; I think one could make a pretty case that even the open source drivers will reach an appropriate level in less time than a port would require, and an iD engine is one of those apps that everyone will be sure to support properly.

    The big unknown that I see is still market size; which is a combination of (a) widely varying numbers for Linux market share, (b) an apparent bias towards low end systems (eg netbooks) which may not be able to run Rage usefully, and (c) not enough market data for sales of Linux-specific SKUs to make a case for how much additional sales will result from providing a Linux client vs hoping Wine will suffice.

    The only really credible market share numbers suggest maybe 1% market share for Linux vs 8% for MacOS, although there are all kinds of seemingly reasonable numbers around (from individual distros) which suggest a much larger market share for Linux. It seems to me that the most useful thing we could do here is to paint a consistent, credible picture for game developers of the market potential for native Linux clients.

    I don't know if the required data even exists; I can tell you that if it does it's pretty darned hard to find.
    Last edited by bridgman; 08-22-2009 at 08:49 PM.

  3. #43
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by bridgman View Post

    The graphics subsystems are already being addressed; I think one could make a pretty case that even the open source drivers will reach an appropriate level in less time than a port would require, and an iD engine is one of those apps that everyone will be sure to support properly.
    IIRC Bridgeman you were the one saying that we can realistically eventually expect ~70% performance of what a binary blob can provide when it comes to 3d performance. That would mean that you would have to have at least +1 generation card above the minimum specs of an equivelent blob based or windows system. Then you also have to account for that games such as Rage are going to push system hardware fairly hard and to use that +1 graphics card you are also going to have to wait until proper and decent support is added for that card in the opensource drivers. This all adds an additional amount of time to get a good enough solution utilizing FOSS drivers and it would not be unreasonable going by previous "time to execution" of the FOSS solutions to be 1 - 2 years. By that time the world has moved on and the game is old news. Until that time comes where opensource solutions can offer same day acceptable solutions to when a 'A' title is released I can't see 'A' titles seriously being ported to linux.

  4. #44
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

    Quote Originally Posted by deanjo View Post
    IIRC Bridgeman you were the one saying that we can realistically eventually expect ~70% performance of what a binary blob can provide when it comes to 3d performance. That would mean that you would have to have at least +1 generation card above the minimum specs of an equivelent blob based or windows system.
    +1 model, not +1 generation, right ? Even a midrange board will give decent gaming performance these days, and a high end card usually offers more than enough performance to make up for the difference in driver efficiency... or you could just take the eye candy down a bit.

    AFAIK the Rage engine is targeting DX9-level hardware, so recent and current GPUs should be fine as long as the driver functionality (specifically level of OpenGL support) is there.

    Quote Originally Posted by deanjo View Post
    Then you also have to account for that games such as Rage are going to push system hardware fairly hard and to use that +1 graphics card you are also going to have to wait until proper and decent support is added for that card in the opensource drivers.
    Yes, that's the time I'm talking about, but it's more of a one-time effort and doesn't have to be repeated for every new GPU.

    The delay would also be a lot shorter for the binary drivers - my point was that *even* the open source drivers would probably have the required level of support by the time the engine was ported.

    Quote Originally Posted by deanjo View Post
    This all adds an additional amount of time to get a good enough solution utilizing FOSS drivers and it would not be unreasonable going by previous "time to execution" of the FOSS solutions to be 1 - 2 years.
    You're including the time it took to catch up from 6-ish years of not supporting open driver development; we would only see that delay again if we stopped supporting driver development and had to catch up again.

    Quote Originally Posted by deanjo View Post
    By that time the world has moved on and the game is old news. Until that time comes where opensource solutions can offer same day acceptable solutions to when a 'A' title is released I can't see 'A' titles seriously being ported to linux.
    I said "even the open source drivers". With the Catalyst driver we run pretty much the same OpenGL stack for all OSes, so if the game runs on one OS then similar support will be available on Linux at the same time, and I think we are seeing enough activity in the open source drivers to have confidence that adequate OpenGL support will be available there as well.
    Last edited by bridgman; 08-22-2009 at 11:05 PM.

  5. #45
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by bridgman View Post
    +1 model, not +1 generation, right ? Even a midrange board will give decent gaming performance these days, and a high end card usually offers more than enough performance to make up for the difference in driver efficiency... or you could just take the eye candy down a bit.
    30% increase in performance would generally require more then just a one step upgrade in model in the same family.

    AFAIK the Rage engine is targeting DX9-level hardware, so recent and current GPUs should be fine as long as the driver functionality (specifically level of OpenGL support) is there.
    Don't be so sure about that. The Siggraph presentation of the challenges of the idtech 5 engine shows that for id to achieve the goals that they set out for themselves some massive parallelization is going to be needed. (Read cuda/openCL)

    http://s09.idav.ucdavis.edu/talks/05...Challenges.pdf

    Yes, that's the time I'm talking about, but it's more of a one-time effort and doesn't have to be repeated for every new GPU.

    The delay would also be a lot shorter for the binary drivers - my point was that *even* the open source drivers would probably have the required level of support by the time the engine was ported.

    You're including the time it took to catch up from 6-ish years of not supporting open driver development; we would only see that delay again if we stopped supporting driver development and had to catch up again.
    It's not only the drivers that you have to worry about, in the case of idTech 5 ogl 2.1 support may suffice for it. However other games may require OGL support at a higher level that mesa currently provides. The mesa ogl level usually takes about a year to get the next level supported. Plus with idtech 5 it is more then likely going to have to use a GPGPU solution for it's parallelism requirements. openCL support is still a relative unknown on anything but Nvidia right now in linux.

    I said "even the open source drivers". With the Catalyst driver we run pretty much the same OpenGL stack for all OSes, so if the game runs on one OS then similar support will be available on Linux at the same time, and I think we are seeing enough activity in the open source drivers to have confidence that adequate OpenGL support will be available there as well.
    I can't say I share your optimistic view. Doom 3 for example had some big issues with the catalyst drivers when it debuted, and recently had issues with even ET:QW despite it being out for a while. That being all said and with Carmacks comments, native linux support is unlikely for idtech 5, which means that wine and kin is probably going to be the only solution out there to run those games. In this scenario the free drivers have ALOT of work to do to properly support the requirements of such an endeavor.

  6. #46
    Join Date
    Oct 2007
    Posts
    912

    Default

    idtech5 won't require gpgpu systems, it's just that it might help if there's spare processing time to use it for a given engine job. They already do things such as additional processing whilst the graphics card is busy just to keep their timing constraints, so they really don't rely upon gpgpu stuff, more just parallel processing (threads, multiple cpu cores, etc).

  7. #47
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by mirv View Post
    idtech5 won't require gpgpu systems, it's just that it might help if there's spare processing time to use it for a given engine job. They already do things such as additional processing whilst the graphics card is busy just to keep their timing constraints, so they really don't rely upon gpgpu stuff, more just parallel processing (threads, multiple cpu cores, etc).
    Required, no, required for a satisfying experience, more then likely. Really, read the siggraph presentation.

    –Anticipate CUDA, OpenCL, Larrabee support
    Last edited by deanjo; 08-23-2009 at 06:52 AM.

  8. #48
    Join Date
    Oct 2007
    Posts
    912

    Default

    Quote Originally Posted by deanjo View Post
    Required, no, required for a satisfying experience, more then likely. Really, read the siggraph presentation.
    I did read it. I also listened to most of the keynote (it's two hours long, so I did skip some parts). I was merely pointing out that idtech5 isn't about leveraging gpgpu - the paper quite clearly state about parallel processing and making an engine to take advantage of a range of possibilities.
    It just seems these days that people think that gpgpu is the answer to everything, but it's really not that useful if your graphics card is too busy drawing graphics to spare the time to compute something else.

  9. #49
    Join Date
    Jul 2008
    Posts
    833

    Default

    Quote Originally Posted by deanjo View Post
    It's not so much the engine as the lack of consumer demand and the poor state of linux's chosen graphics subsystems. This does make something very clear though, the future of quality commercial games on linux rests solely on the efforts of projects like wine (sorry Svartalf, but it's true).
    I meant more the ever increasing range of hardware and software ( OS, drivers, apps ). Supporting all these different setups is a chore and getting optimal performance out of all of them is neigh impossible. We had this back in the old days where each app had to support everything on it's own ( like including own printer drivers or graphic drivers ). Back then we figured out that placing an OS between the hardware and apps solves this problem. But in game development we are still in stone age which is the cause of all the problems we have currently with games, engines and porting.

  10. #50
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote Originally Posted by mirv View Post
    I did read it. I also listened to most of the keynote (it's two hours long, so I did skip some parts). I was merely pointing out that idtech5 isn't about leveraging gpgpu - the paper quite clearly state about parallel processing and making an engine to take advantage of a range of possibilities.
    It just seems these days that people think that gpgpu is the answer to everything, but it's really not that useful if your graphics card is too busy drawing graphics to spare the time to compute something else.
    Your right, GPGPU isn't the answer to everything. These tasks can be done as well with raw core speed but we see right now that every major hardware player out there has basically abandoned this route in favor of parallelism. You don't see roadmaps with a 5 ghz cpu anymore, you do however see roadmaps and plans with cpu's having cores in the hundreds. It just happens to be right now that the solutions that are available to day that offers the most parallelism with being effecient at it happens to be GPU's.

Posting Permissions

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