Developer runs Doom on Altera CycloneV

[Karel]

https://twitter.com/sylefeb/status/1258808333265514497

[Scrts]

Quake on STM32H7
https://www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port/
https://github.com/FantomJAC/quakembd

[ali_asadzadeh]

Quake on STM32H7
https://www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port/
https://github.com/FantomJAC/quakembd

Is there any demo video?

[Scrts]

Quake on STM32H7
https://www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port/
https://github.com/FantomJAC/quakembd

Is there any demo video?

Did you see the reddit link? Unless reddit is banned in Iran..

[ali_asadzadeh]

Yes Now I saw it on reddit! what's the achievable frame rate? what about CPU usage?SRAM and Flash usage etc..

[Berni]

Yes Now I saw it on reddit! what's the achievable frame rate? what about CPU usage?SRAM and Flash usage etc..

CPU usage is N/A % because there is no CPU inside it.

That's what makes it interesting, the rendering was rewritten to be done in logic. So its more of a hardware raycasting engine being run by a state machine to fly around the levels. But it does use up a lot of the FPGAs gates to do it, so its not all that practical.

[senso]

He is asking about the Cortex port..

[David Hess]

That's what makes it interesting, the rendering was rewritten to be done in logic. So its more of a hardware raycasting engine being run by a state machine to fly around the levels. But it does use up a lot of the FPGAs gates to do it, so its not all that practical.

Wasn't Intel considering the integration of FPGA logic with CPUs for that sort of application?  I thought that was one of the reasons they bought Altera.

[T3sl4co1l]

Well, Cyclone V had hard CPU core in it before it was Intel.  (I think this is what you're saying anyway, but for some reason I didn't parse it that way?)  But that's not a challenge.

Tim

[David Hess]

No, I mean integrating FPGA logic with existing processors for applications which could gain a performance benefit from the configurable logic.  I read a little on it and apparently some data center applications already do this with external FPGAs for applications like searching.  It does not seem that Intel was thinking of it in a more general sense.

[T3sl4co1l]

Oh yeah those, Intel released at least a few chips with effectively, programmable microcode, or FPGA style configurable logic, wasn't it?

Tim

[radioactive]

Quake on STM32H7
https://www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port/
https://github.com/FantomJAC/quakembd

Is there any demo video?

found this one

[Berni]

Oh yeah those, Intel released at least a few chips with effectively, programmable microcode, or FPGA style configurable logic, wasn't it?

Tim

I have a Cyclone V dev board and its mostly a typical ARM SoC but with a big fat memory pipe to the FPGA fabric. Its still pretty nice since you get pipes that can execute read/writes in the ARM memory space, seperate pipes where the ARM can send write/read operations to the FPGA fabric and another separate memory bus going directly into the DDR memory controller (I think that's the fattest 256bit bus). There is also the ability to split these buses up into multiple busses with less data lines to get low latency to multiple systems in the FPGA. So maybe not quite microcode but it can do quite a lot.

And yeah if you ware to attempt to run Doom at the max possible frame rate then the way to do it would likely be a chip like a Cyclone V (Or Xilinx ARM+FPGA chips) where most of the code would run on the ARM and the FPGA would sort of be a "hardware raycast acceleratod" graphics card. But who needs to run Doom at 1000s of FPS if you can't even display it.

[ali_asadzadeh]

CPU usage is N/A % because there is no CPU inside it.

I'm interested in the STM32H version, Because I'm doing a real nice project with it! so I need the numbers for that chip.

[T3sl4co1l]

Absolutely; with enough integration, you could probably run Quake 3 on one of the up-scale-ier SoCs.  Video is easy, drop in a HDMI core.

(Er, those are pretty fast A-series cores, aren't they?)

Tim

[Scrts]

Absolutely; with enough integration, you could probably run Quake 3 on one of the up-scale-ier SoCs.  Video is easy, drop in a HDMI core.

(Er, those are pretty fast A-series cores, aren't they?)

Tim

Quake 3 wasn't easy to run on Linux... It required video driver, that supports OpenGL.

[Berni]

Quake 3 wasn't easy to run on Linux... It required video driver, that supports OpenGL.

It is possible to run OpenGL using the CPU only. So technically you can run it as soon as you have a nice linux running ARM, but yeah as you would imagine this software emulated mode is so horrendously slow that it most likely would not run anywhere near a playable speed, as instead of frames per second you start measuring seconds per frame.

You could make it even more ridiculous. Like taking a CPU not capable of running linux and using it to emulate a CPU that can do it. For example someone did boot linux on a 8bit AVR MCU with the help of a big ass bitbanged external RAM chip. So technically it could also be made to run software emulated OpenGL too. But then the measure of seconds per frame would turn into hours per frame... but it would technically run (With a pretty liberal use of that word hah).

[T3sl4co1l]

Well, it doesn't have to be that bad.  Growing up, I played Quake 2 on a Pentium 120.  Barely hit 15 FPS, but it was something.  Quake 3 with a bunch of features turned off (bump mapping, filtering, low detail geometry, etc.) and a low resolution must run way faster than that.  It was only 1999, it's not like it's Source or UE4.

Software renderers have been kicking ass for a long time, at first of course because they had to, but that doesn't explain this beast very well:
https://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765
Such a feat would of course take a serious amount of work to port over to a completely different instruction set, and extensions, but I have no doubt that some quite reasonable looking scenery could be drawn in real time; if probably not full screen HD.

Let alone ported over to raw VHDL; that'd be quite some work indeed.  But with FPGA fabric to do the heavy cranking, look for some open graphics cores maybe, it should be quite possible to implement a reasonable subset of OpenGL.  Maybe it could even deliver full HD?

Tim

[Berni]

Well it definitely is possible to do some good realtime 3D with just software rendering. But Linux LibGL Mesa implementation of it is not all that fast on ARM as its mostly a compatibility fallback/testing thing, tho for 2D stuff it can run fairly fast.

For doing OpenGL on a FPGA the way to go at it might be the architecture of the Playstation 1. It has a 3D GPU so primitive that it sort of straddles the boundary between being a GPU and a math coprocessor. Unlike a modern GPU that can just be thrown some model data, textures, transforms..etc and miliseconds later spit out a rendered image into a framebuffer, instead this one had to be babysit by the CPU all the time. Each triangle had to be passed trough the built in matrix math coprocesor to rotate it, the CPU had to do Z ordering (no depth buffer) and then pass it over to the rasterizer to be drawn. A some of the rendering steps are also using cheaper fixed point math that resulted in a few rounding related graphical artifacts in some places.

So one could take the software OpenGL implementation and start moving the most computationally intensive steps into the FPGA. Not sure how much performance you could get out of it tho since 3D graphics is pretty floating point heavy and the reasonably priced FPGA chips stick to fixed point hardware math blocks, while doing float in raw FPGA logic is pretty resource heavy. The rasterizing step should be really speedy in a FPGA id imagine. Maybe do the float heavy vertex transforms using ARM NEON SIMD instead? So as long as the rasterizer is fast it should do 1080p