The idea of GPU is a method to take load off o the main CPU, to put it onto another processor that has the only purpose of processing the graphics you are doing.
A form of delegating between multiple chips, as I understood it. This way, you have one chip working specifically on the graphics, and the other doing everything else. And you are right---a software render cannot compete with a GPU on an even field. You missed the point where Linux does not take up as much system resources, typically, as the latest versions of Windows does. The idea being, to get a software renderer on Linux, to work on the same level as a hardware renderer on Windows. Like I said, you can typically get Linux, to run in a GBA... you cannot fit anything else into there (maybe pong, I guess?). A GBA typically clocks in at about 67.5MHz IIRC, with next to no RAM. Windows 7, kind of requires 1GiB at a minimum for RAM, and you are going to need at least 1 or 2 GHz to get it running. My idea, again, in case you missed it, was to try to take up this saved overhead, use it for software rendering, to make it comparable to the hardware rendering on Windows. The idea being: If you can get that kind of comparable speed on Linux with Software Rendering... this would make graphics card companies more inclined to make drivers for Linux--as this shows how much more resources you can fit games into. I mean, no idea how this point was lost, when what started this train of thought was that Nvidia and ATI had issues supporting Linux with their drivers. The software rendering engine would never be more than used as a form of insane PoC idea. Or at least, never commercially. It would be a demo, that would be aimed at getting the attention of hardware driver developers to target linux for these drivers. A publicity stunt was what I was suggesting. ~Katrina On Tuesday, June 15, 2010 02:45:33 pm Adam Buckland wrote: > I was under the impression that the whole point of building GPUs in > the first place was because it was impossible to build a software > renderer of comparable speed :P > > On 15 June 2010 20:39, Bob Somers <magicbob...@gmail.com> wrote: > > Trying to make a software renderer compete with a dedicated GPU is > > kind of, uh, an exercise in futility. > > > > --Bob > > On Mon, Jun 14, 2010 at 11:20 PM, Katrina Payne > > <fullmetalhar...@nimhlabs.com> wrote: > >> Well, considering how crazy this idea is... that is likely all I would be > >> having with it... > >> > >> Regardless of whether or not it works. > >> > >> This is like Joker from Batman type crazy here... > >> > >> So, yeah, I will X3 > >> > >> The issue is I have too much other crap on my plate right now--however, I am > >> certain there are other crazy people on this mailing list who have the time > >> for this suggestion. > >> > >> On Tuesday, June 15, 2010 12:14:42 am Bob Somers wrote: > >>> Uh, have fun with that. > >>> > >>> --Bob > >>> On Mon, Jun 14, 2010 at 8:20 PM, Katrina Payne > >>> <fullmetalhar...@nimhlabs.com> wrote: > >>> > This also adds a rather odd burden here, that allows Linux to get a better > >>> > standing for gaming. > >>> > > >>> > It is not that unknown that without mixing, Linux generally does not > >> require > >>> > anywhere near as much over head to run as windows. > >>> > > >>> > The minimum requirements to run a GUI on Linux is about 256MiB of RAM. > >> This > >>> > even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be > >> better if > >>> > you really did only have 256MiB of RAM (well if you were using a DE... and > >> not > >>> > a slimmed down WM with only a few programs loaded into it) > >>> > > >>> > You can do just fine win 1GiB of RAM. > >>> > > >>> > Linux also, as an OS can run on some old Intel boards--that running an OS > >> on > >>> > would other wise be insane today. a Pentium 1 can still get (some) use > >> with > >>> > Linux. > >>> > > >>> > Not enough to really be noteworthy as a desktop PC... but, this is a lot > >> less > >>> > than the least you will get Windows 7 onto. > >>> > > >>> > So we have a nice toss up here: > >>> > > >>> > 1: Linux requires Software Rendering in place. IE: how rendering was done, > >>> > before we got silly things like TNT and Voodoo on the market. > >>> > > >>> > 2: Linux requires significantly less overhead to run, as far as OS goes. > >>> > > >>> > If we can get it so that we can show Steam running on Linux, using mostly > >>> > Software Rendering, and getting it to run as fast as the same game on > >> Windows, > >>> > on comparable hardware... > >>> > > >>> > This will definitely sell Linux as an OS... > >>> > > >>> > Which in turn will get various Graphics Card makers on board to add their > >>> > support. > >>> > > >>> > You know--I kind of want to see somebody work on that goal then. I am > >> almost > >>> > ready to dig up some old books that go over the theory of 3d programming, > >> just > >>> > to pull make a software rendering engine for this idea. > >>> > > >>> > On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote: > >>> >> Yes, 3D drivers are definitely quite lacking on the GNU/Linux front, > >>> >> but if Valve shows support for the development of these drivers, this > >>> >> may prompt certain GPU manufacturers to step up their GNU/Linux driver > >>> >> development. > >>> >> > >>> >> Darren L. VanBuren > >>> >> ===================== > >>> >> http://theoks.net/ > >>> >> On Mon, Jun 14, 2010 at 18:35, Bob Somers <magicbob...@gmail.com> wrote: > >>> >> > Something to consider, though, is that the 3D driver support is years > >>> >> > behind from *ahem* a particular GPU manufacturer. I won't embarrass > >>> >> > them by saying their name, so I'll just say their initials: ATI. > >>> >> > > >>> >> > Their driver support for Linux is, frankly, pathetic at best. The > >>> >> > Fedora team is trying to solve this with their new free drivers in > >>> >> > Fedora 13 (which, I'll admit, are quite good), but it's still not up > >>> >> > to par with what you need to run a game. For example, the new free > >>> >> > drivers have very little (read: practically none) support for basic > >>> >> > vertex and fragment shaders. It will be at least another year before > >>> >> > the free drivers are up to what ATI's crappy proprietary drivers are > >>> >> > now. Even worse, right now you can get the proprietary drivers running > >>> >> > on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and > >>> >> > not at all on Fedora 13. Literally, ATI's Linux drivers are at least > >>> >> > 12 months behind, and the free ones are 12 months behind that. > >>> >> > > >>> >> > Unless somebody gives ATI a swift kick in the nuts the situation does > >>> >> > not look good. > >>> >> > > >>> >> > --Bob > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren <onekop...@gmail.com> > >>> > wrote: > >>> >> >> Spoiler Alert. It's like the ratman drawing that says "She's watching > >>> >> >> you." Canonical is she in that case. > >>> >> >> > >>> >> >> I'm personally a fan of Fedora, but if Steam on GNU/Linux is > >>> >> >> distributed as a tarball, that'd be best in the interests of Valve. > >>> >> >> Even if some people (mainly Ubuntu users) would be a bit stuck on the > >>> >> >> concept of a tarball, it'd be minimal work for Valve, and maximum > >>> >> >> cross-distribution compatibility. > >>> >> >> > >>> >> >> Darren L. VanBuren > >>> >> >> ===================== > >>> >> >> http://theoks.net/ > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Mon, Jun 14, 2010 at 16:49, Harry Jeffery > >>> >> >> <harry101jeff...@googlemail.com> wrote: > >>> >> >>> It's all down to personal opinion, as long as it does what you need > >>> >> >>> quickly and effectively then it's fine. I've yet to see the dark side > >>> >> >>> in cannonical so I honestly can't say much about their ethics. > >>> >> >>> > >>> >> >>> Either way, I <3 Linux and so should Valve. > >>> >> >>> > >>> >> >>> On 15 June 2010 00:19, Katrina Payne <fullmetalhar...@nimhlabs.com> > >>> > wrote: > >>> >> >>>> Well a few points: > >>> >> >>>> > >>> >> >>>> The commands in the Linux Commandline... and well those on any UNIX > >> or > >>> > UNIX > >>> >> >>>> Workalike have not really changed since the 1970s. You could pick up > >> a > >>> > book on > >>> >> >>>> BASH or TCSH from the 1970s, and still have most of what you should > >> do. > >>> >> >>>> > >>> >> >>>> This kind of has allowed for tools to be put around these base > >>> > functions, such > >>> >> >>>> as autocomplete, history and well--quite a few other really handy > >>> > tools, to be > >>> >> >>>> added into the Linux CLI, to make its functionality go above and > >> beyond > >>> >> >>>> anything cmd.exe is capable of. > >>> >> >>>> > >>> >> >>>> I still have yet to look into Microsoft's PowerShell though. > >>> >> >>>> > >>> >> >>>> This is why most Linux users use the CLI. It has developed into an > >>> > experience > >>> >> >>>> that is completely unlike the root canal that is cmd.exe. You can > >>> > actually go > >>> >> >>>> in, and get some functionality from it. A lot of functionality too. > >> It > >>> > also > >>> >> >>>> gives the feeling that the user has more direct control--without > >> that > >>> > Pesky > >>> >> >>>> GUI in the way (though, technically, this just has a bunch of other > >>> > items > >>> >> >>>> typically in the way, such as init.d, bash, various bash > >> extensions-- > >>> > maybe > >>> >> >>>> screen... you are just trading one thing in the way, that is, a GUI, > >>> > for > >>> >> >>>> another thing, that is a CLI). > >>> >> >>>> > >>> >> >>>> Now, that said--there are plenty of Desktop Environments ('DE') that > >>> > Linux can > >>> >> >>>> make use of, that pretty much make requirement of CLI use > >> unnecessary. > >>> > That > >>> >> >>>> is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux > >>> > user > >>> >> >>>> nearly never has to do anything on the CLI. Unless something has > >> gone > >>> > horribly > >>> >> >>>> wrong. In which case, he should be able to get the local Linux Admin > >> to > >>> > fix it. > >>> >> >>>> > >>> >> >>>> As that technically is what he'd do if something went horribly wrong > >> on > >>> >> >>>> Windows. He'd get his local Windows Expert to fix it. > >>> >> >>>> > >>> >> >>>> The "required" use of the CLI rather than GUI to properly use Linux, > >> is > >>> > much > >>> >> >>>> like how using Vi is "required" rather than EMACS for the proper use > >> of > >>> > Linux. > >>> >> >>>> > >>> >> >>>> Also, I use Fedora, and typically find it a LOT easier to work with > >> than > >>> >> >>>> Ubuntu. This maybe, because Fedora tries not to be a bunch of > >> asshats > >>> > to the > >>> >> >>>> people upstream. The same cannot be said about Canonical, the owners > >> of > >>> >> >>>> Ubuntu. Where, from what I have seen on their policies by past > >>> > actions... > >>> >> >>>> their MAIN desire is to be asshats to the upstream. > >>> >> >>>> > >>> >> >>>> I have a long winded rant on why I do not like Ubuntu... I mostly > >> just > >>> > state > >>> >> >>>> that nobody uses Ubuntu Linux. Typically most people go over to > >> another > >>> > Linux > >>> >> >>>> Distro afterwards, generally agreeing that no matter what Linux > >> Distro > >>> > they go > >>> >> >>>> to, be it Fedora, Puppy (well, prior to being based on Ubuntu), > >> Arch, > >>> > Slack, > >>> >> >>>> Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either > >>> > that, or > >>> >> >>>> they return to Windows--only using Ubuntu as a rescue disk setup. > >>> >> >>>> > >>> >> >>>> Right, now then. Back to your regular discussion > >>> >> >>>> > >>> >> >>>> ~Katrina > >>> >> >>>> > >>> >> >>>> On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote: > >>> >> >>>>> People like the command line because it's very fast to do what you > >>> >> >>>>> want if you know what you are doing. So far ubuntu seems to be the > >>> >> >>>>> most user friendly linux distro and what a majority of linux gamers > >>> >> >>>>> might use. > >>> >> >>>>> > >>> >> >>>>> Personally I'd just use arch-linux and optimize my system...a lot. > >> As > >>> >> >>>>> long as nVidia release decent linux drivers it's all good. > >>> >> >>>>> > >>> >> >>>>> On 13 June 2010 14:01, Adam Buckland <adamjbuckl...@gmail.com> > >> wrote: > >>> >> >>>>> > A couple of things: > >>> >> >>>>> > > >>> >> >>>>> > Elan Ruskin gave a good talk on porting to consoles at GDC08. The > >>> >> >>>>> > slides are on Valve's website. There's something in there that > >> may > >>> >> >>>>> > help you here: > >>> >> >>>>> > > >>> >> >>>>> > #ifdef __GNUC__ > >>> >> >>>>> > #define MAXSI_THREADED_VARIABLE __thread > >>> >> >>>>> > #else > >>> >> >>>>> > #define MAXSI_THREADED_VARIABLE __declspec( thread ) > >>> >> >>>>> > #endif > >>> >> >>>>> > > >>> >> >>>>> > You may wish to use another define for windows rather than an else > >>> >> >>>>> > statement in case you wish to port it somewhere else in the > >> future. > >>> >> >>>>> > > >>> >> >>>>> > Also I agree, the Mac and Linux ports are incredibly similar. In > >>> > fact, > >>> >> >>>>> > on the Mac port a shell script is executed first to determine > >> whether > >>> >> >>>>> > it's running on OS X or Linux. > >>> >> >>>>> > > >>> >> >>>>> > Finally Linux could be a great consumer platform. Before it can > >>> > become > >>> >> >>>>> > this, it needs to learn that not everyone is a power user, and > >> make > >>> >> >>>>> > things simple. Learn from the Mac app bundles, and remove > >> reliance > >>> > on > >>> >> >>>>> > the command line (for example the output is shown on the update > >>> >> >>>>> > software). It scares normal users. That, and a lot of power users > >>> >> >>>>> > (like myself), don't want to have to rely on the command line for > >>> >> >>>>> > everything. > >>> >> >>>>> > > >>> >> >>>>> > On 13 June 2010 13:28, Jonas 'Sortie' Termansen > >> <hlcod...@maxsi.dk> > >>> > wrote: > >>> >> >>>>> >> I'd like to share a few experiences about porting code and > >> writing > >>> >> >>>>> >> portable code. Scroll down, if you just want my thoughts on how > >>> > portable > >>> >> >>>>> >> the Source Engine is. > >>> >> >>>>> >> > >>> >> >>>>> >> Recently I've been porting my in-development digital > >> distribution > >>> >> >>>>> >> platform to GNU/Linux for the fun of it. Naturally, most of my > >> code > >>> >> >>>>> >> didn't work right out of the box. But it is worth that several > >>> >> >>>>> >> subsystems actually worked at the first attempt, or with an edit > >> or > >>> > two. > >>> >> >>>>> >> For instance, my string system and parser classes/functions > >>> > compiled > >>> >> >>>>> >> right away. > >>> >> >>>>> >> > >>> >> >>>>> >> However, stuff like accessing the filesystem, multithreading, user > >>> >> >>>>> >> interfaces, networking, and so on didn't work because it relied > >> on > >>> > the > >>> >> >>>>> >> Windows API. The interesting part here is that POSIX does things > >>> >> >>>>> >> differently; but almost in the same manner as Windows. That means > >>> > for > >>> >> >>>>> >> each Windows API call you use, there is often one or more POSIX > >>> > calls > >>> >> >>>>> >> that does the same thing (if you add a little abstraction, that > >>> > is). > >>> >> >>>>> >> > >>> >> >>>>> >> Now, some of you heavily suggested the use of #ifdefs all around > >>> > the > >>> >> >>>>> >> code. You should not use #ifdefs each time you rely on platform > >>> > specific > >>> >> >>>>> >> behavior, but only in shared function calls or in headers. For > >>> > instance, > >>> >> >>>>> >> if you have to open a file. On Windows you can call the > >> CreateFile > >>> >> >>>>> >> function, while POSIX supports the open function. That means for > >>> > each > >>> >> >>>>> >> file opening, you need to write something like. > >>> >> >>>>> >> > >>> >> >>>>> >> #ifdef linux > >>> >> >>>>> >> int FileHandle = open(Path, Flags); > >>> >> >>>>> >> #elif defined(WIN32) > >>> >> >>>>> >> HANDLE FileName = CreateFile(...) > >>> >> >>>>> >> #endif > >>> >> >>>>> >> > >>> >> >>>>> >> Naturally, this isn't very pretty. And if this was used all over > >>> > the > >>> >> >>>>> >> Source Engine you would spend a lot of time writing #ifdefs and > >>> > checking > >>> >> >>>>> >> platform specific documentation. However, I am not saying #ifdefs > >>> > are a > >>> >> >>>>> >> bad idea. But instead of using them all over your code, you > >> should > >>> > move > >>> >> >>>>> >> them to a shared class or function that simply implements all > >> this > >>> > once. > >>> >> >>>>> >> In my code, I declared an abstract baseclass called > >> MaxsiFileSystem > >>> > that > >>> >> >>>>> >> implements all the common functions to access the local > >> filesystem. > >>> > So > >>> >> >>>>> >> now when I wish to open a file for reading, I would call: > >>> >> >>>>> >> > >>> >> >>>>> >> MaxsiHandle FileHandle = FileSystem()->OpenFile(Path, > >>> > MAXSI_FILE_READ | > >>> >> >>>>> >> MAXSI_FILE_SEQUENTIAL); > >>> >> >>>>> >> > >>> >> >>>>> >> This additional layer of abstraction makes it very easy to add > >>> > support > >>> >> >>>>> >> for new platforms as you just have to define a new child of the > >>> > abstract > >>> >> >>>>> >> baseclass. I have also added such a layer for my Window System. > >>> > This > >>> >> >>>>> >> means I call my own APIs in my actual code, and then it > >> redirects > >>> > it to > >>> >> >>>>> >> the Windows API or GTK+ depending on your platform. > >>> >> >>>>> >> > >>> >> >>>>> >> You might also have noticed I implemented a FileSystem() > >> function, > >>> > in > >>> >> >>>>> >> the same manner I have implemented a WindowSystem() function > >> that > >>> >> >>>>> >> returns the window system in use by the current function/class. > >>> > This > >>> >> >>>>> >> makes it easy to simply swap the window system on the fly. For > >>> > instance, > >>> >> >>>>> >> my source mod links against my distribution platform (LGPL) and > >> my > >>> > mod > >>> >> >>>>> >> then implements some of these interfaces. It could implement the > >>> >> >>>>> >> MaxsiWindowSystem class using VGUI and then my programs could be > >>> >> >>>>> >> natively drawn ingame with mininal work. > >>> >> >>>>> >> > >>> >> >>>>> >> Other porting issues includes how the VS compiler breaks a lot > >> of > >>> > the > >>> >> >>>>> >> C99 standard. To counter this, I have simply declared a lot of > >>> > macros in > >>> >> >>>>> >> my header files that replaces platform specific behavior. #defines > >> are > >>> >> >>>>> >> very powerful for this. For example, to declare a thread- specific > >>> >> >>>>> >> variable, I would use this header define: > >>> >> >>>>> >> > >>> >> >>>>> >> #ifdef __GNUC__ > >>> >> >>>>> >> #define MAXSI_THREADED_VARIABLE __thread > >>> >> >>>>> >> #else > >>> >> >>>>> >> #define MAXSI_THREADED_VARIABLE __declspec( thread ) > >>> >> >>>>> >> #endif > >>> >> >>>>> >> > >>> >> >>>>> >> And then use the MAXSI_THREADED_VARIABLE macro to declare each > >>> > threaded > >>> >> >>>>> >> variable. My experience is also that the GNU Compilers throw > >> much > >>> > more > >>> >> >>>>> >> errors and warnings than the Visual Studio compiler - and it is > >>> > often > >>> >> >>>>> >> right to do so. Visual Studio teaches you to write bad > >>> >> >>>>> >> standards-breaking code, even if you just compile using MinGW > >> you > >>> > will > >>> >> >>>>> >> get to fix a lot of issues that makes your code rather non- > >> portable. > >>> >> >>>>> >> (Like avoiding Microsoft-specific extensions to the C Library, in > >>> > some > >>> >> >>>>> >> cases.) But Microsoft did break the standard enough that you > >> might > >>> > need > >>> >> >>>>> >> to use some of the above methods for porting, just to get your > >> code > >>> >> >>>>> >> compiling using MinGW. > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> Now to return to the Source Engine. In my experience a lot of > >> stuff > >>> > in > >>> >> >>>>> >> the SDK code is already defined using interfaces, classes, and > >> such. > >>> >> >>>>> >> That means the actual porting issues have been outsourced to the > >>> > Engine. > >>> >> >>>>> >> This, in turn, means that the SDK code will be rather easy to > >> port > >>> >> >>>>> >> compared to the Engine. Fortunately, as the Source Engine > >> already > >>> > is > >>> >> >>>>> >> highly modular using interfaces, it is easy to just swap a DX > >>> > renderer > >>> >> >>>>> >> with OpenGL. As such, they already have the framework to make > >> their > >>> > code > >>> >> >>>>> >> work on new platforms - all they have to do is implement their > >>> >> >>>>> >> interfaces using the local system calls. If you start to do this > >> on > >>> > the > >>> >> >>>>> >> low-level interfaces and move upward, then soon your program > >> starts > >>> >> >>>>> >> working in all its glory. > >>> >> >>>>> >> > >>> >> >>>>> >> As for a Steam Client for GNU/Linux. It exists. I lost the link, > >>> > but it > >>> >> >>>>> >> seems that Valve uploads nightly builds of their Steam Client, > >> and > >>> > each > >>> >> >>>>> >> day it works just a bit better. Last I heard, the Steam Client > >>> > actually > >>> >> >>>>> >> logged on and the actual UI was partially drawn. I am not sure > >> why > >>> > Valve > >>> >> >>>>> >> is so silent about this - perhaps it's just experimental, or > >> they > >>> > they > >>> >> >>>>> >> to make a big deal about it, like they did with the Mac. > >> Seriously, > >>> > when > >>> >> >>>>> >> are they gonna shut up about it? Last I saw was that they made a > >>> > funny > >>> >> >>>>> >> TF2 comic about it. > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> Porting programs to Linux hasn't been very hard for me, though > >> it > >>> > is a > >>> >> >>>>> >> lot of work, if you want to do it properly. It seems that the > >>> > Source > >>> >> >>>>> >> Engine is already highly portable and GNU/Linux build doesn't > >> seem > >>> > too > >>> >> >>>>> >> difficult, as it seems from the nightly builds. There is no doubt > >>> > about > >>> >> >>>>> >> whether we need a client for GNU/Linux, it is just a matter of > >> time > >>> >> >>>>> >> before they announce and release it. > >>> >> >>>> > >>> >> >>>>> > Bucky > Bucky _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
