On-Board graphics

Most computer enthusiasts instinctively know that on-board graphics doesn’t perform as well as a discrete graphics card, but why isn’t common knowledge. Today I’d like to shed a little light on why this is.

However don’t take this as a criticism of on-board graphics, as they have their place within the industry to provide lower cost solutions for people who don’t need the ability or can’t afford the cost of a GPU card. AMD in particular have had some very nice graphics processors on-board or on-chip and their current line up of APUs does offer very good performance per cost.

I won’t be talking about any specific hardware, as there is just too much to cover. I’ll be talking about this in a more general sense.

Onboard graphicsHere’s a little diagram of how on-board graphics are usually connected to the main system memory and CPU. Where these components actually reside depends on the age of the system. Modern APUs contain everything in this diagram (and more) except the main system memory, older systems had the memory controller and GPU in the North bridge chip on the main board. Some older systems had a separate graphics chip that utilised the main system RAM, and others actually integrated some VRAM on the board. Boards with separate VRAM are completely different beasts, and actually have more in common with systems that have a discrete graphics card.

This story in fact starts off way back in the micro computer era of C64 and ZX spectrum, which essentially had integrated graphics. The graphics chips took up much of the memory bandwidth, essentially slowing down the machines CPU quite severely under certain conditions. Modern PCs with on-board graphics also usually share the system memory with the GPU, and this is where the performance hit usually originates from.

Firstly there is an un-avoidable loss of memory bandwidth in the form of video signal generation. All graphics processors have to actually output to a screen at some point, and this requires reading the entire frame buffer and outputting appropriate data to the screen. This is as true for HDMI and DVI as it was for old school CRTs, except the resolution and colour depth have increased.

Lets take an example, say 1920×1080 at 60Mhz with 32 bit colour. For every frame sent 8,294,400 bytes have to be read (the size of the frame buffer). Do this 60 times a second and you get 497,664,000 bytes per second or about 474.6 MB/s just to output to the screen. Whilst it’s not a huge chunk of the minimum 6400MB/s that DDR3 can deliver, it certainly will reduce the available memory bandwidth to the processor, lessening its potential performance.

On-board GPUs have a significant advantage in some areas, such as the CPU being able to write (draw essentially) directly to the frame buffer, and the GPU being able to read texture data directly from system memory. However this convenience isn’t all roses as we will see.

Lets consider a rendering situation, where the GPU needs to render a number of polygons into the frame buffer. To make it simple lets make the squares of 32×32 pixels (buffer size of 4Kbytes) and we’re going to render a number of them onscreen say 500,000 per frame, now you’re looking at copying 2,048,000,000 bytes which requires both a read and a write, so really in terms of memory bandwidth that’s 4,096,000,000 or about 3.82Gb.

This is a bit of a contrived circumstance, but you can see that it’s easy for a GPU to chew up memory bandwidth when it’s rendering. This can have the effect of starving the main CPU of memory bandwidth forcing it to run slower than it could have otherwise (and vice-versa). In practice that much bandwidth probably wouldn’t be needed as modern CPU and GPU designs incorporate caching, which works very well until you start dealing with data sets larger than the cache. In this case if we were copying the same bitmap repeatedly we could half the bandwidth required as the whole bitmap could be stored in the cache.

So how does this differ from a discrete graphics card?

Discrete Graphics CardHere’s another diagram showing how they usually fit in. The graphics card basically contains everything on the right, with the IO interface being the only means of communication with the computer.

Since the graphics card has its own memory the system isn’t burdened with output of the video signal. This graphic memory is usually dual ported, or in the case of modern GDDR5 which is capable of accessing two pages of memory simultaneously (effectively dual ported although only having one). This turns out to be important as it allows both the GPU and CPU to access the video memory at the same time, which reduces latency when writing to the video memory. This used to be a big problem with CGA, EGA and earlier VGA graphics cards that didn’t have dual ported memory and the CPU had to wait for the video signal to access the graphic memory.

This graphic memory also has the distinct advantage that when the GPU is rendering a scene it doesn’t slow down the main processor by consuming the system memory bandwidth.  It does however require the CPU to communicate via the IO bus to issue scene data and rendering commands. Most scene data (textures and meshes) are pre-loaded into the graphic memory so the load on the IO bus is minimised.

The only real disadvantages of the discrete graphics card are slightly increased loading times, and slower access to Graphic memory. Longer loading times arise from the need to pre-load the scene data to the graphic card, whilst the IO bus can be exceptionally fast, the logic in the graphic card and the speed of the system and graphic memory limit the throughput. There’s also usually lots of data to upload, in the realm of gigabytes these days.

I hope this goes some way to at least beginning to explain why on-board graphics as they are implemented now won’t achieve the same performance as a system with equal but separate parts. It’s mostly the fact that system memory is shared between the two that hampers both the CPU and GPU from achieving maximum performance. If in the future AMD or Intel were to change their chips such that the GPU on-board had its own separate bank of memory, you’d start to see on board graphics become more competitive with graphic cards. This would require either dedicated memory on the main board or an extra socket for it which would add to the cost, so I feel that would be unlikely. After all on-board graphics is all about reducing the cost.


0 Responses to “On-Board graphics”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way


MS-DOS game reviews, retro ramblings and more...

%d bloggers like this: