Where's the mac version of LoG2?

[Dr.Disaster]

You aren't actually falling for the "one thread -> one core" conclusion, don't you?

"No need to buy a multicore cpu, guys. DX games can't use them anyway"

Even with a DX-wise limit to one thread for all draw commands you can have a dynamic number of threads building them. In my post right above Petri's you did link to i refered to our finding that LoG2 does in fact this: launch more threads when needed. Of course additional threads can only build so much drawcalls as the draw command sending thread gets cpu-time to submit them.

So yes, as Petri has stated, there is a limit how many draw calls can be submitted but then drawing the conclusion that the engine was/is ment for a single core is very far fetched.

[Frenchie]

Can we keep the cpu discussion in the "very hot" topic only?

It is still too early to get Mac requirements as there's no beta testing yet. In the PC version compatibility ruled over performance to reach a bigger audience, but for Macs compatibility is of lesser importance with similar hardware. Thus, I hope the performance should be slightly better.

[Dr.Disaster]

In case Petri does a 1-to-1 translation of the renderer from DX9 to OpenGL we should see about the same performance. It get's interesting during the optimizing process if he can replace some of the DX bottlenecks with GL specifc routines like MultiDrawIndirect that allow to pack large numbers of draw calls into a single one.

I don't know how the engine works internally so take anything i say now with a good grain of salt. In LoG2 we have tiles with grass in open areas. Drawing each straw would be inefficient so it's prolly a bunch of straws which then gets drawn a few dozen times. Now reducing the need of sending such a "draw" command from several times to just one should boost overall performance. OpenGl has routines at it's disposal which make this possible; i.e. see http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/

[Frenchie]

Are you also talking about driver overhead? I read about on a wiki page.

Perhaps this might give more insight : http://www.grimrock.net/2014/03/07/perf ... mizations/

If you read the comments you might conclude that Petri will write a 64-bit only engine for LoG3.

[Dr.Disaster]

I just went after possibilities to reduce draw call numbers and cost but yes, driver overhead comes into play too. To go with the example i used: when you could instruct the gpu to draw an entire tile of grass with only one draw call instead of dozens(?) you need to call less routines which reduces overhead.

[Frenchie]

Petri, can you post some images of your progress like this surreal image (shader error) here:

SpoilerShow

[petri]

Petri, can you post some images of your progress like this surreal image (shader error) here:

Sure I can post more images of funky graphics glitches if I get any. At the moment the game looks identical on OS X, but it's not running fast enough yet. Hunting down those milliseconds..

[Frenchie]

Anything is progress...

Did you ever play Age of Conan? When it game out it was there were so many shader errors I considered it a gamma...

[Azel]

I loved Age of Conan. I still have the Collectors Edition in my closet (collecting ages of dust).

[vlzvl]

I just went after possibilities to reduce draw call numbers and cost but yes, driver overhead comes into play too. To go with the example i used: when you could instruct the gpu to draw an entire tile of grass with only one draw call instead of dozens(?) you need to call less routines which reduces overhead.

In fact, there's no technical difference between DX and OpenGL on draw calls. For example:

DX

Code: Select all

HRESULT DrawPrimitive(D3DPRIMITIVETYPE PrimitiveType, UINT StartVertex, UINT PrimitiveCount);

OpenGL

Code: Select all

void glDrawArrays(GLenum mode,  GLint first,  GLsizei count);

As you see, the draw calls are identical. There can be some limits like the total number of vertices but to my experience are driver-specific or non-exist. Some GPUs can render tens of thousands triangles in just one call with the above functions while some other can render less.
One rule of thumb i found is to try and pack at least 100 triangles / draw comamnd, having the same state etc. same texture, same colors, same transparency whatever.

The real performance killer comes from drawing 1,2 or 5 trianges by a single draw command as above. If your scene has thousands of triangles that translates to hundreds of DX/OpenGL commands, which in turn may or may not be optimized by driver. Combine that with a consuming shader and you have just killed the performance.

One can get a massive performance just by packing hunders of triangles using the same texture, thus sending far less commands to the driver -> GPU. I don't know about the grass effect but certainly terrains are very demanding in this kind of issue.

@petri, i had a performance problem as well to my OGL rendered in OSX. For some reason, OSX driver was always set my renderer to software. Apple drivers have a software revert for everything that doesn't supported in hardware but there's no easy way to know about My solution was to add the following to my list of OpenGL context format attributes (Cocoa):

Code: Select all

	  NSOpenGLPixelFormatAttribute formatAttrib[] = {
             ...
             NSOpenGLPFAAccelerated,   // <-- that forces the Apple drivers to NOT revert to software renderer
             ...
	  };
         
     ...

More info here.