You all jest, but I'd kill for curated tags on HN. There's a lot of content here I don't really care about and it's steadily growing larger. Nothing wrong with the site, just personal preferences.
I wouldn't hand-curate the tags, but parsing a well-commented HN discussion, or the fine article under discussion, might lead to hints. For instance, given a Title term "Matrix", one might parse for "movie", "mathematics", "transformation", "neo", "algebra", "agent smith" and discover to which tag "matrix-movie" or "matrix-math" the discussion should be assigned.
Adding a UI that presents the tags in the Algolia search might be the difficult-to-get-right part.
I guess classification via combination of article and comments shouldn't be too hard (at least in my imagination). I would like to subscribe to tag-based RSS feeds then, ideally.
This wasn't about Win32 SECURITY_DESCRIPTOR s? I thought not. Though, Win32 security is indeed hard, and I'm diving into assembling and debugging security descriptor ACLs right now...
There was a lot of unusual things back then; now I think memory is flat so your stack address 1234 is the same as your code and data address 1234 (the exception being thread-local variables).
I still have a moment when I think of all the "hey look we have shaders!" games released in the early xbox 360 era when I hear the phrase "bloom filter"
The breakdown of what resource binding methods exist in the wild, and the table of what binding methods are used by which GPU vendors is great! First time I've seen this all in one place.
This explains a lot of the difficulties the Vulkan designers had to deal with in order to cover all popular GPU architectures. It also means that Vulkan isn't actually as low level and explicit as initially thought, it still has to abstract over very different hardware (I guess the dream that GPUs will eventually converge to a unified 'modern' architecture is dead?).
Vulkan sits in an awkward place sandwiched between slightly less explicit but more straightforward and convenient APIs like Metal, and GPU-specific (but also more straightforward and convenient) APIs on the game consoles.
I hope that the current wave of constructive criticism of the Vulkan API can lead to a Vulkan 2 which addresses those concerns (there are some interesting extensions in the pipeline like VK_KHR_dynamic_rendering which make parts of the API more flexible and convenient to use, however at the cost of not supporting all GPU vendors - e.g. there's a desktop/mobile split).
What I see, is Khronos kind of repeating the same errors from design by comittee API as OpenGL falled into, with extension spaghetti, make your own adventure SDK style, and thankfully they got Mantle as starting point, otherwise probably they would still be arguing how the API should look like.
The make your own adventure SDK isn't as bad as on OpenGL heyday, because at least this time we have LunarG on board, trying to make it less painful.
Still it isn't the same as having Metal Kit, DirectXTK, PhyreEngine,... in the box with "File new template" for newcomers.
I mean, the future looks something like SM6.6 bindless imo. The allure is just too great otherwise. If we can get SM6.6 bindless but make it efficient and usable, that saves so much. Something like the PS4 SRT model would be even better.
The big failure was constant uploading IMO, turns out you really want to use the buffer versioning hardware unit on devices, but that's such an awkward fit for descriptor sets. A lot of frameworks (including sokol, and my own) buffer UBO data into a giant single buffer, upload once at the start of the frame, and use dynamic UBOs to offset per draw. That's great on AMD, but could be better on other devices. A way to use that buffer unit would be better. Push constants ain't it. All drivers have heuristics now, but they aren't perfect.
19 comments
[ 2.8 ms ] story [ 48.7 ms ] thread[1] https://stackoverflow.com/questions/36625892/descriptor-conc...
Adding a UI that presents the tags in the Algolia search might be the difficult-to-get-right part.
There was a lot of unusual things back then; now I think memory is flat so your stack address 1234 is the same as your code and data address 1234 (the exception being thread-local variables).
This explains a lot of the difficulties the Vulkan designers had to deal with in order to cover all popular GPU architectures. It also means that Vulkan isn't actually as low level and explicit as initially thought, it still has to abstract over very different hardware (I guess the dream that GPUs will eventually converge to a unified 'modern' architecture is dead?).
Vulkan sits in an awkward place sandwiched between slightly less explicit but more straightforward and convenient APIs like Metal, and GPU-specific (but also more straightforward and convenient) APIs on the game consoles.
I hope that the current wave of constructive criticism of the Vulkan API can lead to a Vulkan 2 which addresses those concerns (there are some interesting extensions in the pipeline like VK_KHR_dynamic_rendering which make parts of the API more flexible and convenient to use, however at the cost of not supporting all GPU vendors - e.g. there's a desktop/mobile split).
Anyway, interesting times :)
The make your own adventure SDK isn't as bad as on OpenGL heyday, because at least this time we have LunarG on board, trying to make it less painful.
Still it isn't the same as having Metal Kit, DirectXTK, PhyreEngine,... in the box with "File new template" for newcomers.
The big failure was constant uploading IMO, turns out you really want to use the buffer versioning hardware unit on devices, but that's such an awkward fit for descriptor sets. A lot of frameworks (including sokol, and my own) buffer UBO data into a giant single buffer, upload once at the start of the frame, and use dynamic UBOs to offset per draw. That's great on AMD, but could be better on other devices. A way to use that buffer unit would be better. Push constants ain't it. All drivers have heuristics now, but they aren't perfect.