VKVG: Vulkan Vector Graphics With A Cairo-Like API

[dkasak]

Why C? Seriously we already have Cairo. One of the biggest problems in Linux land is tge willingness to embrace or even experiment with new tech

Ugh. From where I'm sitting, one of the "biggest problems" is the ratio of armchair experts to people actually coding *anything*. This project was done in C, because that's what the dev wanted to do. Where's your github page?

[Luke_Wolf]

How is this "one of the biggest problems in linux land". Have you ever written software? Language choice isn't such a big deal, but I can think of many benefits to writing this in C. Firstly, Vulkan itself uses the C calling conventions, so this requires no intermediate adapters (and the language conventions match the API conventions perfectly. Secondly, C compilers are mature, they generate fast and predictable code, and they are most likely to already be present on the development machines of whoever is using a library like this.

C99/C11 is not "PDP8 level tech", fundamentally very little about computers (especially CPUs) has changed since the PDP-7 (and the first real C compilers were actually for the PDP-11), and most available operating systems with Vulkan implementations are basically like UNIX in most important ways. Virtually nothing about the environment has changed, why should the language have to change if it is not constraining the solution?

Why C? Because it's good.

While wizard69 is usually talking out his ass (and largely is this time), and while you make a few valid arguments in favour of it being written in C (all of which surround it being the native language of the vulkan api), not all of them are, and you're basically otherwise wrong.

Language choice does matter a hell of a lot, All languages have particular properties associated with them, and while it's technically possible to simulate any other language in any Turing-Complete language it is a disingenuous idea to use this as a basis for any statement so lets just dismiss that notion before we start, because normal programmers aren't creating DSLs to deal with the problems of a language. Choosing the correct language has deep impacts on a project, the most obvious that comes to mind is the effect on code size. A language like C has a lot more boilerplate it has to deal with especially as it lacks a proper mechanism for generics (void pointers are cancer), but as well safety and ease of expression put huge fingerprints on your code. For example, could Mozilla have written Stylo in C? In theory? Yes. In practice? Absolutely not. Another example, in C# Linq can turn hundred line searches into 5 lines of declarative code. The only time where language choice doesn't matter is when you're working with a trivial program

As to your second point, I'm sorry what? The primary platform for Vulkan development is Microsoft Windows, Windows has crappy C support, and this idea that a C compiler is somehow in any way a baseline for Vulkan development is a bad joke. What rock have you been living under for the past 20 years? Visual Studio supports a multitude of languages, as do both GCC and LLVM, but more importantly this isn't the day of dial-up-internet connections the "What's on my machine" barrier to development hasn't been a problem for a long time, especially with developers, and especially a language like Rust where it's almost entirely self-contained for downloading.

Finally "Fundamentally little about computers has changed since the PDP-7" that's cute. Did they tell you that in your university class? Because it's wrong. Hilariously wrong. Vulkan only even exists at all because the environment changed. Drastically. What you're saying is basically the equivalent of saying that "Fundamentally very little has changed about human society since the Hellenistic period". Plenty has changed: Out of Order Execution, Memory Protection, RISC, SMP and CMT, w^x, SIMD instructions... you know just to name a few examples for that CPU you think hasn't fundamentally changed at all. And if you're thinking about responding with some variation of "But they can do the same things then that they can do now"... don't. That's like saying a Greek Theater Troupe in the Hellenistic Age was capable of all the same things that a modern movie company with massive render farms, and a huge staff are capable of. It's categorically untrue (especially when you consider that the PDP-7 was a 18-bit processor).

[computerquip]

Language choice does matter a hell of a lot, All languages have particular properties associated with them, and while it's technically possible to simulate any other language in any Turing-Complete language it is a disingenuous idea to use this as a basis for any statement so lets just dismiss that notion before we start, because normal programmers aren't creating DSLs to deal with the problems of a language. Choosing the correct language has deep impacts on a project, the most obvious that comes to mind is the effect on code size. A language like C has a lot more boilerplate it has to deal with especially as it lacks a proper mechanism for generics (void pointers are cancer), but as well safety and ease of expression put huge fingerprints on your code. For example, could Mozilla have written Stylo in C? In theory? Yes. In practice? Absolutely not. Another example, in C# Linq can turn hundred line searches into 5 lines of declarative code. The only time where language choice doesn't matter is when you're working with a trivial program

Language matters based on who's writing it. You don't hire a Javascript programmer to write C and frankly, you don't hire a C programmer to write Javascript, Rust, or C# for that matter, at least not while understanding there's a buffer area for learning. Your idea that code size matters here is a bit weird if not petty. I would take well-written and organized code that's verbose over convoluted, heavily abstract code that happens to have less lines any day of the week. The idea that you think void pointers are the only way to handle different types with duplicate code at compile time makes me a bit sad in that you probably don't write in C (at least, not for a very long time).

There should be no confusion that people who worked on Mozilla products wrote something using Rust, also a Mozilla product. Otherwise, the industry is booming with competent C/C++ developers that can produce better code than someone who just started using Rust because it's what's hip.

