Jump to content

  • Log In with Google      Sign In   
  • Create Account


Opengl design


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#21 Mona2000   Members   -  Reputation: 558

Like
0Likes
Like

Posted 25 March 2014 - 03:55 PM

Except a good software renderer like WARP or LLVMpipe can run that kind of scene at more than playable FPS.



Sponsor:

#22 frob   Moderators   -  Reputation: 18841

Like
2Likes
Like

Posted 25 March 2014 - 10:54 PM


At this stage I really really regret even mentioning the word "Quake" here as my doing so seems to have steered this thread down a completely irrelevant path.  What I meant was a Quake-like level of scene complexity, as in low-polycount, low-resolution textures, low screen resolution (maxing out at perhaps 640x480 or 800x600), no complex effects, etc.
 ...  
So taking these two together, that's the kind of scenario where a software OpenGL implementation will get you below 1fps even with the low level of scene complexity I mention.  Yes, even on a modern CPU.  Anybody want a citation?  OK, see for example this thread where the OP in it got 0.5fps owing to using an OpenGL feature that was supported by the driver but not in hardware.

It all depends on what features you want.

 

I know you regret bringing up quake, but it is actually a good example. They released two versions, one using their custom rasterizer and another using the OpenGL rasterizer. IIRC they released the source for both. Just a hunch, but I'm fairly confident if you ran GLQuake with Mesa software drivers you'd probably still see a highly performant game on today's hardare.

 

The specific post you mentioned was fairly high polygons using a blending function. Neither of those fits the quake-style graphics which were low polygon and simple texturing.

 

Naturally if you are trying to run something complex in a software renderer, such as your collection of modern shaders or even a moderately complex blending function, then yes you are quickly going to get bogged down.

 

 

The first question was "what does this mean?" which I think was fully answered.

 

The second question was "is this possible?" which is a little more complex. It is certainly possible to make a fast 3D opengl game with a software renderer if you limit yourself to a subset of the features. It is also possible to make a 3D opengl game with a software renderer that takes hours per frame.

 

The OP was about OpenGL design. OpenGL is about rendering generally, and the design reflects that. Games represent a subset of what OpenGL does.


Check out my personal indie blog at bryanwagstaff.com.

#23 Aks9   Members   -  Reputation: 769

Like
0Likes
Like

Posted 26 March 2014 - 08:37 AM

Except a good software renderer like WARP or LLVMpipe can run that kind of scene at more than playable FPS.

Thanks for the examples. I was not aware that WARP even exists. It is really great, BUT it is a substitution in the cases when there is no GPU in the system, or drivers don't support 3D acceleration on such GPUs. As a substitution, it enables rendering, but it is at least an order of magnitude slower (which is excellent result) than there is a GPU. Usually it is almost two orders of magnitude. Anybody could easily experience that through 3DMark tests.

 

The first question was "what does this mean?" which I think was fully answered.

 

The second question was "is this possible?" which is a little more complex. It is certainly possible to make a fast 3D opengl game with a software renderer if you limit yourself to a subset of the features. It is also possible to make a 3D opengl game with a software renderer that takes hours per frame.

 

The OP was about OpenGL design. OpenGL is about rendering generally, and the design reflects that. Games represent a subset of what OpenGL does.

 

I completely agree that it is possible to do everything on the CPU side, but it is not a wise decision. OP has a very naive question, and I hope he had a better insight now. I'm glad that there are some efficient CPU based implementations, but they should be used only when any other alternative is impossible. Probably every low-end GPU can easily outperform the fastest commercial CPU, leaving it free to do other tasks.



#24 mhagain   Crossbones+   -  Reputation: 7422

Like
1Likes
Like

Posted 26 March 2014 - 12:14 PM

I completely agree that it is possible to do everything on the CPU side, but it is not a wise decision. OP has a very naive question, and I hope he had a better insight now. I'm glad that there are some efficient CPU based implementations, but they should be used only when any other alternative is impossible. Probably every low-end GPU can easily outperform the fastest commercial CPU, leaving it free to do other tasks.

 

Well there are cases, outside of the game development space, where software makes sense.  For example, the first line of the "invariance" section in your local friendly OpenGL specification warns you that OpenGL is not a pixel-exact specification.  So if you need pixel-exact results, you must look elsewhere.  Likewise the supported floating point precision limits may not meet some rendering requirements.

 

But these are outside of the game development space.  The general case is that neither is a perfect replacement for the other, so like any other tool sets, you pick the tools that match the job you want to do.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS