Mojang Hardware Stats

[kappa]

Just noticed that Mojang now release their Minecraft user hardware stats here (in all its unprocessed glory so a bit hard to read). Other companies like Valve do this too but this release is much more relevant to the folk here since it includes stuff like Java version, OpenGL version and OS version for all 3 big platforms, etc for millions of game players.

Some rough conclusions we can get from the data include stuff like:

• About 91% of Minecraft users have computers that support OpenGL 2.0+, meaning we can write games fully with the programmable pipeline (GLSL shaders) and start to safely forget about supporting or having a fallback for the old fixed function pipeline.
• Intel cards are crap (yes everybody already knew that) and account for the majority of the 9% that don't support OpenGL 2.0+.
• Java 5 use has pretty much died with very few users still on that version of Java.
• OS X 10.4 use is pretty much dead however OS X 10.5 still has significant market share.

I'm sure there are more conclusions that we can make from the data but its a bit of a pain to do it without properly processing the raw data. Do keep in mind that this data is pretty specific to the Minecraft user base and probably not representative of all computer users but still very relevant for Java game developers.

[Jimmt]

thanks for the link, very interesting.

[princec]

I pretty much concur with their findings.

Cas

Games published by our own members! Check 'em out!

[SkyAphid]

This makes me happy.

[theagentd]

Gotta love Iphones. Made me wait for 5 minutes to load what I thought was a slowly downloaded text file or something only to end up with a 200+MB compressed file I can´t open. Someone apparently decided that showing what you´re about to download was a too advanced feature or something. -____-

Anyway, what´s the stats for OGL 3 and 4?

[kappa]

Anyway, what´s the stats for OGL 3 and 4?

• 51% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.0+.
• 38.8% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.2+.
• 34.2% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.3+.
• 19.6% of the Minecraft user base have computers with graphics cards capable of OpenGL 4.0+.
• 8% of the Minecraft user base have computers with graphics cards capable of running the latest OpenGL version 4.2.

[theagentd]

Anyway, what´s the stats for OGL 3 and 4?

• 51% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.0+.
• 38.8% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.2+.
• 19.6% of the Minecraft user base have computers with graphics cards capable of OpenGL 4.0+.
• 8% of the Minecraft user base have computers with graphics cards capable of running the latest OpenGL version 4.2.

OGL 3.0 hardware = OGL 3.3 hardware. Just need a driver update. >_>

[kappa]

OGL 3.0 hardware = OGL 3.3 hardware. Just need a driver update. >_>

14.8% of Minecraft users are on OpenGL 3.0 to 3.2, considering the registered user base of Minecraft is listed at about 28 million users that is just over 4 million computers that need a driver update

Even if you get all those computers updated, excluding half your potential user base by supporting such a high version of OpenGL is a bit too much.

[princec]

The logistics of driver updates is highly bothering. As far as most consumers is concerned, hardware and software are "one thing". Always aim for the lowest common denominator...

Cas

[Orangy Tang]

It does looks like GL2.0 is a reasonable baseline these days, which is nice. Time to actually finish my shader based 2d renderer.

Are there any existing libraries like Slick that are shader based? All the ones that I can think of off hand are fixed-function.

Games published by our own members! Check 'em out!

[princec]

I've finally moved to shaders as well. Only two years after moving to VBOs

Cas

[ReBirth]

First read thread's title I thought we're talking about notch's (and team's) PC

[pitbuller]

It does looks like GL2.0 is a reasonable baseline these days, which is nice. Time to actually finish my shader based 2d renderer.

Are there any existing libraries like Slick that are shader based? All the ones that I can think of off hand are fixed-function.

Libgdx have fixed and shader path for all the rendering stuff. SpriteBatch default shader work almoust anything altought being extremely simple(fast) one.

What are the other features that you seek from shader for 2d? I can't figure many general things.

[Orangy Tang]

What are the other features that you seek from shader for 2d? I can't figure many general things.

Personally I look for a rich set of graphics primitives (ie. not just Sprites + SpriteBatch) which interact well, alongside a flexible geometry pipeline that ideally lets you mix and match geometry types with different geometry formats and shaders with different geometry format requirements.

It's a hard problem, and one that most 2d libs don't really attempt to solve. I've made good headway but got distracted by writing an actual game so it's still pretty incomplete.

[theagentd]

It does looks like GL2.0 is a reasonable baseline these days, which is nice. Time to actually finish my shader based 2d renderer.

Are there any existing libraries like Slick that are shader based? All the ones that I can think of off hand are fixed-function.

Libgdx have fixed and shader path for all the rendering stuff. SpriteBatch default shader work almoust anything altought being extremely simple(fast) one.

What are the other features that you seek from shader for 2d? I can't figure many general things.

Geometry shaders. -_-'

[davedes]

What is are some practical uses of geometry shaders?

I've read that it's not practical for many tasks which you might expect (like point-based particle systems) as it's not very efficient. I haven't actually seen a single practical use of a geometry shader -- though I'd be interested to see their benefits.

Tessellation shaders, on the other hand... That's some cool stuff.

[theagentd]

What is are some practical uses of geometry shaders?

I've read that it's not practical for many tasks which you might expect (like point-based particle systems) as it's not very efficient. I haven't actually seen a single practical use of a geometry shader -- though I'd be interested to see their benefits.

Tessellation shaders, on the other hand... That's some cool stuff.

Proof? You know, Java is slow too....

[princec]

