   Bottleneck of sotware 3D drivers?
  Someone used to 15 years of 3D gaming might not be aware of it, but there exist computers that emulate 3D graphics in software mode instead of using the video card. Examples of this are:-Windows Vista / 7 when it renders OpenGL without proper video drivers-Linux (both OpenGL and D3D through Wine) when not using the binary NVidia drivers (even though they're available and work great for me, some people can't or don't want to use them)-Some other platforms, including AmigaOS4, that have no good 3D driversSo apparently there are renderers that implement OpenGL through software. Does anyone know, in general, what the bottlenecks of such renderers are?For hardware acceleration, the bottleneck I encountered the most was the data transfer from the CPU to the video card (to pass such things as 3D coordinates and textures to the graphics card). But in software rendered drivers there is of course no such thing as transfering such data to the video card.What are the weak spots of such renderers? Could it be alpha channels? How much triangles per second should such a renderer be able to handle?I'm trying to find out if there are some potential easy optimizations I could do to my program (which uses 3D rendering for 2D graphics with many alpha channels) to be fast enough on such systems.   
  This article might be a good read for you Dr Dobbs. Pixomatic.Its about Pixomatic, probably the most advanced and fastest DirectX 9(although its much faster at DX7) compatible software renders.I think anything to do with texturing becomes a problem if you don't want to to point filtering only.   ;  Are you sure about the Nvidia drivers? Operation Flashpoint and some other games run very well through wine on my AMD/ATI machinery.   ;Quote:Original post by phresnelAre you sure about the Nvidia drivers? Operation Flashpoint and some other games run very well through wine on my AMD/ATI machinery.Read carefully, I posted: "when _not_ using the nvidia drivers"! :);Quote:Original post by LodeRead carefully, I posted: "when _not_ using the nvidia drivers"! :)Phresnel's point is that you ought to have said 'when not using the ATI or NVidia drivers', or to put it far more succinctly, 'when using MESA'.   ;  This isn't directly related to OpenGL, but DirectX implements a D3D10 level renderer.  It could be good for testing out different scenarios if you have access to a D3D10 codebase.  You can google for the WARP driver for more details.In my own experiments a couple of years ago, I found that memory bandwidth for the CPU was the biggest hurdle in my engine.  The calculations can be spread across several threads, but it is very difficult to find an optimal way to pass all of the data through a software pipeline efficiently.That is my experience anyways, I would be interested to hear other opinions...;  AFAIK, where posible, Vista/Win7, in leue of proper OpenGL drivers, use a translation layer that sits on top of Direct3D, rather than traditional software rendering.Off the top of my head, the modern software rasterizers are:Pix-o-matic by RadGameTools, written by Michael Abrash (graphics god) and probably others. Abrash was also hired as a consultant to develop what would have been the Direct3D and OpenGL software for Intel's ill-fated Larabee GPU, which was essentially 32 very fast Pentium processors with huge (16-float-wide) vector units tacked on.SwiftShader by TransGaming Technologies written by Nicolas Capens (not sure if the spelling is right, but he goes by SwiftCoder C0D1F1ED around here). It's IIRC, able to support DirectX 10.Mesa, the old OpenSource standby. For the most part its a traditional software renderer, but there are some interesting sub-projects, namely:Mesa for Cell -- A software renderer which ofloads graphics to the SPU units as much as possible. There's certainly a lot of brunt there. Interesting architecture for graphics work. Originally, Sony was hoping the the PS3 wouldn't have a dedicated GPU at all, but multiple Cell processors. They couln't get performance up to snuff with that approach, considering the cost of multiple Cells (and also not wanting to create an even shorter supply of them) vs adding a discreete GPU, which they of course ended up doing.SoftPipe -- This is the newest and most interesting to me. It uses LLVM to compile the graphics pipeline for the hosting architecture on the fly. Apple has already been using LLVM (They're one of its main corporate contributors) in their OpenGL stack to provide missing functionality. LLVM itself is interesting since it supports fairly high-level constructs (IIRC, common SIMD argument vector widths, if not arbitrary ones), once a graphics stack targets LLVM bytecode, the LLVM runtime JITer compiles and optimizes for the platform.All of these projects are not simple software rasterizers, each relies on dynamic code generation which is really the only way to get performance that is *really* special these days (in terms of software rasterizers). I imagine they can reach speeds 50-100 percent faster than a traditional rasterizer.Also, most of these are multi-threaded and most choose to "tile" the screen into several small chunks and farmed out to cores as they become available. Its really about the only architecture for a software rasterizer which makes sense in a multi-core world. The XBox 360 does this for higher resolutions in order to keep the working set inside its 10MB embedded framebuffer. The PowerVR architecture has used tiling all its life, from back to the Kyro days, through the Dreamcast, and still today in the latest versions found in nearly every smartphone (Most android phones, all iPhones, iPad) and embedded devices (most GPSes, the Beagleboard, the Pandora).[Edited by - Ravyne on May 31, 2010 10:57:29 PM];Quote:Original post by RavyneSwiftShader by TransGaming Technologies written by Nicolas Capens (not sure if the spelling is right, but he goes by SwiftCoder around here). It's IIRC, able to support DirectX 10.Nope, he really doesn't - no relation at all [wink]Also worth mentioning Apple's extremely capable software OpenGL implementation, though they heavily favour functionality over speed, it is still no slouch when it comes to speed.   ;  Hrm... guess I've crossed wires... He is around though. What user name does he go by?Edit: Turns out it's C0D1F1ED, though that profile hasn't been active in nearly a year.   ;Quote:Original post by Lode-Windows Vista / 7 when it renders OpenGL without proper video driversWin Vista/7 comes with OpenGL drivers unless you're using a very obscure video card, in which case IIRC it fallbacks to a Direct3D wrapper. It's not a software implementation.Windows XP uses a very old 1.4 ICD implementation, and IIRC, it was based on SGI's reference source code implementationFor Direct3D10 in Vista and 7, there's a decent software implementation called "WARP"Quote:Original post by Lode-Linux (both OpenGL and D3D through Wine) when not using the binary NVidia drivers The most used software implementation in Linux is Mesa.If you don't have an implementation installed, your Linux box won't be capable of running any OpenGL program (which can happen)Quote:Original post by LodeSo apparently there are renderers that implement OpenGL through software. Does anyone know, in general, what the bottlenecks of such renderers are?Ummm, there can only be two: CPU or RAM.CPU if you use too many vertices, filtering capabilities (bilinear, trilinear, anisotropic), or advanced computations (i.e. advanced lighting, by "advanced" I mean anything beyond diffuse lighting model)RAM when the screen resolution is big, there are too many vertices, textures are very big and filtering is set to high (i.e. bilinear, trilinear, anisotropic).Oh and yes, most of the problems causing a bottleneck in the CPU and RAM are shared problems. Usually if it's not bottlenecking the RAM it's because memory bandwidth is high enough on the system being run, or all the data fits in the cache (that's very nice)Quote:Original post by LodeFor hardware acceleration, the bottleneck I encountered the most was the data transfer from the CPU to the video card (to pass such things as 3D coordinates and textures to the graphics card)Then you must be doing something very wrong or you're doing hell of a rendering.VBOs, FBOs, updating from shaders, instancing, have all reduced CPU-to-GPU transfer bottlenecks to very specific cases.Still remains a problem, but I doubt a 2D game could trigger it.Quote:Original post by LodeWhat are the weak spots of such renderers? Could it be alpha channels?More than weak spots, the question is if your game runs fast enough at the minimum/average system specs from the market you're aiming.Alpha channels per se don't affect much (unless you're very bandwidth limited) but rather alpha blending (that definately eats all bandwidth, that's even true for dedicated GPUs)Quote:Original post by LodeHow much triangles per second should such a renderer be able to handle?Hard to say. Depends too much on the processor CPU.Why are you worried about your user not being able to run with a GPU anyways?If your game runs in software mode, it should run more than fast even on a crappy integrated GPU solution.If you're in Windows, there's a driver for sure (and if there is not, then the system is SO old that even a software implementation wouldn't be able to run it decently).If you're in Linux, the newbie user uses Ubuntu which most of the times comes with accelerated drivers out of the box; if he's using a different distro it's fair to assume he has enough knowledge to setup the drivers or he's not interested in gaming.CheersDark Sylinc   