PAX Dev slides

Awesome. I'm reading it. Nice Slides.

Thanks for sharing these, love code and tech

Just wonder before on forum you talking that you want to adopt extensions which isn't yet included within GL core. Did you mean direct_state_access back then? Also when it's not included into OpenGL 4.5 do you see possibility to use it in PA? Thoughts?

Or did you mean some other extensions too? Which one?

Very cool stuff @varrak. Thanks for sharing mate.

I was hoping I might read something in there about the future implementation of SLi? Is it still on the table as a future improvement down the track?

Cheers,

-Todd

Thanks for the response @varrak,

Good to know!

Cheers,

-Todd

This slideshow made me mentally aroused.
I always love seeing backbone stuff for games, its so interesting.

I have an old dual Intel LGA2011 system(It still runs like a beast. ), yknow, dual Xeons? Its fun stuff. Will that system run PA at all, since its using two physical processor sets? And more importantly, since a lot of PA is processor based, will it run better?

No reason why it's wouldn't work. Actually I suppose I know one of two guys who tested it, but under Windows.

Not likely. I have no idea what actual overhead is, but I pretty sure that communication between processors have high delay and RAM is also issue so using two sockets for single game client wouldn't work well.

Though this is interesting question related to server-side.

The game isn't optimized to use that many cores, so the performance wouldn't be much different

The game barely utilizes a duel core multi-threaded CPU atm.

Is it bad that I'm making a openGl engine for myself and I didn't understand 1/4 of it?

He he he. Looks like I have a lot of reading to do.

I really liked this
even though I didnt understand half of this tech talk, I got the point that developing in openGL is really tough, and doing such things with openGL is quiet imprissive

on the other hand, did I get right that the game has a greater performance with vendor "N"?
I guess my next computer will be nvidia xD

Not necessarily. What he said, was that vendor "N"'s driver was more tolerant towards broken shader syntax and other "you should not have done that"-stuff, plus support was more competent/responsive.

Not a single word about raw performance though. Plus, Nvidia apparently also had some nasty bugs.

Thanks !!!!!! jumping on it !

I've said this in another post but former Valve developer Rich Geldreich's "The Truth on OpenGL Driver Quality" is worth a read and matches up with what I've heard elsewhere from credible sources. The comments are also enlightening.

The thing that's a bit worrying about all these vendor shenanigans is whether games of today will continue to work into the far future. I can think of a fair number of 7-10 year old titles that have graphics problems or simply crash on up-to-date PCs.

I'd still go nVidia though because their dev support is so much stronger, which means that games like this, and many others, tend to have far less issues on nVidia hardware. AMD often give better bang for buck, but you're going to have to put up with more games having more quirks.

Dunno, as a dev, I would probably go for AMD since they have superior cross platform debugging tools and a less error tolerant implementation, and a second alibi card from Nvidia to get access to their support, because that is virtually non-existent with AMD. Going purely Nvidia will probably result in unclean / unportable code since the driver is tolerating far too much.

As a user, it doesn't matter much. Yes, few applications will be "broken" on AMD cards (mostly since the devs did only develop on Nvidia cards, screwed up, and the Nvidia driver was so "generous" to ignore/fix the error silently), but in the end, all well tested applications run equally well on both platforms.

Sorry, I meant as an end user. As a dev you're going to go all three because doing otherwise is madness.

But not all applications are well tested, and even if they are discovering a bug is no guarantee of resolution prior to shipping.