Le Tue, 22 Feb 2011 22:11:27 +0000, Fons Adriaensen <fons(a)linuxaudio.org> a écrit : Another problem is the hardware. All the PC video cards are video driven. That imply than the card have to refresh the whole screen in order to change one pixel. That is not old technology, that is PC technology. At the same time than the first PC was computers like the Amiga or the Atary. In the Amiga, the video card was vectorial, to change one pixel, all that was needed was the new pixel value and its x y coordinates. To change a part of the screen, the Amiga was using vectorial objects called sprites. So, even for complex visual objects, the computational time was much lower than with the video approach, and the 2D on such old machines is still competitive against the 2D on the most powerful PC of today. At that time, 3D was almost non existent. To develop the 3D capabilities, most efforts from the manufacturers was spend on improving the video based cards. Now, the situation is than the 2D part of a video card is so little than the manufacturers are considering to remove it and use the 3D part to get the 2D from the card. I don't get the advantage of this approach for a workstation. A workstation is not about 3D gaming but about making some work. 3D cards are very hungry for electricity, and they will be an overkill for anyone that is not working on some kind of 3D development. The electricity providers will certainly like them very much, but my wallet and the environment don't like them. So, I think than a complete discussion on that matter should include the hardware part, that is how to make power and computational efficient 2D video cards. Dominique -- "We have the heroes we deserve."

On Wednesday 23 February 2011, at 23.47.33, Dominique Michel <dominique.michel(a)vtxnet.ch> wrote: [...] Though it would be theoretically possible to do partial refreshing of some types of displays, that would be very, very implementation specific - and quite pointless. In applications where you care about frequent updates with accurate timing, you'll usually want that for the whole screen anyway. In other applications, you just use a frame buffer and some $2 of RAMDAC hardware to repeatedly pump that out in some standard serialized format. This has nothing whatsoever to do with the way graphics is rendered. (Well, true vector displays as seen in some ancient arcade games would be a gray zone - but believe even those had some sort of "frame" buffer of sorts somewhere; they just stored a table of coordinates rather than a 2D array of color codes.) I still do exactly that in various projects, via SDL, on Windows, Linux, Mac OS X and a dozen other platforms. It works with OpenGL and Direct3D as well, though it can be a bit tricky to get right, as buffering and page flipping can be set up in a number of different ways. The sprites were just tiny hardware overlays, not actually changing anything persistently - which is the very point with them. Lots of restrictions though, there were only 8 of them, though you could multiplex them vertically. As someone who's done quite a bit of to-the-metal graphics programming on the Amiga and PC/VGA, as well as the usual DirectDraw, GDI, X11, OpenGL etc, I don't quite see what you mean here. Even the C64 did pretty much what we do today; it just had a lot less data to move around! Indeed, the C64, Amiga (and VGA) had hardware scrolling, and the former two had those hardware sprites. Those features could indeed save loads of cycles - but only in some very special cases. Many Amiga trackers used hardware scrolling of a single bitplane for low cost scrolling of the pattern view, but that's a clever trick with many limitations. The sprites were used for slider knobs and VU meters, but as there were only 8 channels, that required some clever coding in any non-trivial application. And, it would actually have a *higher* cost (due to DMA stealing CPU cycles, among other things), except for the moments when the user is actually dragging a knob...! So, for the most part, it was the usual pixel pushing we're still doing today - and not only that; it was dog slow and awkward to do due to the bitplane memory layout; for each pixel you had to twiddle individual bits in multiple locations. Same deal with anything before AGA "Chunky pixels", 256 color VGA and the HighColor/TrueColor era. The Amiga had the blitter of course, but that's just a simple precursor of the 3D accelerators we have now. That is, it did the same thing as you'd do with the CPU, only a bit faster (provided you were on the standard 7.14 MHz 68000) and more restricted. So, what's wrong with that? The alternatives are to use ancient, limited 2D APIs, or tax the CPU with custom software rendering. 2D rendering APIs essentially just cover random crippled subsets of 3D accelerator functionality. I long for the day when OpenGL (or similar) is the single, obvious answer to any realtime graphics rendering needs, so we can just forget about all this rectangular blits and limited or no blending nonsense! (And this is coming from some weirdo who actually likes to play around with software rendering and other low level stuff...! :-) It's just so much quicker and easier to get the job done! As a bonus, even a dirt cheap integrated GPU will get the job done many times faster than a software implementation, and without stealing cycles from your DSP code. 2D rendering is just a subset of 3D... Where does "3D" start? Non-rectangular blits? Scaling? Rotation? That's all basic 2D stuff, and a 3D accelerator doesn't add much more than z-buffering and perspective correct transforms on that level - and you can disable that to save the occasional GPU cycle. A CPU consumes a lot more power doing the same job. Actually, it can't even do the job properly unless you want it to take forever, and it'll still be much slower. Dedicated hardware makes all the difference in the world when it comes to efficiency. Sure, my (now "ancient") rig burns around 1000 W when working at full speed - but that means blending transformed textures all over my 2560x1600 screen at a few THOUSAND frames per second! Obviously, it only takes a tiny, tiny fraction of that power to get your average GUI application to feel responsive. And, unless you're scrolling or somehow animating major areas of the screen all the time, you don't even need that. I don't see how one could realistically design anything that'll come close to a down-clocked low end 3D accelerator in power efficiency. What are you going to remove, or implement more efficiently...? Also, 3D accelerators are incredibly complex beasts, with ditto drivers. (Part because of many very clever optimizations that both save power and increase performance!) But, hardcore gamers and other power users need or want them, so they get developed no matter how insanely overkill and pointless they may seem. As a result, slightly downscaled versions of that technology is available dirt cheap to everyone. Why not just use it and be done with it? -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://consulting.olofson.net http://olofsonarcade.com | '---------------------------------------------------------------------'