Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Member Since 15 Dec 2001
Offline Last Active Today, 08:49 PM

#5160278 using static initialisation for paralelization?

Posted by phantom on 13 June 2014 - 06:53 AM

if this is not done to allow some parallel works what it is for? 
and how is the mechanizm it slowed my program and growed it +50KB

No, that will not do anything in parallel either.
It is there so that when you call functions from threads the static data is setup in a thread safe manner.
In order to ensure this the runtime will have to add some code/mutex locks to make sure two threads can't try to initialise at the same time.

void foo()
static int one = f1(); // potetntialy referencing and updating other data
static int two = f2();
static int three = f3();
static int four = f4();

int main()
parallel_invoke(foo, foo); // some function which will run supplied functions on multiple threads
printf("\n done.");

So, in the above code 'foo' is invoked on two threads via the helper function. In C++03 the static initialisation of the function's variables would not be safe as both threads might end up running the setup functions. In C++11 only one thread would.

#5160276 [DX11] Why we need sRGB back buffer

Posted by phantom on 13 June 2014 - 06:45 AM

Erm, if the backbuffer is sRGB then you shouldn't be providing ANY changes to the values you are writing out; you should be writing linear values and allowing the hardware to do the conversion to sRGB space when it writes the data.

The correct versions are either;
linear maths in shader => sRGB buffer
linear maths in shader => pow(1/2.2) => non-sRGB buffer 8bit/channel image

Anything else is wrong.
(Also, keep in mind sRGB isn't just a pow(2.2) curve, it has a toe at the low end to 'boost' the dark colours).

#5159220 whats this? javscript/ga

Posted by phantom on 09 June 2014 - 04:21 AM

Do not bump your posts so soon after your last one, wait at least 24h between posts to give people a chance to reply.

#5158635 Metal API .... whait what

Posted by phantom on 06 June 2014 - 02:03 AM

Yeah I've mostly ignored commenting on the AZDO presentation, because IMHO their position of "Hey, did you know that our slow API is fast when you don't use it at all" isn't a very progressive stance to be taking laugh.png

heh, yeah - my take on it has been "ok, this is half a solution" but the feeling coming off the guys involved was 'this is all you need!' often combined with some waffle about a single core being able to saturate the GPU's command processor, which is kind of missing the point.

Although yesterday or the day before in a twitter thread there was signs that those involved do recognise the API need changes so all might not be lost, but I'm not counting on it personally.

#5158438 Metal API .... whait what

Posted by phantom on 05 June 2014 - 10:29 AM

Really it depends on your goals and targets.

For many things OpenGL4.x or 3.x is going to be plenty; if you aren't driver limited then you'll probably be OK.
If you want to push things and want to be cutting edge then OpenGL4.4 and the associated information presented in the 'approaching zero driver overhead' (aka 'AZDO') talk is a must. (link to the presentation from GDC2014; yay free content!).

OpenGL isn't going to up and vanish overnight but it's likely to have a harder time in AAA space (again!) going forward simply because it isn't matching the wide front end which engines are gravitating towards as they better suit the consoles, Mantle and D3D12 (as well as making better use of CPU resources in general).

If nothing else NV and Valve have an interest in keeping it going which will drag AMD and Intel along for the ride in the Linux space at least. (Mantle is meant to end up on Linux but I'd be surprised if that happened before 2015).

#5158373 Metal API .... whait what

Posted by phantom on 05 June 2014 - 06:51 AM

Btw is Apple possibly considering cutting the cord with OpenGL ES?
I know that Apple can be very aggressive in pushing new stuff. Do you think this is a threat, an alternative or is the "damage" already done?

Going forward Apple won't need ES any more; they'll probably continue to support 3.0 for a while yet but that'll likely be it.
They'll probably stay part of the board for a while but, like MS when they stopped caring about OpenGL and left the ARB, I think it's only a matter of time before they leave.

#5158370 Metal API .... whait what

Posted by phantom on 05 June 2014 - 06:50 AM

So D3D11 beats GL hands down for performance and ease-of-use and, D3D12/Mantle are about to blow D3D11 out of the water in terms of performance!! This is mostly on the CPU side, but also with GPU side improvements too... And GL is showing no sign of even having a plan to deal with this future.
D3D11 at least tried to allow for multi-threading, whih didn't quite work in practice, but the API is there for it. With D3D12/Mantle, CPU API overheads will actually scale linearly with processing cores. So, not only will mantle be 10-100x faster than GL/D3D9, but can also get an extra 8x boost on a modern oct-core CPU!

To be fair the recent OpenGL core/extension features do go some way to helping with regards to the "Approaching Zero Driver Overhead" stuff, and while 'sidestepping the API' isn't a full solution this kind of persistently mapped data and GPU pull setup is, imo, going to be a corner stone of things going forward.

The problem it has three issues for GL going forward;
1) Drivers. AMD have 4.4 drivers now but likely to have bugs/issues due to lack of testing; not sure of Intel's state.
2) Features. While supported some stuff might well be slow on some hardware, fast on another and fast in certain situations.
3) Future. D3D12/Mantle are going to (more than likely) expose the same AZDO features AND remove CPU overhead AND allow threading.

1 and 2 are 'fixable' in that drivers will improve and the IHVs are pretty upfront about what does what where.
However 3 is the real problem for OpenGL and by extension SteamOS which relies on it.

#5158335 Metal API .... whait what

Posted by phantom on 05 June 2014 - 04:03 AM

