Developer runs Doom on Altera CycloneV - Page 1
Forum section: electronics / general

author: Karel
author_rank: Super Contributor
timestamp: May 12, 2020, 10:58:49 am
content: https://twitter.com/sylefeb/status/1258808333265514497

author: Scrts
author_rank: Frequent Contributor
timestamp: May 12, 2020, 02:32:35 pm
content: Quake on STM32H7https://www.reddit.com/r/embedded/comments/gg5704/i_published_the_code_for_quake_for_stm32_port/https://github.com/FantomJAC/quakembd

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 13, 2020, 05:43:57 am
content: QuoteIs there any demo video?

author: Scrts
author_rank: Frequent Contributor
timestamp: May 13, 2020, 07:22:42 pm
content: Quote from: ali_asadzadeh on May 13, 2020, 05:43:57 amDid you see the reddit link? Unless reddit is banned in Iran..

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 14, 2020, 06:44:07 am
content: Yes Now I saw it on reddit! what's the achievable frame rate? what about CPU usage?SRAM and Flash usage etc..

author: Berni
author_rank: Super Contributor
timestamp: May 14, 2020, 07:26:53 am
content: Quote from: ali_asadzadeh on May 14, 2020, 06:44:07 amCPU 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.

author: senso
author_rank: Frequent Contributor
timestamp: May 14, 2020, 11:23:12 am
content: He is asking about the Cortex port..

author: David Hess
author_rank: Super Contributor
timestamp: May 14, 2020, 01:50:43 pm
content: Quote from: Berni on May 14, 2020, 07:26:53 amWasn'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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 14, 2020, 02:07:57 pm
content: 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

author: David Hess
author_rank: Super Contributor
timestamp: May 14, 2020, 02:59:50 pm
content: 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 14, 2020, 04:36:33 pm
content: Oh yeah those, Intel released at least a few chips with effectively, programmable microcode, or FPGA style configurable logic, wasn't it?Tim

author: radioactive
author_rank: Regular Contributor
timestamp: May 14, 2020, 10:46:44 pm
content: Quote from: ali_asadzadeh on May 13, 2020, 05:43:57 amfound this one

author: Berni
author_rank: Super Contributor
timestamp: May 15, 2020, 05:15:15 am
content: Quote from: T3sl4co1l on May 14, 2020, 04:36:33 pmI 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: May 15, 2020, 10:22:21 am
content: QuoteI'm interested in the STM32H version, Because I'm doing a real nice project with it! so I need the numbers for that chip.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 15, 2020, 06:30:14 pm
content: 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

author: Scrts
author_rank: Frequent Contributor
timestamp: June 06, 2020, 06:23:36 pm
content: Quote from: T3sl4co1l on May 15, 2020, 06:30:14 pmQuake 3 wasn't easy to run on Linux... It required video driver, that supports OpenGL.

author: Berni
author_rank: Super Contributor
timestamp: June 09, 2020, 08:20:35 pm
content: Quote from: Scrts on June 06, 2020, 06:23:36 pmIt 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).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 09, 2020, 09:06:46 pm
content: Well, it doesn't have to bethatbad. 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/184405765Such 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

author: Berni
author_rank: Super Contributor
timestamp: June 10, 2020, 05:41:49 am
content: 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