As to your second point, I'm sorry what? The primary platform for Vulkan development is Microsoft Windows, Windows has crappy C support, and this idea that a C compiler is somehow in any way a baseline for Vulkan development is a bad joke. What rock have you been living under for the past 20 years? Visual Studio supports a multitude of languages, as do both GCC and LLVM, but more importantly this isn't the day of dial-up-internet connections the "What's on my machine" barrier to development hasn't been a problem for a long time, especially with developers, and especially a language like Rust where it's almost entirely self-contained for downloading.

Vulkan targets virtually all platforms that has a relatively modern graphics processor. Where did you get the idea that Windows is the primary target platform, especially given Android, Linux, and even Nintendo all have a specification-conformant implementation? No response to the use of other languages, you should technically be able to use any language that uses the platform's standard calling convention (which is _stdcall on Windows, not _cdecl as someone else previously mentioned). This includes C++, Rust, Go, D, and probably an infinite number of other languages. A lot of people don't like C and that's fine. You can't pretend that it's obsolete though which is the vibe I'm getting here.

You're actually correct that Windows has crappy C support but that's actually slowly changing with the introduction of Clang for Windows, where you can use Clang as an alternative platform toolset in Visual Studio. Some major projects have already taken advantage of it, notably Chromium which now defaults to compilation with Clang for Windows. Depending on the project, there's also nothing wrong with writing code using C90 compliance which is what the msvc compiler actually claims to be conformant with.

Finally "Fundamentally little about computers has changed since the PDP-7" that's cute. Did they tell you that in your university class? Because it's wrong. Hilariously wrong. Vulkan only even exists at all because the environment changed. Drastically. What you're saying is basically the equivalent of saying that "Fundamentally very little has changed about human society since the Hellenistic period". Plenty has changed: Out of Order Execution, Memory Protection, RISC, SMP and CMT, w^x, SIMD instructions... you know just to name a few examples for that CPU you think hasn't fundamentally changed at all. And if you're thinking about responding with some variation of "But they can do the same things then that they can do now"... don't. That's like saying a Greek Theater Troupe in the Hellenistic Age was capable of all the same things that a modern movie company with massive render farms, and a huge staff are capable of. It's categorically untrue (especially when you consider that the PDP-7 was a 18-bit processor).

