Spinning up a separate thread @Kartik Agaram said in https://futureofcoding.slack.com/archives/C5T9GPWFL/p1585680051053200?thread_ts=1585420887.013400&cid=C5T9GPWFL:

Please build your prototypes atop Mu!

I have no idea how to do graphics or sound. But a forcing function would be helpful.

All that I need for a basic implementation of Hest's renderer is something like: the ability to draw stroked straight lines, filled rectangles and circles, and the most basic text (bitmap font) at arbitrary sizes and positions... with a few thousand drawing operations of various sorts happening in less than 3ms.

If you want to draw such shapes at good quality, I can recommend the nanovg library; you just need an opengl render target and can draw high quality images.

@Ivan Reese can you elaborate on what you mean by "stroked straight line"?

@Kartik Agaram See here https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Fills_and_Strokes

Yeah, the "line" or "path" refers to the geometry, and the "stroke" is how it is rendered. When stroking a line, you generally want control over the stroke thickness and color at a minimum. Lots of features beyond that, but that's the basics.

Nanovg requires OpenGL. Doesn't that conflict with the "no dependencies" requirement of the Mu project? If the goal is to be able to program all the way down to the bare metal, then I think you would want to standardize on a single GPU architecture, and program it directly. Just as you have standardized on x86. Or don't support a GPU, and instead interface directly to a frame buffer.

Yeah, my current plan is to focus on just a frame buffer. Mu currently can boot up a disk image with the hobbyist OS Soso (https://github.com/ozkl/soso) in addition to Linux. Soso is much tinier so reduces my dependency on C. It's also graphical from the ground up, where I haven't really managed to compile a Linux kernel with graphics yet. On the other hand it doesn't have a network stack... I interpreted the nanovg suggestion as something to crib from, and it's extremely useful in that respect. Even though I minimize dependencies I don't want to rethink everything from scratch. (For example, Mu's support for bootable disk images comes from digging into and cribbing from the Minimal Linux project at http://minimal.linux-bg.org.) Regardless of dependencies, tiny projects that can teach how something works are gold.

The https://libre-soc.org/ project aims to produce an open source CPU + GPU. The GPU is integrated with the CPU: it's just an extension to the instruction set architecture, rather than being a coprocessor. This means that programming this GPU on the bare metal will be orders of magnitude simpler than a typical GPU. Hypothetically, when the project is finally finished and the hardware is available, it would be a good platform for a program-on-the-bare-metal type of software project.

The advantage of GL is that it is pretty much available everywhere. As you say, Vulkan is difficult for beginners (and advanced users 🙂 ).

I am using OpenGL right now for my project. My problem is that I want to be cross-platform, and Apple has officially deprecated OpenGL, and they also do not support OpenGL 4.3, which has features I need. The MacOS and WebAssembly platforms are the reasons why I will migrate to WebGPU. OpenGL is still a great cross-platform solution if you don't need access to features introduced in the last 10 years, like compute shaders.

Yeah, for original poster’s question, he just needs basic GL. I didn’t realise WebGPU would work native on desktop - if there’s a C API it’s more interesting... my live coding tool has GL/DX 12 and Vulkan backends in various levels of completion!

@Chris Maughan both those repos are excellent, thank you. However they're not actually writing to the framebuffer, are they? Maybe I'm missing something. Just to give some context, the problem I wrestle with for graphics is how to make something that: a) can display on a real machine with minimal dependencies, and b) can also display on a stock *nix or Mac machine without needing root permissions and so on. To help you triangulate, my non-graphics programs in Mu can currently run on Linux and also on a much simpler OS using either Qemu or native hardware. This is easy because we don't typically need root to access stdin/stdout/tty the way we need it for framebuffer access. Once I can display a single pixel within these criteria, your repos become very relevant.

@Chris Maughan The WebGPU C implementations are wgpu (https://github.com/gfx-rs/wgpu) and dawn (https://dawn.googlesource.com/dawn/). Both implementations use the same C header file (https://github.com/webgpu-native/webgpu-headers/blob/master/webgpu.h). For now, these prototype implementations ingest SPIR-V as the shader language. Later they will change to ingest WebGPU Shader Language (WGSL), which is text based and isomorphic to SPIR-V, but that is still in an early stage of design.

It occurs to me that I just need a framebuffer emulator analogous to text-mode terminal emulators. And look, someone else had the same idea: https://sixpak.org/fbe @Doug Moen it's totally an option to have different code paths for running on native hardware vs a host OS. For example, here are the syscalls I use for two different OSs: https://github.com/akkartik/mu/blob/master/init.linux and https://github.com/akkartik/mu/blob/master/init.soso. In combination with fbe, I could maybe have separate init.linux and init.qemu or something like that, where the ioctls expand to nothing and the address of `mmap`d memory changes.

Yes, I was describing my implementation of a framebuffer emulator.

@Kartik Agaram sounds like you are on the right track.... I had thought you earlier mentioned you had some kind of framebuffer already - hence the software rasterizer. To me, a framebuffer is a GPU memory surface that gets copied to the screen - I work for NVIDIA, so I have hardware bias 😉. The approach of using a memory buffer then copying it to the screen using an OS specific path, as @Doug Moen suggests sounds good to me 🙂 OpenGL remains the best supported way to do that on any platform. Any version of it will be able to take a memory surface and copy it to the display, and it is still the first graphics API that most platforms support. There are other ways to get a framebuffer that would work without creating an OpenGL context though. My easy render repo has a really simple example of displaying memory pixels on the display in windows. There are probably similar ways to do such things on other OS. There may even be a cross platform header library that will accomplish the same thing: https://github.com/cmaughan/easyrender/blob/master/src/devices/windows/device.cpp

sixpak.org/fbe contains a loop that runs every millisecond and copies the framebuffer into a X pixmap using XSetPixel(). Although this code contains optimizations, I would still choose to write a framebuffer emulator in OpenGL, updating once per frame instead of once per millisecond. I think efficiency and power consumption could be an issue. (I still have work to do in Curv to prevent laptops from heating up and turning on their fan unnecessarily, which is why I'm sensitive to this issue.)

Btw there is at least one software rasterizes version of nanovg

The philosophy of Mu is to interrogate abstractions. Definitely willing to consider this!