What is meant by coding down to the metal?

Started by
11 comments, last by Buster2000 10 years, 10 months ago

This description is for a Senior Game Programmer position:

  • Coding down to the metal is crucial for today’s high-performance games. Low-level programming fundamentals and experience with the DirectX/OpenGL graphics pipeline are a huge plus.

What does "coding down to the metal mean?" Why would they need low-level programming fundamentals? I thought high-level programming languages like Java was enough. I only have enough programming experience with Java. Please enlighten me. I am curious. happy.png

Advertisement

Firstly, if they're talking about coding to the metal, they're almost certainly talking about writing code in C/C++. I doubt they're using higher level languages like Java or C# (at least for this particular role - you might find that the company uses C# in their tools for instance).

I would imagine the company would be looking for a candidate who knows, amongst other things:

* How to write efficient code

* How to profile GPU performance and how to optimise based on the results

* How to profile CPU performance and how to optimise based on the results

* How to use multithreading effectively

* How to use SIMD effectively

* How to design code that is data cache friendly

* Possibly even an understanding of assembly (although this is less common these days)

calling C++ and OpenGL running on top of Windows "down to the metal"... sigh...

there was a time when "down to the metal" meant basically writing code for the raw hardware (with no OS or device drivers involved), and often with stuff written in a fair bit of assembler as well.

hence, the "metal" meant the "physical hardware", and "down to" as-in, no OS or drivers running between ones' code and said hardware...

but, alas...

Note that the line of the ad mentioned 'down to the metal' and also OpenGL and DirectX.

Reading the ENTIRE line,it is obvious 'down to the metal' is referring to low level graphics programming.

Note that the PS3 and X360 have graphics systems that are either OpenGL-like or Direct3D based. So someone in this position needs to know both.

On the PC, you use a function call to OpenGL or DirectX to do something, and the drivers feed information to a command buffer, which in turn gets consumed by the graphics card. On game consoles you have the option of directly manipulating the graphics command buffer. This is often called bare metal graphics programming; there is nothing between you and the hardware.


Translation of the line: They want a graphics programmer who can understand and manipulate the graphics command buffers on both PS3 and X360, but will settle for someone who just knows graphics on both systems really well.

Programmers who are skilled at this type of programming work are rare. They are also expensive to headhunt. On the other hand, if you want your $30M game project to approach the console's theoretical maximum of 500 million tris/sec, you probably need somebody like this. You need them early, you need them for the entire project, and you allow them to force performance-minded habits on everybody on the team.

It is absolutely a senior-level position. If you don't have years of experience in console programming and graphics, don't apply.

cr88192 is generally right - the original meaning of 'down to the metal' was that you would write software that ran directly on hardware (either on an EPROM or later on flash-programmable hardware).

In the gaming world, knowing how to code "down to the metal" generally means that you are able to write software for specific pieces of hardware. High level languages like Java are meant to make it easy to write software that runs on multiple platforms, but they also tend to restrict or remove access to hardware-specific features (especially since certain features are only available on one piece of hardware and none of the rest). C++ is one of the few languages that spans a large range of low-level control to high-level convenience (but pays for that flexibility by being harder to understand and use correctly than most languages).

C0lumbo mentioned many of the typical things you'd deal with in games at the low level. Also, some of the following would apply:

- Know details about specific processors you're targeting. Do they have any instruction set extensions that your compiler won't use automatically? This used to be restricted to specific gaming consoles, but more recently also includes phones and tablets.

- (PS3 specific) How the SPUs and RSX chips works and how to best use them. This is probably the closest thing to the original meaning of 'down to the metal' left in game dev -- eventually this knowledge will become irrelevant since Sony received pretty strong backlash from us developers resulting in the PS4 having a more conventional processor.

- Write custom memory management systems. (Fragmentation avoidance, debug helpers, and in extremely rare cases garbage collection and relocation)

- Be able to disassemble your own code to identify places where C++ code did not get optimized ideally (usually due to a mistake in the high level code, but very rarely due to a compiler oversight).

- Be able to profile and debug at the assembly level, and understand profiling information for bus access and cache hits/misses.

- Perform specialized serialization of game assets and optimization of disc access patterns to increase loading speeds.

- Understand data structure layout in memory byte-by-byte and know what kind of size/performance tradeoffs you have on the specific platform you're working on.

- Know the gory details of the specific GPU you're using and how to get the best performance out of it.

- Know which texture compression formats your GPU supports and the quality, performance and memory characteristics of each.

And after a few moments in Google, we can see that Arkadium in New York is staffing up for building a new engine, and the above quote is a line from one of their open senior developer positions. Based on the 24 open positions on their site and what they've released in the past, it looks like they're looking to expand their current mostly-social business over to consoles.

Two relevant lines from that job listing:
* Coding down to the metal is crucial for today’s high-performance games. Low-level programming fundamentals and experience with the DirectX/OpenGL graphics
* Modern games need to run well on a wide range of devices. If you are skilled in optimizing gameplay and graphics code, you’ll help our games reach the widest audience.

This is a team lead or programming lead position. They also have some intern positions available, but I'm sure they'll go quick.

Note that the line of the ad mentioned 'down to the metal' and also OpenGL and DirectX.

Reading the ENTIRE line,it is obvious 'down to the metal' is referring to low level graphics programming.

Note that the PS3 and X360 have graphics systems that are either OpenGL-like or Direct3D based. So someone in this position needs to know both.

On the PC, you use a function call to OpenGL or DirectX to do something, and the drivers feed information to a command buffer, which in turn gets consumed by the graphics card. On game consoles you have the option of directly manipulating the graphics command buffer. This is often called bare metal graphics programming; there is nothing between you and the hardware.