CPU at the hardware level has changed a bit (though I'm not too familiar with the details, hardware implementation has never been my thing). The interface to that hardware (in particular x86), has changed by means of mostly just extensions. Hell, you can still start your CPU in real-mode if you know how. As a matter of fact, you mention out of order execution but that was introduced in the early 90s. Ironically, there were vulnerabilities found in general hardware capabilities concerning out of order execution, which you may have heard of called Spectre and Meltdown which age back to those times because the architecture and interface is strikingly similar.

[Luke_Wolf]

Language matters based on who's writing it. You don't hire a Javascript programmer to write C and frankly, you don't hire a C programmer to write Javascript, Rust, or C# for that matter, at least not while understanding there's a buffer area for learning.

It's more than based on who's writing it. The idea that if you get a highly skilled enough programmer in C or some other particular language and they can write anything in a way equivalent to safer languages is asinine. Given infinite skill and time, sure... but I'm still waiting to see this mythical super-programmer, and the statistics don't bear the idea out. Meanwhile the compiler yelling at you more does make for better code, as long as it's not doing stupid shit like Java where it demanding you adhere to particular folder structures or it won't compile.

Your idea that code size matters here is a bit weird if not petty. I would take well-written and organized code that's verbose over convoluted, heavily abstract code that happens to have less lines any day of the week.

Oh I agree it's petty but it's the most concrete thing that can be reached for. Would you prefer I had waxed on about safety?

The idea that you think void pointers are the only way to handle types unknown at compile time makes me a bit sad in that you probably don't write in C (at least, not for a very long time).

If you know of something besides macros and void pointers, I'd like to know. I'm very not a fan of either. If I'm willing to use the C++ compiler I can use templates but... that's cheating isn't it?

There should be no confusion that people who worked on Mozilla products wrote something using Rust, also a Mozilla product. Otherwise, the industry is booming with competent C/C++ developers that can produce better code than someone who just started using Rust because it's what's hip.

And you think Mozilla whose primary "products" are mostly in C++ doesn't have competent programmers? The important thing about Stylo is not that it's a CSS engine, or that it's a fast one... what is important about Stylo is that it's an incredibly well threaded CSS engine which Rust enabled by yelling at them and calling them idiots whenever they did something that wouldn't be thread friendly. In C++ and heaven forbid C the compiler doesn't know any better, and I have to trust that the developers are fastidious enough to pull it off which isn't historically supported and is why multithreading is "hard". Hence I can wholeheartedly believe that it's not practical to implement in C++.

Vulkan targets virtually all platforms that has a relatively modern graphics processor. Where did you get the idea that Windows is the primary target platform, especially given Android, Linux, and even Nintendo all have a specification-conformant implementation? No response to the use of other languages, you should technically be able to use any language that uses the platform's standard calling convention (which is _stdcall on Windows, not _cdecl as someone else previously mentioned). This includes C++, Rust, Go, D, and probably an infinite number of other languages. A lot of people don't like C and that's fine. You can't pretend that it's obsolete though which is the vibe I'm getting here.

And the main target for games is?... That's right ladies and gentlemen: Microsoft Windows, followed closely by the Nintendo Switch, and then Android in terms of platform importance. Linux is taking a long distant place behind them.

Yes it's cross platform but the person I was quoting seemed to be putting a much greater importance on Linux in the Vulkan ecosystem than it really has.

You're actually correct that Windows has crappy C support but that's actually slowly changing with the introduction of Clang for Windows, where you can use Clang as an alternative platform toolset in Visual Studio. Some major projects have already taken advantage of it, notably Chromium which now defaults to compilation with Clang for Windows. Depending on the project, there's also nothing wrong with writing code using C90 compliance which is what the msvc compiler actually claims to be conformant with.

And good on them, Epic does the same thing. You need LLVM-Clang to compile. I'd love to see Microsoft drop their shitty compiler and replace it with Clang.

CPU at the hardware level has changed a bit (though I'm not too familiar with the details, hardware implementation has never been my thing). The interface to that hardware (in particular x86), has changed by means of mostly just extensions. Hell, you can still start your CPU in real-mode if you know how. As a matter of fact, you mention out of order execution but that was introduced in the early 90s. Ironically, there were vulnerabilities found in general hardware capabilities concerning out of order execution, which you may have heard of called Spectre and Meltdown which age back to those times because the architecture and interface is strikingly similar.

The PDP-7 that he was referring to was produced in 1964. It's not just a little bit that's changed since the 1960s it's a lot that's changed since then. How memory was laid out wasn't even settled until the VAX which was released in 1977 (around the same time the 8086 showed up). It's like comparing a Ford Model T to a modern car and saying "Here's the steering wheel there's the gas pedal, don't you see? Nothings much changed since then" The reality is quite different.

[Guest]

Then why didn't he just work on adding a Vulkan back-end to Cairo? Isn't that the point of OSS?

Not really. The point is he can look at Cairo's code and get inspiration. Nothing forces him to contribute to an existing project.

[microcode]

(especially when you consider that the PDP-7 was a 18-bit processor).

What does the addressing size have to do with the language? Why are you still talking about the PDP-7, even though C has nothing to do with the PDP-7? Why would any of these ISA extensions and microarchitectural changes, with no change to the actual programming model of the machine, warrant a new language for a task the extensions don't even apply to? What benefit would any other language confer to the author, who praises Cairo and hopes this work will be integrated or built off of in the upstream?

Why should anyone trust what you have to say about anything when you can't even reliably differentiate between the PDP-8, the PDP-7, and the PDP-11?

You're an amateur, stop spouting this nonsense, it is misleading to your fellow amateurs and it makes everyone cringe. There is nothing wrong with being an amateur, but if you're an amateur and an arrogant jerk at the same time, you're not doing anyone any good.

Life is better when you don't spend it all bloviating.

[Luke_Wolf]

What does the addressing size have to do with the language? Why are you still talking about the PDP-7, even though C has nothing to do with the PDP-7? Why would any of these ISA extensions and microarchitectural changes, with no change to the actual programming model of the machine, warrant a new language for a task the extensions don't even apply to? What benefit would any other language confer to the author, who praises Cairo and hopes this work will be integrated or built off of in the upstream?

Why should anyone trust what you have to say about anything when you can't even reliably differentiate between the PDP-8, the PDP-7, and the PDP-11?

You're an amateur, stop spouting this nonsense, it is misleading to your fellow amateurs and it makes everyone cringe. There is nothing wrong with being an amateur, but if you're an amateur and an arrogant jerk at the same time, you're not doing anyone any good.

Life is better when you don't spend it all bloviating.

Why should I trust the words of someone who thinks that CPUs haven't fundamentally changed since 1964? Especially someone who would claim that they have no impact on the programming model of the machine.... when Protip: They do, immensely. C doesn't hide away the fact that you used to be able to arbitrarily access memory for example because it was all a single address space with no protection, but now if you're lucky you'll trip the MMU and get a segfault. SMP is a programming model we're still trying to figure out how to properly cope with, which is the big point of Rust and something it fundamentally does a good job of solving, etc etc etc...

Also nice projection on the amateur bit.

[microcode]

...Protip: They do, immensely. C doesn't hide away the fact that you used to be able to arbitrarily access memory for example because it was all a single address space with no protection, but now if you're lucky you'll trip the MMU and get a segfault....

The PDP-11, the first computer C was implemented for, had paged virtual addressing and a separate execution mode for the kernel and userspace processes; and I believe the model they used had memory protection (MX11).

If you can use Phoronix.com, you can probably also use Google; I encourage you to google things before you continue making a fool of yourself over and over.