fayalalebrun

Apparently Voodoo cards defaulted to 1.3 gamma instead of the standard 2.2. I wonder why that is, since it theory using a non-standard gamma would just reduce your color range with no real benefit.

This is definitely fixable in the design though by looking at the DAC gamma register. I'll do so once I get to the scan-out implementation on the DE-10 Nano.

This fits and runs in a DE-10 Nano without too much difficulty, uses around 70% of the fabric. I've been working on timing closure and just got it to 50 MHz.

Note that I also implemented cache components not present in the original Voodoo in order to be more flexible in terms of the memory that can be used. So it could be quite a bit smaller, maybe 50% of the fabric if you got rid of that.

You do have a nice point here. Then the compute unit can simply stall the commands coming out of the register bank. Without this I need to stall the write FIFO, which feels less elegant and has given me some pain in terms of combinational loops. The drawback though is that you have to duplicate a significant amount of registers in the compute unit.

Thank you! These things do pack in a ridiculous amount of functionality for what they do. Probably why they look so good but also why it took 30 years for a hardware re-implementation.

Maybe I'm misunderstanding, but that functionality is implemented in another component. The register bank only records the category of each register and implements the memory-mapped register functionality.

This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.

SpinalHDL did not fork from Chisel. You might be able to say that it was inspired by Chisel, but it does not share a commit history. See this comment by the author: https://www.reddit.com/r/chisel/comments/4ivevd/comment/d3lj...

My favorite dithering algorithm for motion video is Yliluoma dithering: https://bisqwit.iki.fi/story/howto/dither/jy/

It is especially useful for grayscale content, as finding the optimal dithering matrix from the available palette is a straightforward exact operation, and the result can be placed in a LUT for real-time rendering.

In my opinion it looks much better than bayer or random dithering, especially on gradients.

Do you have any other examples where systolic arrays are suitable other than matrix multiplication? As far as I am aware, other problems require different systolic architectures. So I am curious whether you are talking about a general purpose architecture.

As a result of a flaw in the protocol itself or in its implementation?

This is a common misconception, but is not the case. For example, look at the Voodoo 1, 2, and 3, which also used fixed point numbers internally but did not suffer from this problem.

The real issue is that the PS1 has no subpixel precision. In other words, it will round a triangle coordinates to the nearest integers.

Likely the reason why they did this is because then you can completely avoid any division and multiplication hardware, with integer start and end coordinates line rasterization can be done completely with addition and comparisons.

A few years ago a friend and I made something similar to universe sandbox, though only with the gravitational simulation part: https://github.com/fayalalebrun/Astraria

Surprisingly enough the jar still runs without issue. Something which probably would not be the case for linux binaries, but maybe for windows.

Even though the newest nvidia drivers have started to support GBM, the Wayland compatibility story is still not great. In my experience on Wayland, several OpenGL programs refuse to work, and Vulkan does not work at all. This is with driver 545.

I probably don't have nearly as much experience as you do, but I have used VHDL, Verilog, and modern HDLs like Chisel and SpinalHDL. I think the main advantage of a modern HDL is to have the full power of a traditional programming language when it comes to generating hardware. This especially helps when making deeply parameterizable and reusable hardware in a fraction of the lines compared to SystemVerilog, and which sometimes is impossible to do in Verilog.

From a first impression, your language doesn't look all that different from SystemVerilog. Does it have any features that make parameterization easier than SystemVerilog? Can I, for example, easily generate hardware using higher order functions and other functional programming features like those available in Rust and Scala?

Chisel does emit FIRRTL. Which can be made into a bitstream directly by Yosys.

Perhaps already possible via MoltenVK -> Vulkan -> Zink?

I am surprised no one has yet tried to make a portable shell for the DE-10 Nano (Mister-FPGA's target platform). With a power usage of 10 watts, I think it should be quite feasible even with the addition of a small LCD panel. However, it would probably require re-engineering some of the standard addon boards for the form factor.

What about the actual FPGA specs? Is it more power efficient per LUT? A newer generation or the same generation but a smaller chip?

I am curious, in what ways is WebGPU better than Vulkan or Metal? From my point of view, WebGPU going back to an interpreted shading language like OpenGL makes it conceptually closer to JavaScript than WebAssembly.

With FPGA, unlike with GPUs, you can achieve significant speedup of algorithms where parallelization is very difficult. This is thanks to a technique called pipelining, where you can perform several steps of a sequential computation at the same time.

An example of this is video decoding/encoding, which is commonly implemented by dedicated hardware.

Last time I tried the 535 driver, GPU copies from XWayland and Wayland were broken, as well as Vulkan in Wayland. Pretty much the only thing which works are GL applications in Wayland. I found that both of these had been previously reported by other issues: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1444 https://github.com/NVIDIA/egl-wayland/issues/72

I'm curious what kind of workloads you were running that you have had no issues. I wouldn't expect XWayland to have worked at all before Nvidia added GBM support.

Yes, this is indeed a replacement for the proprietary driver. However, Vulkan 1.0 is the most basic version of Vulkan. Right now we are at 1.3, plus there are many Vulkan extensions which need to be implemented aside from the core version.

In other words, this is a good start, but with only Vulkan 1.0 you won't be able to use something like DXVK, for running DirectX games with Proton/Wine.

Yes, desktop applications need to implement the Wayland protocol in the same way they need to implement the X protocol. There is a compatibility layer called XWayland which allows you to run Xorg programs under Wayland.

However, running programs under XWayland comes with issues such as lack of proper fractional scaling. This means that although not strictly necessary, from a user's point of view it is desirable to have applications move to Wayland.

If you play with a delay, then why would you need any more storage than what is required to play a single video?

Personally I would not pay any amount to Google, as I believe it is unethical to support such a company. Google has a monopoly in several markets, to the point of being an unavoidable part of our lives.

No single company should have that much power. Especially since due to its nature as a for-profit corporation, Google's interests are at odds with yours.

It almost works on Linux with Wine. The text fields are messed up though.

However, I do not know why you would use this considering the alternatives available. It is closed source, no GraphQL support, and has cloud "features". The only pro for me is low RAM use.

Linux has ~/.local, ~/.config, and ~/.cache for user-specific program files. Sadly many programs don't respect these and pollute your home directory instead.

Of course. First of all they did not open source any existing driver. They released an open source kernel driver, which is separate from their existing closed source kernel driver. They still have not released an open source userspace driver.

These models work on a "latent" representation of the image, instead of working on the pixels directly. The model essentially learns a compression algorithm which allows it to process images most efficiently according to its loss function. The latent space might not represent certain types of shapes very well, as is the case with text characters.

Models like DeepFloyd IF work in pixel space, without learning a latent space. This means they can capture much more detail, but require more computational power. This is why these types of models usually rely on creating a smaller image and then using a separate model to upscale the image.

Indeed Apple has been very active in shaping WebGPU, and that is why we can't use a bytecode representation for shaders. Instead, we have to repeat OpenGL's mistakes and store shaders as strings.

WebGPU specifically has to be the lowest common denominator among the APIs it supports. And there are several features very useful in GPGPU's which are supported in Vulkan and CUDA, but cannot be included in WebGPU due to the lack of Metal support. One such example is floating point atomics.

I am in my early 20s and started using Emacs when I was 18. The reason I use Emacs instead of a more "modern" tool is because nothing else comes close in terms of ease of extensibility.

I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".

Doesn't using a software gl driver like llvmpipe do the trick?