Translation of the line: They want a graphics programmer who can understand and manipulate the graphics command buffers on both PS3 and X360, but will settle for someone who just knows graphics on both systems really well.

Programmers who are skilled at this type of programming work are rare. They are also expensive to headhunt. On the other hand, if you want your $30M game project to approach the console's theoretical maximum of 500 million tris/sec, you probably need somebody like this. You need them early, you need them for the entire project, and you allow them to force performance-minded habits on everybody on the team.

It is absolutely a senior-level position. If you don't have years of experience in console programming and graphics, don't apply.

Yup its says Senior as listed above. I was just curious about what an applicant needed to know upfront for this position. I only know one programming language well enough and that is Java.

And after a few moments in Google, we can see that Arkadium in New York is staffing up for building a new engine, and the above quote is a line from one of their open senior developer positions. Based on the 24 open positions on their site and what they've released in the past, it looks like they're looking to expand their current mostly-social business over to consoles.

Two relevant lines from that job listing:
* Coding down to the metal is crucial for today’s high-performance games. Low-level programming fundamentals and experience with the DirectX/OpenGL graphics
* Modern games need to run well on a wide range of devices. If you are skilled in optimizing gameplay and graphics code, you’ll help our games reach the widest audience.

This is a team lead or programming lead position. They also have some intern positions available, but I'm sure they'll go quick.

Oh so that is what Arkadium is doing! I was confused because all their past titles were not console games but rather web-based casual like their game on Facebook and on their website. So they are trying to tap into the console market. Interesting insight.

calling C++ and OpenGL running on top of Windows "down to the metal"... sigh...

there was a time when "down to the metal" meant basically writing code for the raw hardware (with no OS or device drivers involved), and often with stuff written in a fair bit of assembler as well.

hence, the "metal" meant the "physical hardware", and "down to" as-in, no OS or drivers running between ones' code and said hardware...

but, alas...

How did you know it was on Windows and not dealing with code for the hardware? Most of the stuff I am writing on this post is very new to me. But all the information is an interesting read. I am still a CS undergraduate.


calling C++ and OpenGL running on top of Windows "down to the metal"... sigh...

there was a time when "down to the metal" meant basically writing code for the raw hardware (with no OS or device drivers involved), and often with stuff written in a fair bit of assembler as well.

hence, the "metal" meant the "physical hardware", and "down to" as-in, no OS or drivers running between ones' code and said hardware...

but, alas...

How did you know it was on Windows and not dealing with code for the hardware? Most of the stuff I am writing on this post is very new to me. But all the information is an interesting read. I am still a CS undergraduate.


I had seen the term used this way before, and was writing more in "general sense".

like, basically it is the issue of some people being like "man, I am using C and OpenGL, man so low-level, so down to the metal...". like, the whole thing of seeing C like it was ASM and OpenGL like it is raw hardware, failing to take note of how much abstraction already does exist by this point.


(much of what follows is personal experiences and personal opinion).


meanwhile, I once (long ago now) wrote a simplistic OS (got about to the level of having networking and a basic GUI before I concluded it was ultimately pointless at this point), and booting up into ones' own kernel and doing graphics mostly by messing around with VGA io-ports/registers and the framebuffer and similar, is a fair bit of a different experience.

it was an experience of like:
want networking? deal with Ethernet packets, protocols like ARP, then build up to things like ICMP and IP, and implement UDP and TCP on top of this;
want graphics? deal with the various ports and registers for this particular piece of video hardware (and the fun of the framebuffer and VRAM, and if you want something OpenGL like, you write it yourself...);
want sound? basically the same thing;
as well, there was the fun of all the other hardware (ATA / IDE controller, dealing with keyboard and mouse, ...).

or, IOW:
there is the core part of writing the OS kernel (and some CPU-level stuff, *1);
and, then, trying to write all the drivers...

technically it would have been kind of a hybrid (of Windows and Linux), as by that point I was using mostly PE/COFF for binaries (and basically compiling the kernel and binaries using MinGW), but was using POSIX-like APIs (and some architecture based on looking at early versions of the Linux kernel), and using mostly using FAT32 and LFN (*2), ...

*1: yeah, this is a bit more manual memory management... you have physical addresses, process-level virtual addresses, page-table fun, ... simple things, like copying memory between userspace and kernel-space, when you can't access both spaces at the same time, and the user-space memory is scattered all over the place from the POV of the kernel (would have been more fun if I was dealing with swap... *3).

*2: yes, one gets to see how LFN is implemented...

*3: no, you can't just call something and do a synchronous read/write from/to the HDD in the kernel, more often things like disk-IO need to be asynchronous and use callbacks for when IO completes, ... partial thing: you can't really have any blocking operations in the kernel (this would probably, kind-of, break stuff...).


eventually, I gave up on this project, eventually concluding that there would be little hope of me personally getting anywhere near either Windows or Linux levels of development, and OS's tend to be largely mutually-exclusive.

but, yes, the point is not to underestimate how much the OS actually does here...


but, for me, "down to the metal" is more this sort of experience, rather than the sort of sheltered existence of a user-space process inside an OS where "low-level" is people feeling uncertain about when to use "free" or "delete"...

much like C seems little like assembler to anyone who has actually written much of anything *in* assembler.


but this (among other things) can sort of be a bit of a source of personal frustration sometimes...

much like the whole view (when expressed occasionally by supposed "expert" programmers) that program code is itself like some sort of black-art written off by mages somewhere... seriously?!...

This topic is closed to new replies.

Advertisement