Vulkan doc has various chapters as well about devices and queues, and synchronization: https://www.khronos.org/registry/vulkan/specs/1.0/pdf/vkspec.pdf [External Link]

But they avoid details about practical usage and threading in regards to that. I suppose some higher level articles should dive into that.

View this comment - View article - View full comments

I saw this topic mentioned in the Mantle document: https://www.amd.com/Documents/Mantle-Programming-Guide-and-API-Reference.pdf [External Link]

Search for "GPU queue" there. Synchronization is also covered there with queue semaphores. So I assume Vulkan should have an analog of the same idea.

I can't find it now, but I saw someone asking similar question in one of the Khronos Q&A, and they said Vulkan should support multiple parallel GPU queues.

View this comment - View article - View full comments

Actual submission of commands to the GPU is still done sequentially, in a single thread, however there’s very little overhead; all error checking has been done

Is that true? From what I've read, modern GPUs support multiple queues for input (some for graphics, some for compute). I'm not sure what GPU is supposed to do with multiple queues for graphics for example, since in the end, rendered image is a single frame, but if they exist, it means it should be possible to feed them from multiple threads (one thread per GPU input queue). And Vulkan should support that.

Also, it's possible to have multiple GPUs working in parallel (Vulkan aims to support that), to increase computational power. You for sure don't want to have one thread feeding such hardware setup - it's going to be underutilized.

View this comment - View article - View full comments

I just see, "image", "image", etc. I guess something didn't go through.

UPDATE: I see it now :)

View this comment - View article - View full comments

Quoting: KimyrielleUnfortunately, that's true. Of the 3,000 games, roughly 2,500 suck very extremely hard. Indie development has brought us gems like Prison Architect and Stardew Valley. But also a lot of people who can barely code Hello World suddenly thought they could be the next game development star and published their drivel on Steam because nobody stopped them. That's actually a huge problem these days, because it's getting harder and harder to find the few good games in the mountain of drivel.

There is GOG for that. I regularly check their release announcements. I don't buy all games that they release, but I buy most of them (I mean ones that come out for Linux). And they are good as a rule.

I suppose Steam is becoming more like itch.io, with barely any filtering of what's submitted. There is some benefit in that too (GOG filtering can prevent some good games occasionally from coming out there). But the downside is of course a huge noise of various irrelevant stuff.

View this comment - View article - View full comments

I bought Owlboy not long ago, and I'm still in the middle of the game.

View this comment - View article - View full comments

Well, there are good binary patching tools as well, I think one of the inXile Linux developers event wrote an interesting overview of this topic. So it's not like GOG or anyone else need to reinvent the wheel. They just need to iron out the expected way for developers to do it. Kind of strange that this is so hard.

View this comment - View article - View full comments

Quoting: liamdaweFinances: They split their possible purchases across more stores, if they don't hit the payout threshold on GOG they won't get paid, but if they stick to one store they are more likely to get their money.

Are you saying that GOG have a threshold of sales they require, before starting paying anything to developers? That's the first time I hear such thing. I thought they simply pay percentage of every sale. On the other hand, I don't think games of Croteam are in danger of underselling. They are quite good and popular in general. Way less known studios and games are selling through GOG, and apparently have no such issue.

Quoting: liamdaweTime: They have to do support across another place, think what you want, but that alone will suck up a fair amount of time.

That's probably related to the above, but again, GOG isn't tiny, so they can compensate their support efforts with more profits. And again, less known games and smaller studios do it apparently successfully.

Quoting: liamdaweGOG tools: I've heard from a number of people that GOG's upload tools aren't great and they don't allow different versions like Steam do. There is a reason so many actively choose to use Steam for their builds as it's easy to manage lots of different versions, especially when in development or generally updating titles.

I'm not sure about different versions (I suppose GOG only offer the latest one, or some version + patches to latest one in some cases), but I don't really understand the trouble with upload. GOG accept some tarball from developers, and they themselves (i.e. GOG) already package and put it out. What's hard with having some rsync set up between GOG servers and developers? It should be a no brainer, there are tons of solid and production proven upload / sync tools out there. I'd like some comments from GOG about why this can be a sore point.

View this comment - View article - View full comments

Quoting: STiAT@silmeth croteam talked about exactltly this some time ago. And everyone who follows croteam and the approach they prefer (do-it-yourself-and-do-it-right) - I give my bet on that they've written their own optimizer by now.

Why would they all reinvent the wheel, instead of let's say improving glslang?

View this comment - View article - View full comments

Nice, but when are they going to release their games on GOG? They aren't some legacy publisher, so what's stopping them?

View this comment - View article - View full comments