Vulkan 1.1.130 Released With New Tooling Extension

[phoronix]

Phoronix: Vulkan 1.1.130 Released With New Tooling Extension

Vulkan 1.1.130 is out today as the newest update to this graphics API that fixes a wide variety of documentation issues and areas in need of clarifications while also introducing a new extension...

http://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.1.130-Released

[ssokolow]

How much you wanna bet some idiot developer will think that it will somehow slow piracy if they use this API to try to prevent release builds from running while any kind of debugging tool is announcing its presence?

[Guest]

How much you wanna bet some idiot developer will think that it will somehow slow piracy if they use this API to try to prevent release builds from running while any kind of debugging tool is announcing its presence?

It will happen for sure. It's just a question of how many do it.

[starshipeleven]

How much you wanna bet some idiot developer will think that it will somehow slow piracy if they use this API to try to prevent release builds from running while any kind of debugging tool is announcing its presence?

It's harmless, let them dream.

[arQon]

It will happen for sure. It's just a question of how many do it.

jep, guaranteed. sigh. (It won't be an idiot developer though: it'll be his idiot manager after the developer thoughtlessly mentions it to him).

starshipeleven - that's why it's not harmless. There's no genuine value to this extension at all that I can think of: no developer has EVER wanted or needed this capability, and the only purpose it will ever serve is to have it be perverted into something harmful. (c.f. "extended browser capabilities" that are only ever used to improve fingerprinting).

[starshipeleven]

the only purpose it will ever serve is to have it be perverted into something harmless that gives some false beliefs of safety to some businnes-types.

fixed.

Really, if stuff like this is enough to make the businness-types feel safe it might even decrease the usage of intrusive DRM, which is NOT harmless.

[ssokolow]

jep, guaranteed. sigh. (It won't be an idiot developer though: it'll be his idiot manager after the developer thoughtlessly mentions it to him).

starshipeleven - that's why it's not harmless. There's no genuine value to this extension at all that I can think of: no developer has EVER wanted or needed this capability, and the only purpose it will ever serve is to have it be perverted into something harmful. (c.f. "extended browser capabilities" that are only ever used to improve fingerprinting).

I imagine the original intended purpose was some kind of "make the release build able to switch into some kind of limited debug mode when a debugger attaches" functionality.

[arQon]

Really, if stuff like this is enough to make the businness-types feel safe it might even decrease the usage of intrusive DRM, which is NOT harmless.

ah, okay - I see what you were trying to say in your earlier post now.
While I admire your optimism and would like to share it, I don't see it playing out that way at all in practice. Inspecting the renderer is so divorced from breaking the DRM that there's no relationship between the two at all. You'd have to try pretty hard to convince the business side that reacting to this is "protection" in ANY way, let alone protection against copying. Still, you never know.

ssokolow - Yes. But the point is, that's an absolutely BS concept in the first place. Development doesn't work that way. For the supposed "useful" scenario you're already going to be running in the debugger in the first place, with conditional breakpoints already determined and in place. For every other scenario, i.e. post-release, the only thing you're ever going do with this stupid, pointless, utterly valueless extension, is - at best - disable the entire rendering pass entirely if this is non-empty.

[ssokolow]

ssokolow - Yes. But the point is, that's an absolutely BS concept in the first place. Development doesn't work that way. For the supposed "useful" scenario you're already going to be running in the debugger in the first place, with conditional breakpoints already determined and in place. For every other scenario, i.e. post-release, the only thing you're ever going do with this stupid, pointless, utterly valueless extension, is - at best - disable the entire rendering pass entirely if this is non-empty.

Oh, no argument there. IMHO, all potential uses of this extension are much more simply accomplished by implementing some kind of hidden --debug flag that the release binary can be launched with.

(If someone responsible for this extension is lurking in here, feel free to try to change my mind.)

[starshipeleven]

(If someone responsible for this extension is lurking in here, feel free to try to change my mind.)

They seem to be convinced that

When an error occurs during application development, a common question is "What tools are actually running right now?" This extension adds the ability to query that information directly from the Vulkan implementation.

...

Typically, the expectation is that developers will simply print out this information for visual inspection when an issue occurs, however a small
amount of semantic information about what the tool is doing is provided to help identify it programmatically.
For example, if the advertised limits or features of an implementation are unexpected, is there a tool active which modifies these limits? Or if an application is providing debug markers, but the implementation is not actually doing anything with that information, this can quickly point that out.


see here the official description.
https://github.com/KhronosGroup/Vulk...oling_info.txt

I quite frankly don't know either way. It just seems to be garbage as an antipiracy measure so I doubt this is a "stealth DRM" thing.