"My engine supports 7 at the moment (D3D9, D3D11, Mantle, Xbox360, PS3, PS4, XboxOne), and I want to add GL4 and GL3 to that list too..."
I never quite understood why people bother to implement Direct3D at all when GL gives you 3 platforms (even if they aren't big), and D3D gives you 1.
Luck of the draw??

Short version; D3D implementations tend not to suck.

Slightly longer version;

D3D9/Xbox are pretty similar as is XboxOne and D3D11; while you'll still have separate code paths for the consoles you can practically bootstrap one from the other. Until reasonably recent OpenGL was also lacking the features found in D3D; look at how long it took Compute to appear for example (and then become stable).

It's only in recent years that OpenGL has got the tooling to compete too; although part of that is down to D3D's tools going backwards a bit.

End of the day if I throw some code at D3D and it doesn't work I suspect my code (and with D3D11 I can turn on a verbose debug mode which will quickly point out errors and suggest solutions!). If I throw some code at OpenGL and it doesn't work I'm left wondering if it was me or the driver and I'm short a quick tool to find out.

#5158326 Metal API .... whait what

Posted by phantom on 05 June 2014 - 02:10 AM

So instead of debugging your GLES code for iOS and adding in the special hacks and workarounds required by Apple's implementation of it, you can just use Apple's API instead, which has a much greater chance of actually following it's specifications to the letter laugh.png

I guess the ironic thing here is that Apple tends to be the best of the GL|ES implementations. I've seen Android GL|ES implementations straight up lie about what they support; including a Google Nexus 10 device which sits on my desk and will happily claim to support ES3.0 and then output log entries telling me I'm using unsupported functions! Or the NV Tegra4 driver which didn't even do that; claimed to support things and then just silently do nothing when you try to use them.

(I've only been doing Android stuff directly for 3 months; by week 2 I'd concluded it was a hateful OS to develop for...)

I've got my fingers crossed that nVidia and Intel get on board the Mantle train, implement it in their own drivers, and form their own committee to standardize it. As it stands at the moment, it's not designed around AMD cards and Windows specifically, so this could happen.

This would be my preferred route in the PC space; as much as D3D12 will catch NV and Intel on Windows it won't help the Linux/SteamOS situation one bit for them (Mantle is targeted at Linux in the 'future').

Unfortunately the public noise from NV seems to be 'nope.' which doesn't give me much hope right now sad.png

#5158216 Metal API .... whait what

Posted by phantom on 04 June 2014 - 03:02 PM

I think there's far more work than just a recompile. You're going to have to contend with bugs from 2 different APIs. And what is the benefit, anyway? None, because you assets are made for the OpenGL ES lowest common denominator. You have the fast API only available on devices that are already fast.
Look at it another way. OpenGL ES 3.0 has been available for more than a year, yet there are no commercial games for it

If you license an existing engine that is it; you recompile, you run on Metal.
Your initial assertion was 'we wont see games on Metal for years' which is provably false.

Going forward you might want to switch on more advanced things for the Mantle version of the game but that's the same problem as already existed with different hardware levels so hardly new. Until that point highend phones either get the added bonus of higher frame rate OR reduced power consumption depending on where the bottle neck is as the CPU will be doing less work.

Your comments pretty much come across as 'not everyone can use it, why bother?' which is a dumb position to take because if we took that approach we'd never advance and we'd still be sat in a cave somewhere hoping a tiger isn't going to eat us in the night..

And for the record I work on UE4 doing Android dev and we certainly use OpenGL|ES 3.0 on target devices which support it.
Now, as to the level of support on said target devices I can't speak to that...

#5158113 Metal API .... whait what

Posted by phantom on 04 June 2014 - 09:03 AM

Well, they would have to fall back to OpenGL ES for devices that don't support it. Even the iPhone 5c doesn't support metal and that is a device still being sold

Yes, of course, in the same way they use the platform specific APIs on other platforms; my point was this isn't a "announced, games might start using it later" but a case of if you are using any of those engines (which is common, certainly in the Unity case) then a recompile will get you Metal support so it won't be "years" like you asserted.

Even for small teams it might be possible to get on it quickly as the general feedback coming from those who have done it has been that it's pretty quick/easy to get things going with it.

#5158094 Metal API .... whait what

Posted by phantom on 04 June 2014 - 08:12 AM

Frostbite, CryEngine, Unity and UE4.0 already have support for it - if you are using any of them then your game can already use it.

(Well, once the updates hit... so weeks?)

#5157817 Metal API .... whait what

Posted by phantom on 03 June 2014 - 08:23 AM

We are now in a fun situation where 3 APIs look largely the same (D3D12, Mantle and Metal) and OpenGL - while this won't "kill" OpenGL the general feeling outside of those who have a vested interest in it is that the other 3 are going to murder it in CPU performance due to lower overhead, explicate control and the ability to setup work across multiple threads.

It'll be interesting to see what, if any, reply Khronos has to this direction of development because aside from the N API problem the shape of the thing is what devs have been asking for (and on consoles using) for a while now.

#5157386 How much time does a game company give programmers to solve something

Posted by phantom on 01 June 2014 - 01:46 PM

How long is a piece of string?

If something needs to be done then you have to give it time to be done; at worst you'll feature cut if you run out of time.

I've worked on features which had had days to completed and others where I've managed to get a couple of months by convincing people the extra time will be worth the cost even though it over ran initial estimates.

#5157222 Overhead of subroutines in arrays when multidrawing?

Posted by phantom on 31 May 2014 - 03:56 PM

The problem with saying '5% less performance' is we don't know if you were CPU or GPU bound in your tests.

If you were CPU bound then it's possible the extra calls made the difference.
If you were GPU bound then it might be a GPU resource allocation problem.
Or it could be anything in between smile.png

If you could run the tests via AMD's profiling tools and get some solid numbers that would be useful.
Even their off-line shader analyser might give some decent guideline numbers as that'll tell you VGPR/SGPR usage and you can dig from there to see what is going on.