New Vulkan Extension Proposed For DirectFB Support

[phoronix]

Phoronix: New Vulkan Extension Proposed For DirectFB Support

The DirectFB library once popular with embedded systems and other environments needing formerly a full X11 stack (or now, Wayland) remains in an abandoned state with no real upstream development any longer and the project site long dead, but with a newly proposed Vulkan extension could allow this modern graphics API to run on top of it...

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

[ddriver]

This seems backwards. If Vulkan runs on top of DirectFB, then the latter should facilitate the former, not the other way around.

The code that is needed to run vk on top of dfb should be part of dfb, there is no need to bloat vk on the off chance someone decides to use dfb.

Imagine a power plug, which you had to open and tinker with to introduce changes for each and every different new appliance you decide to plug into it.

I've seen this pattern in poorly designed software many times, it leads to pointless complexity and increases the potential for bugs.

[xxmitsu]

This seems backwards. If Vulkan runs on top of DirectFB, then the latter should facilitate the former, not the other way around.

The code that is needed to run vk on top of dfb should be part of dfb, there is no need to bloat vk on the off chance someone decides to use dfb.

Imagine a power plug, which you had to open and tinker with to introduce changes for each and every different new appliance you decide to plug into it.

I've seen this pattern in poorly designed software many times, it leads to pointless complexity and increases the potential for bugs.

Go ahead and provide this feedback to the author, on the linked github issue from this article. And see how that goes.

[loganj]

so the author wants a vulkan extension for something that is dead for a long time now? Frankenstein

[xeekei]

This seems backwards. If Vulkan runs on top of DirectFB, then the latter should facilitate the former, not the other way around.

The code that is needed to run vk on top of dfb should be part of dfb, there is no need to bloat vk on the off chance someone decides to use dfb.

Imagine a power plug, which you had to open and tinker with to introduce changes for each and every different new appliance you decide to plug into it.

I've seen this pattern in poorly designed software many times, it leads to pointless complexity and increases the potential for bugs.

Are Vulkan "extensions" a permenant part of Vulkan? Or would it be something modular? Graphics stuff, while cool, is a bit outside my area.

[DadSchoorse]

This seems backwards. If Vulkan runs on top of DirectFB, then the latter should facilitate the former, not the other way around.

The code that is needed to run vk on top of dfb should be part of dfb, there is no need to bloat vk on the off chance someone decides to use dfb.

Imagine a power plug, which you had to open and tinker with to introduce changes for each and every different new appliance you decide to plug into it.

I've seen this pattern in poorly designed software many times, it leads to pointless complexity and increases the potential for bugs.

Well, core vulkan by itself does not interact with any display server or anything like that. You can use it without a window and create a Vulkan instance only through interacion with the loader. This is very different from opengl for example, where you need to use a platform specific mechanism to create a opengl context. Instead, Vulkan tells you through the vulkan loader which surface extensions are avaiable and you can activate those extension you want (or none). Then you create a window with the respective platform api and call one vulkan function to get a VkSurfaceKHR object, which is then used to create everything you need to display images. While the vulkan way isn't perfect and I would say that the Window Subsystem Integration part is the worst part of vulkan, it's way better than every other cross platform api handles things. At the end of the day the driver still needs to interact with the platform mechanism, but only if they choose to implement this extension. So what you are recommending isn't possible in practice, at least nobody created an api that does this better.

The proposed extension is 100% the way to go if you want to add a new display platform to vulkan.

[milkylainen]

This seems backwards. If Vulkan runs on top of DirectFB, then the latter should facilitate the former, not the other way around.

The code that is needed to run vk on top of dfb should be part of dfb, there is no need to bloat vk on the off chance someone decides to use dfb.

Imagine a power plug, which you had to open and tinker with to introduce changes for each and every different new appliance you decide to plug into it.

I've seen this pattern in poorly designed software many times, it leads to pointless complexity and increases the potential for bugs.

Why the hell not? Just because you can't see a win?
Every code and every application is not "new and shiny", especially in the embedded world.
I absolutely see legitimate use of running Vulkan on something very small, like DirectFB.
I also cannot grasp how you translate cross-generation display functions with "bad design".
If anything, code working over generations is well designed code.

I for one absolutely hate when "I R shiny" come every third year and "Yeah. You have to redesign everything because we do like this now and everybody else is stupid."

[ddriver]

Go ahead and provide this feedback to the author, on the linked github issue from this article. And see how that goes.

No thanks, if professional experience has taught me anything, it is to not waste energy on people, stuck in their ways.

This is classic "legacy programming" mental deformity of people who had to work against some shortsighted, outdated and outright lousy software architecture, and as a result, developed it as standard practice.

Surprisingly popular, even and especially in huge billion dollar revenue companies, it is by far the largest contributor to code bloat, bugs and wasted developer hours. It is remnant of the olden days of computing of oddities, particularities and incompatibilities and has no place in a context of modern universal and open APIs.

What's funny is this passes for "modular architecture" even tho it is so anti-modular it is only second to a literal wall of code...

VK is a low level GPU programming API, it provides standard routines to input and output data and that should be it. It should be up to the data consumer to retrieve and use it accordingly. There shouldn't be a need for a dedicated VK extension to spoon-feed each and every use case.

[skeevy420]

VK is a low level GPU programming API, it provides standard routines to input and output data and that should be it. It should be up to the data consumer to retrieve and use it accordingly. There shouldn't be a need for a dedicated VK extension to spoon-feed each and every use case.

So instead of a dedicated VK extension they'll have to reinvent the wheel with every program they write?

[ddriver]

So instead of a dedicated VK extension they'll have to reinvent the wheel with every program they write?

Why? The GPU gives you back a buffer of memory with the result, and you do with it what you will. What wheel reinventing? And it is not on a per-program basis, it is on a per-platform basis. And yes, I can see quite a lot of use in having the flexibility to intercept and process raw data in the way you want rather than having to settle for something that happened to work for someone else.

If anything, code working over generations is well designed code.

Yeah, living in caves worked over many, many generations. So, go live in a cave, won't you?