LWN.net Logo

Linux Mint introduces Cinnamon

Linux Mint introduces Cinnamon

Posted Jan 7, 2012 21:55 UTC (Sat) by michaeljt (subscriber, #39183)
In reply to: Linux Mint introduces Cinnamon by raven667
Parent article: Linux Mint introduces Cinnamon

> I think this represents a common misunderstanding, that 2D and 3D exist and are two different things, or that 3D is complicated and slow and 2D simple and fast [...]

Is it really a misunderstanding on my part to think that a simple one-to-one blit (likely accelerated at that!) is significantly faster than a perspective transformation of the same image done on the CPU without any help from a GPU?


(Log in to post comments)

Heh...

Posted Jan 7, 2012 22:56 UTC (Sat) by khim (subscriber, #9252) [Link]

Is it really a misunderstanding on my part to think that a simple one-to-one blit (likely accelerated at that!) is significantly faster than a perspective transformation of the same image done on the CPU without any help from a GPU?

Hmm... Yup, that's your misunderstanding.

The Times They Are a-Changin'. Accelerated 2D no longer exist. Contemporary GPUs no longer have it. Either you have accelerated 2D and accelerated 3D or you have nothing accelerated at all.

And if don't have a GPU then we still have a CPU which can theoretically execute about 64 billion simple operations per second (working on @4GHz and using SSE2, of course). It can transfer only 25 million bytes from memory at the same second. That's three orders of magnitude difference. More then enough to make sure perspective transformation is limited by DRAM speed, not by CPU speed (the same as with one-to-one blit). I assume here both "a simple one-to-one blit" and "perspective transformation" are written optimally: it easy to make both of them exhaustingly slow, of course...

Heh...

Posted Jan 8, 2012 16:04 UTC (Sun) by michaeljt (subscriber, #39183) [Link]

> The Times They Are a-Changin'. Accelerated 2D no longer exist. Contemporary GPUs no longer have it. Either you have accelerated 2D and accelerated 3D or you have nothing accelerated at all.

I was under the impression though that even if the same underlying hardware is used free drivers are more likely to manage the first well than the second.

> And if don't have a GPU then we still have a CPU which can theoretically execute about 64 billion simple operations per second (working on @4GHz and using SSE2, of course). It can transfer only 25 million bytes from memory at the same second. That's three orders of magnitude difference.

Thank you, point taken.

Heh...

Posted Jan 9, 2012 13:06 UTC (Mon) by etienne (subscriber, #25256) [Link]

> transfer only 25 million bytes from memory at the same second.

Wiki PCIe 2.0 bandwidth: per-lane throughput rises from 250 MB/s to 500 MB/s
With an 8 line PCIe card we have 4Gbytes/s.
3000x2000 display in 32bpp: 22 Mbytes.
Maximum refresh rate (with all pixel changed at each refresh): 186 Hz
Unless I cannot calculate on Monday morning...

Yup. My mistake.

Posted Jan 9, 2012 13:14 UTC (Mon) by khim (subscriber, #9252) [Link]

Oops. I've actually looked on real tests but they were messed up (they had title "Memory Bandwidth, MB/s" and under that numbers between 20 and 25... now they are fixed and title says "Memory Bandwidth, MB/s" which of course makes a hell of difference).

Yes, your calculation looks correct - this means that in the absence of GPU acceleration perspective effect should be coded very carefully to saturate PCIe.

Oops...

Posted Jan 9, 2012 16:01 UTC (Mon) by khim (subscriber, #9252) [Link]

Sorry for repeating the typo :-( "Memory Bandwidth, MB/s" was replaced with "Memory Bandwidth, GB/s"...

Numbers are still between 20 and 25. For LGA 2011 CPUs it's between 40 and 45, but only if there are at least 6-8 threads working in parallel. For a single thread it's the same 20-25 GB/s.

Oops...

Posted Jan 9, 2012 17:20 UTC (Mon) by etienne (subscriber, #25256) [Link]

25 Gbits/s / 8 = 3 Gbytes/s
screen definition of 1600x1200 in 32 bits = 7.3 Mbytes
Maximum "total update" frequency: 3000 / 7 = 428 times/seconds.

That is obviously when you saturate the PCIe link, which may not be possible on PC.
It will be extremely sensitive to the amount of CPU cache you have and how you use it, less so on which assembly instruction you use.
PCIe is using posted write for even large write buffers, but it may be tricky in configuration.

Heh...

Posted Jan 9, 2012 16:22 UTC (Mon) by dgm (subscriber, #49227) [Link]

> Accelerated 2D no longer exist.

It does in all my machines, thank you. It's not the GPU, but the APIs and driver support for those APIs what define what is accelerated or not.

And, by the way, there are many old GPU out there that do not fit your probable definition of "contemporary". Most are more than powerful enough for the mundane task of zooming and moving windows all day long without breaking a sweat, but are ignored because they do not support OpenGL 1.4 or newer (this definition fits ALL of my FOUR machines, for instance, none of wich is going to be replaced any time soon).

Well...

Posted Jan 9, 2012 17:51 UTC (Mon) by khim (subscriber, #9252) [Link]

And, by the way, there are many old GPU out there that do not fit your probable definition of "contemporary".

If they are old then they are probably not a contemporary. Most PCs are replaced in 4-5 years thus anything older can be safely ignored when you develop new program. With smartphones and tables replacement time is even shorter.

It's not the GPU, but the APIs and driver support for those APIs what define what is accelerated or not.

If your driver translates accelerated 2D to accelerated 3D and there are no "pure 2D hardware" then it's just unnecessary abstraction layer and you'll be better of you'll rip it out.

Most are more than powerful enough for the mundane task of zooming and moving windows all day long without breaking a sweat, but are ignored because they do not support OpenGL 1.4 or newer (this definition fits ALL of my FOUR machines, for instance, none of wich is going to be replaced any time soon).

Well, it's nice to play with a piece of computer history, but if you are developing something then you should draw a line somewhere. OpenGL 2.0 is pretty good place to draw the line IMNSHO (I'm kinda surprised GNOME Shell have chosen OpenGL 1.4) because OpenGL ES 2.0 (which is what you get on all contemporary embedded platforms) actually removed fixed-function pipeline - thus you either need to write two sets of code (one for OpenGL 1.4+ and one form OpenGL 2.0+/OpenGL ES 2.0+) or you drop support for all the obsoleted systems. ATI added support for OpenGL 2.0 in 2002, NVidia in 2004 thus it's already old enough to not be a problem in practice unless Intel GPU is used and even Intel supports OpenGL 2.1+ now...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds