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 >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Bucky _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
