robbies

I can only speculate on this aspect (from inside the industry), but it's been plain to see that AMD has been hemorrhaging engineers (though they still have plenty of talent). This relates to your request about getting built-in support: I'm not sure AMD has the manpower to do that work, and they might be hoping the OSS community helps them with that...

Yes to your OpenCL stuff, no to your reverse-engineering stuff. The post you linked is about generating your own native shaders on GCN. GPUOpen could possibly expose that, but that's a difficult problem to expose to developers considering the variety of architectures exposed at any time by the IHVs (including just inside one IHV at any time). If they did go down that path, they would open up their internal bytecode-to-native-ISA shader compiler...which they haven't done yet, and have shown no indication of doing.

In my experience, the vast majority of realtime rendering engineers work on Windows (because of the products). The landscape is starting to change, but I'd spitball still 99% Windows ownership. Even for console development, the platform is Windows

Well, they were compute shaders, and that's not the intent of the article.

This is relatively old NV functionality. However, there were some complaints about this folder ballooning after installing a couple driver updates, which caused brand new shader blobs to be built. Not a huge issue, but that spurred some of the extension getting traction to allow games to manage the process

The original motivation for GetProgramBinary was to bypass the driver compiler passes, but in order to prevent the unpredictable (by the game) compilations that would happen mid-game, causing CPU spikes.

As far as Vulkan, this is not the same use case. Vulkan is using the DX model of compile high level to intermediate representation, and then let driver compile to maybe. One idea of SPIR-V is that any compiler can generate the bytecode, whereas on DX, it currently is that only fxc is allowed to (this didn't used to be the requirement...I speculate it changed when the IL started to drift away from HW ISA , making it so that targeting IL was a bad idea).

As far as GetProgramBinary on Vulkan, that doesn't jive with how it's supposed to work. DX12/Vulkan have precompiled pipeline state objects that include compiled shader binaries as part of the state. Ideally, you build (and serialize) these at installation/startup so you don't have to worry about those during runtime.

What's most interesting to me about the iPad Pro is that it (likely) will be the most popular consumer device pushing beyond 1440p (2048p = ~5.6 megapixels vs ~3.7 megapixels). Considering the dearth of 4K content out there, I wonder if this will start to push devs into making considerations for 4K, considering that this is over halfway to that resolution.

Ding ding ding. Meanwhile, the majority of this thread is complaining about user review quality on Amazon. Nice.

Powers at is a subdivision of ImgTec, so...your answer is PowerVR

For all the complaints of $599, consider the prices of graphics cards, gaming monitors, phones, (4K) TVs, and so on. With this price, they are targeting the alpha consumer, who (hopefully) will have a great experience, tell their friends and the world, and prepare the markets for the eventual mass market version that will be in the $200-$400 range. AAA devs were never going to participate in this first gen anyway (there was no way they'd recoup their dev resources, so why would they).

While I think the concern for content is a valid one, I think indies and non-gaming apps will come through with a few breakthrough experiences that will drive the first set of sales, paving the way for the AAAs.

On a technical level, sure, this is reasonable.

But when someone goes out to gamble/play DFS, they aren't looking to diversify their bets in order to minimize their chance to lose. The base use case is "Hey, I have a few bucks, I'd like to place a quick bet for kicks, and maybe I have a chance to beat some other like-minded folks". Before DFS, you'd just grab your buddies and make an impromptu bet, and that's that. The implicit expectation is that you're playing with other players like you. And that is precisely what the DFS advertisements promote: you are expanding your pool of for-fun players by orders of magnitude. I'm going to the site, kicking in a $20 every few weeks, for the entertainment and possibility of winning. I'm not going to make 20 $1 bets because that isn't...fun.

The disconnect comes from the fact that DFS pit you directly against top-ranked high-rollers, who are not just schmoes off the street. Sure I don't expect to win. But I also don't _expect_ to be playing top 25 players in the world who are playing with thousands of bets.

That issues is covered in depth by the article, but from the looks of your post, you just seemed to stop reading after the 'gambling addict' bit. The last paragraph covers this:

"At the start of the N.B.A. season, a couple of friends and I started a friendly league on DraftKings. Every night, we draft teams, watch the points accumulate and make fun of one another for our picks. On the first of each month, we pay one another what we owe. One of these friends creates N.B.A. player performance models. They help him escape the cynical demands of his job as a corporate lawyer. To date, I am down $350 to him.

“Yes, yes, yes,” Harber said when I told him about this league. “That’s how it’s supposed to be.” "

An open standard is not OSS, so using those terms here is pretty disingenuous. You might get AMD to release an open source driver. Not sure if they actually intend to release a real, performany driver, or just a launcher with hooks into an ICD

I expected this to be more of a story about actual onboarding interactions instead of a product pitch, though I certainly understand the motivation for the latter.

In every company I've started at, I try to surf through process documentation, or if there isn't any 'newbie' docs, then I keep a little live-blog of my experiences, with the idea that I can share those later. The cost of such a blog is minimal, and it helps the new hire recall parts of the process they might quickly lose track of. Additionally, with some editing work, the blog serves the greater purpose of: 1) Informing the team about the process 2) Preparing the next new-hire.

He calls out Renderdoc for picking out rendering internals in the third part of the series: http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...

You can poke around D3D11 and OGL games, though I haven't tried out the OGL functionality. Next-gen api support is coming as well.

If you've poked around other engines, either via debuggers or actual engine development, you actually run into a lot of the same concepts as far as piecing a frame together. The interesting parts come in the details of those sub-passes, which is what gets analyzed by the article author.