One extremely practical use for geometry shaders that would genuinely speed my code up by a considerable amount is drawing sprites. Currently I have to transform every vertex of a sprite's quad manually in Java before writing all the data out to a VBO. It's not that Java is massively slow at doing this per se, but the simple fact is that the GPU is probably rather faster at it, operates asynchronously, and I'd only have to write out a fraction of the data using a geometry shader.

The specific way it works is I'd just send the raw sprite info to the geometry shader - position, width, height, rotation angle, scales, vertex colours, etc; and the shader would then expand each one into four vertices. Thus reducing my bandwidth by an order of magnitude and freeing my CPU up to do gamey things.

Granted this is not generally a concern for most people but then I can use upwards of 8000 sprites in a single frame at 60Hz and it starts to become a bit of a bottleneck.

Cas

[theagentd]

Like Cas said, in the case of 2D it allows much more efficient usage of bandwidth since we don´t have to duplicate vertex data or do everything on the CPU. For 3D it´s suitable for algorithms that require visibility of all vertices in a triangle. A very simple example would be flat shading where we need to calculate a normal for each triangle. Since we can´t store multiple normals for each vertex without duplicating vertices it´s a lot more efficient to just calculate the normal in a geometry shader.

Geometry shaders also have other capabilites, like basic 3D rendering. It´s possible to bind a 3D texture (or a 2D texture array) to an FBO and then route triangles to different z-layers of the texture. This also possible with cube mapping, meaning that we can draw to a cubemap in a single pass or render to all cascades of cascaded shadow maps. A new OGL4 feature also allows you to specify the number of invocations of the geometry shader, improving parallelism in the GPU.

[davedes]

This isn't a comprehensive benchmark but it's interesting to see the marked difference in CPU usage:


GL_POINTS + geometry shader + vertex arrays: ~18,300 sprites at 60 FPS
GL_TRIANGLES + vertex arrays: ~17,500 sprites at 60 FPS

Can probably be further improved with interleaved arrays and VBOs.

Shader source, for those interested:
http://pastebin.com/R2kexnYJ

Though I wonder how this would hold up on other machines...

[princec]

I could do quite a lot more stuff with that extra CPU (not to mention another 10% sprite count).

Cas

[Orangy Tang]

Just to play devils advocate for a moment, but wouldn't this mean you'd *only* be able to render sprites? (ie. rectangles with a width/height/angle). Sure, some things (like nine patches) could be converted to sprites, but you'd loose the ability to have things like ribbons, curves, rings, circles, etc. You'd have to draw them in separate batches, which might mean further chopping up your geometry shader sprite batches heavily.

I'm not sure if the tradeoffs would overall be worth it. I suspect it might be highly scene dependent - I tend to have lots of non-sprite drawing, what about other people? Cas, are you faking things like your spotlights with rotated sprites?

[matheus23]

For that case, you could simple disable the geometry shader, and render everything without any limitations...

[Orangy Tang]

For that case, you could simple disable the geometry shader, and render everything without any limitations...

Yes, that's what I said by 'you'd have to draw them in separate batches'.

[matheus23]

For that case, you could simple disable the geometry shader, and render everything without any limitations...

Yes, that's what I said by 'you'd have to draw them in separate batches'.

oh.. okey, I think that comes from libGDX, right? ... Couldn't now that. Have never used libGDX

[princec]

Just to play devils advocate for a moment, but wouldn't this mean you'd *only* be able to render sprites? (ie. rectangles with a width/height/angle). Sure, some things (like nine patches) could be converted to sprites, but you'd loose the ability to have things like ribbons, curves, rings, circles, etc. You'd have to draw them in separate batches, which might mean further chopping up your geometry shader sprite batches heavily.

I'm not sure if the tradeoffs would overall be worth it. I suspect it might be highly scene dependent - I tend to have lots of non-sprite drawing, what about other people? Cas, are you faking things like your spotlights with rotated sprites?

Spotlights n that are just rotated sprites. Special effects such as radar circles, lasers, strobes, targeting reticule animations, that's done outside of the normal sprite rendering in a cunning sort of interleaving. It wouldn't quite work the same way as is currently in the library (which uses a the same VBOs for sprite vertices as for the effects geometry) - I'd probably have to use a completely separate VBO to avoid all sorts of confusion.
Anyway, all moot, as not enough machine support geometry shaders yet.

Cas

[Orangy Tang]

For that case, you could simple disable the geometry shader, and render everything without any limitations...

Yes, that's what I said by 'you'd have to draw them in separate batches'.

oh.. okey, I think that comes from libGDX, right? ... Couldn't now that. Have never used libGDX

I'm sorry but I genuinely can't parse that sentence. 

[ReBirth]

@Orangy Tang
I think he refers to your "separate batches" thing. As in libgdx you can have multiple instances of SpriteBatch to draw on screen, which each one holds its own properties. Based on my 2 hours experience on lwjgl, you can't do that except by popping and pushing property of GL.

Behold my post, prince is coming!

[davedes]

As in libgdx you can have multiple instances of SpriteBatch to draw on screen, which each one holds its own properties.

In this case a "batch" refers to sending geometry data to the GPU (e.g. VBO, vertex array, or glEnd). You need to flush the renderer and any currently accumulated sprites before you can change shaders. SpriteBatch may do this internally, just like it does whenever you give it a new texture. Having multiple SpriteBatch instances will not solve your problem.

[princec]

There's no need for you to flush anything - OpenGL drivers batch up the requests internally in a queue and execute them asynchronously. There's still a pipeline stall server-side but that's just because there has to be.

Cas