ATI supposedly payed 8 million bucks in order to "team up" with Valve, so I guess they're screwed enough just by that deal even without NVIDIA being involved. Especially since nobody has seen anything new from Valve since 3 months or so. I'll judge HL2 once it's out there and I'm not even sure that it's ever going to ship.
>thus encouraging developers to support the top- >of-the-line, high-profit-margin chips without >shutting out the huge installed base of older >chips
Nobody makes money with the top-of-the-line, because there is no high-profit-margin.
Well, the fact that Microsoft copied the Cg syntax verbatim into the DirectX 9.0 specification shows that Cg is not that proprietary but that there is already a vendor offering an alternative implementation of the language.
Cg itself is not open source as far as I know but NVIDIA supports people writing different backends for Cg. So if the Mesa folks wanted to write a backend that would compile Cg directly into Intel (vector instruction) machine code they could. However the right way to do it would be that Mesa implements support for the ARB_vertex_program and ARB_fragmen_program extensions writing a compiler that translates the "OpenGL FP and VP assembly" into Intel assembly.
Re:Platform independence! .. uh..no nvidia.. ati..
on
The Cg Tutorial
·
· Score: 3, Insightful
Wrong! Cg and also the Cg runtime are programmed on top of the standardized APIs OpenGL and Dirct3D. So Cg shaders work on any HW that supports these standard APIs. On top of that: Since it will probably take an other 200 years for OpenGL 2.0 to see the light of the world Cg is the only way to write high-level shader programs for OpenGL.
I worked for IBM in one of their 390 labs right after I graduated from college. All I can say is that I can perfectly understand that nobody with a good education in computers would want to work on these machines. The OS is pre UNIX, i.e. no hierarchical filesystem and files can not change their size dynamically. When you want to edit a new text file you have to create a file of defined size. If you run out of space you have to create a new file, copy your contents over and delete the old one. But this is not exactly true someone might say! Admitted. You can actually resize your file 3 times by an increment that must be specified at file creation. Very intuitive. Oh and the same people complaining about the filersizeing being not correct might say, that there is a hierarchy. Well, somewhat. It is possible to create a file that acts as a container for text-file only. So if you want to write a program and use several source files this is the way to go.
There also is no shell. Whenever you want to run a program you have to write a script in a completely cryptic job description language. There you have to specify how long the job should maximally take,...
So after spending 15min on writing your job-script you can finally run an ls command.
Now all this isn't quite true either. What I described is only true for the basic OS. You can purchase several layers of stuff that uses DB2 databases to create something like a filestructure and so on that makes things a little easier.
The next thing is that the 390 don't have floating point units which makes them completely useless for any scientific application or even simple numerical tasks.
Oh, did I mention that non of the 15 layers actually implements a GUI?
Oh and the speed of these machines is ridiculous. Even if you have 1 processor completely for you alone it's about half as fast as a comparably clocked PC.
One of the funniest things that happened to me was when I confronted my manager with the fact that OS/390 is not an API based OS (there is no defined set of C (or COBOL/FORTRAN functions for that matter) that can be uses to access OS features from applications. He managed to find a marketing brochure from the 70 that stated that OS/370 was an API based OS just like UNIX. The brochure defined API = Assembler Programmer Interface -- isn' that funny?
Did I mention that hard disks (DASD in 390 lingo) are not block devices as we know them? No, the OS exposes information about the number of tracks and segments on certain disk. The application programmer can then write code on how to write data to the segments. If you want to optimize file IO of your app you consult all the handbooks of all harddrives in the past and figure out how to best interleave write requests...
So if you're completely backwards and want to work in a stuffy, conservative environment with incompetent managers, then the mainframe word might be for you. If your into databases and corporate computing and don't want to work with the dinosaurs find a place that uses either Suns big UNIX servers or IBM Regattas. Both nice machines and UNIX got almost everything right that IBM got wrong with OS/360/370/390.
I was totally frustrated working on mainframes especially if you want to do some real programming.
Yes, it is possible, to use the GPU for non graphis operations. Using NVIDIA's Cg programming language to write vertex and fragment shaders is fairly simple. As long as your result data can be encoded into a 1,2,or 3 dimensional array (i.e. texture) you can read back the result easily.
I have not done anything completely non CG related but I just wrote a little app that uses the GPU to do image processing. It has convolution filters and non-linear filtering implemented as fragment programs (pixel-shaders) and runs completely on the GPU.
Gauss-filtering a 1024-768 image takes less then 1/10 of a second with a r=2 Grauss kernel.
Re:GTK-- is not GTK+
on
GTK-- vs. QT
·
· Score: 2, Informative
"[...] Qt is in a C++ like language that must be first preprocessed to produce C++."
First of all that is a serious exageration! Second it does not matter even if from a esthetical point if view the preprocessing of the headers is not nice. Why? Because the decision for a specific product/venor leads to vendor lock (see Anti Patterns) in any case.
You rely on a library. Your code will not compile if that library is not there! In the case of Qt you also rely on a little preprocessor program --- so what? If you use GTK or Win32 or MFC that don't need the preprocessor what is the difference? You cannot take your MFC program and compile it using say GTK.
The only thing you can do is to try to introduce clear layers that separate you program logic from the GUI to contain and localize the damage in case you have to go from one GUI library to another.
This is also my answer to the criticism that Qt (which was started in pre STL times if I am not completely wrong) uses non-STL containers. Separation of GUI and core program allow you to use more approprate/modern/protable technologies in the core. It is the architect's/designer's/programmer's choice where to use these non-standard constructs and how deep you will move into vendor lock.
Especially tricky in the case of Qt is that Troll Tech also offers a Qt specific abstraction layer for low-level constructs like threads/locks/sockets, etc. This means that if you are not carefull your software is locked at the top and at the bottom. If these low level services are used I would recommend to wrap them into a platform isolation layer. In the case you want to change you can replace these services using the native OS constructs or libraries like ACE, etc.
How can a project maintainer of a GNU project make a statement like this:
"I [...] can assure everybody that I consider none of the code I contributed to glibc (which is quite a lot) to be as part of the GNU project and so a major part of what Stallman claims credit for is simply going away."
At the time he started porting glibc to Linux (see article) it must have been cristal clear to Ulrich Drepper what the deal with GNU, GNU projects, the LGPL, and the glibc in particular were. In short it is about individuals making (many small) contributions to something that in the end is beneficial for a big group of individuals - call it user base, comunity, or society.
The GNU Project was the first of its kind and many similar free projects followed. The GPL and LGPL are constructed to protect this freedom, the basic idea of sharing. That is the reason why many of the follow-up projects chose this license - as the best possible protection for their code.
Making the above statement Ulrich Drepper, for me, becomes questionable as a project maintainer for glibc. His statement is a complete negation of the idea behind free software and GNU in particular. For him free software seems to be about claiming credit, not about sharing contributions (and I think it is more than ok that RMS claims a major part of the credit for Linux and that he wishes to see GNU mentioned together with Linux).
Ulrich Drepper seems not willing to continue playing by the rules that must have been clear to him, and that he accepted, when he started contributing to glibc, one of the core GNU projects. Even worse: Instead of walking away,now he doesn't like the GNU idea anymore, his statement makes clear that he wants to be in control of making the rules from now on and that makes me think that he must have lost his brain.
Personally I think that the post script to this release note was written in rage and that is wasn't really clear to Ulrich, what he was actually saying. But it still makes me sad to see that a brilliant developer like Ulrich looses control over himself to such a degree that he makes statements perverting his own contribution to GNU and GNU/Free Software in general.
"[...]no unix server can currently compete with even a middle of the road OS/390 machine for heavy server/transaction/database type workloads."
This would be true if you added "in a ultra-high-reliabilty environment". Fact is that not a single ISP uses S/390 systems for serving web content. If the IO of these machines would be so excellent, why don't they use them? What makes things even worse is the fact that serving web pages is similar to the IO load envisioned by Amdahl, namely relativly large chunks of data being tranfered. As a result even the terminals (3270) are based on transactions of this type. The user edits on the screen and commits changes every once in a while. This is very different to the character based aproach of Unix ttys.
"[...]a modern OS/390 the IO is handled by up to 1024 of these processers called 'channels'."
This is unclear to me. OS/390 is an operating system but you seem to make a statement about hardware. True is that 390-IO is based on a channel subsystem. All models from G3 through G7 (GA 2000) have 256 channels. Wrong is that a channel has something to do with a processor. A channel is an IO line with an interrupt on its own. Each of these channels may end in a channel controller. To the channel controller one can attach 256 subchannels. The subchannels end in a device. This makes a total of 64k devices.
A modern G6 has 16 processors (390 architecture). 14 for workload, 2 for the IO subsystem, 2 in case two of the others die.
"Nearly everything relating to transactions was done forst on an OS/390, databases in general, relational databases, messageing and queueing software, & etc. are all areas where the intial and continuing innovation took place on OS/390s"
True. One of the last "innovations" of DB2 on 390 was to optimize the data distribution on the harddisks depending on the speed of the movement of the HD heads. The last 390 harddisk physically built was a 4 Gig drive (I beleave it was called 3390 model 4) in the early 1980s. The disks had a diameter of almost 1 yard. Since then IBM simulated these 3390s through (SCSI-) disk arrays. The controlling software of these RAIDs introduce special waits to not disturb and crash DB2 that relies on specific timings.
The last disk logically defined was a 8 Gig drive. In case all 64k devices are 8 Gig drives this makes 512 TB storage. This will be a boarder very difficult to cross.
Is OS/390 innovative? All I know is that the OS/390 filesystem is non-hierarachical, i.e. does not know of directories! The filesystem is not block oriented. If you append data to the end of a file the file may overflow. This means that the user must create a new, bigger file and copy the old file into the new one and delete the old one.
Programs in OS/390 must be started using a special "scripting" language to supply parameters!
I could go on with this list. 390 were nice in the 70es. They still do a good job in some places that can afford them and need high reliability. All I'm saying is that the future belongs to a different kind of machine (definitly not 31bit like S/390) with a different kind of OS.
I have long been waiting for something like this beeing announced by IBM. They have had a long tradition in RISC development (RS/6000) but never really pushed this technology into the (buisiness-) server market. The reason was that their management decided to protect the S/370, now S/390 cash cow.
IBM politics was that certain techniques (like the ceramic multi-chip modules, copper process, etc.) were reserved for the S/390s. This was the reason why the RS/6000s with AIX were never really competitive (S/70 AIX server).
When SUN brought their E10000 server into shops IBM thought they'd never loose to SUN they obviously started changing their minds. The (RS/6000 based) 24 processor S/80 outperformes the 64 processor E10000.
This new POWER4 design makes clear that IBM favours modern Unix-based RISC servers over the old S/390 mainframes.
This is a good thing especially for IBM S/390 customer who start having problems finding talented people who want to work with dinosaur machines and OSes. (IBM also has major problems implementing new or even innovative software for the S/390s. Exception: Linux/390;-).
Better IBM offers them a safe way into the RISC/Unix world (we are looking at huge amounts of enterprise critical data sitting on all these S/390s) than when they try to migrate on their own.
I think some terms got mixed up a little in the previous posts. "S80 is SP/2 hardware" doesn't make sence. S80 is a RS6000 based Unix/AIX Enterprise Server. It is a 24-way symmetric multiprocessor. RS6000 is IBM's RISC architecture, very similar to PCC.
The SP/2 was a RS/6000 based numbercruncher. The machine that won the chess match agains Kasparow was SP/2 based. SP/2 is not a SMP machine but a cluster. The specific SP/2 machine is not built anymore. They call the series of machines just SP.
S390 is a totaly different processor architecture. Its design goes back some 30 years. Porting Linux to these machines has absolutely nothing to do with porting to the RS6000-based S-Series (S70, S80,...) or the SP-Series. A port to this architecture already exists. It's the PPC Linux Port. I've seen a S70 running Linux recently.
Slashdot Mirror
ATI supposedly payed 8 million bucks in order to "team up" with Valve, so I guess they're screwed enough just by that deal even without NVIDIA being involved. Especially since nobody has seen anything new from Valve since 3 months or so.
I'll judge HL2 once it's out there and I'm not even sure that it's ever going to ship.
You've got no clue.
>thus encouraging developers to support the top-
>of-the-line, high-profit-margin chips without
>shutting out the huge installed base of older
>chips
Nobody makes money with the top-of-the-line, because there is no high-profit-margin.
Well, the fact that Microsoft copied the Cg syntax verbatim into the DirectX 9.0 specification shows that Cg is not that proprietary but that there is already a vendor offering an alternative implementation of the language.
Cg itself is not open source as far as I know but NVIDIA supports people writing different backends for Cg. So if the Mesa folks wanted to write a backend that would compile Cg directly into Intel (vector instruction) machine code they could. However the right way to do it would be that Mesa implements support for the ARB_vertex_program and ARB_fragmen_program extensions writing a compiler that translates the "OpenGL FP and VP assembly" into Intel assembly.
Wrong! Cg and also the Cg runtime are programmed on top of the standardized APIs OpenGL and Dirct3D. So Cg shaders work on any HW that supports these standard APIs.
On top of that: Since it will probably take an other 200 years for OpenGL 2.0 to see the light of the world Cg is the only way to write high-level shader programs for OpenGL.
I worked for IBM in one of their 390 labs right after I graduated from college. All I can say is that I can perfectly understand that nobody with a good education in computers would want to work on these machines.
...
/370 /390.
The OS is pre UNIX, i.e. no hierarchical filesystem and files can not change their size dynamically. When you want to edit a new text file you have to create a file of defined size. If you run out of space you have to create a new file, copy your contents over and delete the old one. But this is not exactly true someone might say! Admitted. You can actually resize your file 3 times by an increment that must be specified at file creation. Very intuitive.
Oh and the same people complaining about the filersizeing being not correct might say, that there is a hierarchy. Well, somewhat. It is possible to create a file that acts as a container for text-file only. So if you want to write a program and use several source files this is the way to go.
There also is no shell. Whenever you want to run a program you have to write a script in a completely cryptic job description language. There you have to specify how long the job should maximally take,
So after spending 15min on writing your job-script you can finally run an ls command.
Now all this isn't quite true either. What I described is only true for the basic OS. You can purchase several layers of stuff that uses DB2 databases to create something like a filestructure and so on that makes things a little easier.
The next thing is that the 390 don't have floating point units which makes them completely useless for any scientific application or even simple numerical tasks.
Oh, did I mention that non of the 15 layers actually implements a GUI?
Oh and the speed of these machines is ridiculous. Even if you have 1 processor completely for you alone it's about half as fast as a comparably clocked PC.
One of the funniest things that happened to me was when I confronted my manager with the fact that OS/390 is not an API based OS (there is no defined set of C (or COBOL/FORTRAN functions for that matter) that can be uses to access OS features from applications. He managed to find a marketing brochure from the 70 that stated that OS/370 was an API based OS just like UNIX. The brochure defined API = Assembler Programmer Interface -- isn' that funny?
Did I mention that hard disks (DASD in 390 lingo) are not block devices as we know them? No, the OS exposes information about the number of tracks and segments on certain disk. The application programmer can then write code on how to write data to the segments. If you want to optimize file IO of your app you consult all the handbooks of all harddrives in the past and figure out how to best interleave write requests...
So if you're completely backwards and want to work in a stuffy, conservative environment with incompetent managers, then the mainframe word might be for you. If your into databases and corporate computing and don't want to work with the dinosaurs find a place that uses either Suns big UNIX servers or IBM Regattas. Both nice machines and UNIX got almost everything right that IBM got wrong with OS/360
I was totally frustrated working on mainframes especially if you want to do some real programming.
Yes, it is possible, to use the GPU for non graphis operations. Using NVIDIA's Cg programming language to write vertex and fragment shaders is fairly simple. As long as your result data can be encoded into a 1,2,or 3 dimensional array (i.e. texture) you can read back the result easily.
I have not done anything completely non CG related but I just wrote a little app that uses the GPU to do image processing. It has convolution filters and non-linear filtering implemented as fragment programs (pixel-shaders) and runs completely on the GPU.
Gauss-filtering a 1024-768 image takes less then 1/10 of a second with a r=2 Grauss kernel.
First of all that is a serious exageration! Second it does not matter even if from a esthetical point if view the preprocessing of the headers is not nice. Why? Because the decision for a specific product/venor leads to vendor lock (see Anti Patterns) in any case.
You rely on a library. Your code will not compile if that library is not there! In the case of Qt you also rely on a little preprocessor program --- so what? If you use GTK or Win32 or MFC that don't need the preprocessor what is the difference? You cannot take your MFC program and compile it using say GTK.
The only thing you can do is to try to introduce clear layers that separate you program logic from the GUI to contain and localize the damage in case you have to go from one GUI library to another.
This is also my answer to the criticism that Qt (which was started in pre STL times if I am not completely wrong) uses non-STL containers. Separation of GUI and core program allow you to use more approprate/modern/protable technologies in the core. It is the architect's/designer's/programmer's choice where to use these non-standard constructs and how deep you will move into vendor lock.
Especially tricky in the case of Qt is that Troll Tech also offers a Qt specific abstraction layer for low-level constructs like threads/locks/sockets, etc. This means that if you are not carefull your software is locked at the top and at the bottom. If these low level services are used I would recommend to wrap them into a platform isolation layer. In the case you want to change you can replace these services using the native OS constructs or libraries like ACE, etc.
At the time he started porting glibc to Linux (see article) it must have been cristal clear to Ulrich Drepper what the deal with GNU, GNU projects, the LGPL, and the glibc in particular were. In short it is about individuals making (many small) contributions to something that in the end is beneficial for a big group of individuals - call it user base, comunity, or society.
The GNU Project was the first of its kind and many similar free projects followed. The GPL and LGPL are constructed to protect this freedom, the basic idea of sharing. That is the reason why many of the follow-up projects chose this license - as the best possible protection for their code.
Making the above statement Ulrich Drepper, for me, becomes questionable as a project maintainer for glibc. His statement is a complete negation of the idea behind free software and GNU in particular. For him free software seems to be about claiming credit, not about sharing contributions (and I think it is more than ok that RMS claims a major part of the credit for Linux and that he wishes to see GNU mentioned together with Linux).
Ulrich Drepper seems not willing to continue playing by the rules that must have been clear to him, and that he accepted, when he started contributing to glibc, one of the core GNU projects. Even worse: Instead of walking away
Personally I think that the post script to this release note was written in rage and that is wasn't really clear to Ulrich, what he was actually saying. But it still makes me sad to see that a brilliant developer like Ulrich looses control over himself to such a degree that he makes statements perverting his own contribution to GNU and GNU/Free Software in general.
"[...]no unix server can currently compete with even a middle of the road OS/390 machine for heavy server/transaction/database type workloads."
This would be true if you added "in a ultra-high-reliabilty environment". Fact is that not a single ISP uses S/390 systems for serving web content. If the IO of these machines would be so excellent, why don't they use them? What makes things even worse is the fact that serving web pages is similar to the IO load envisioned by Amdahl, namely relativly large chunks of data being tranfered. As a result even the terminals (3270) are based on transactions of this type. The user edits on the screen and commits changes every once in a while. This is very different to the character based aproach of Unix ttys.
"[...]a modern OS/390 the IO is handled by up to 1024 of these processers called 'channels'."
This is unclear to me. OS/390 is an operating system but you seem to make a statement about hardware. True is that 390-IO is based on a channel subsystem. All models from G3 through G7 (GA 2000) have 256 channels. Wrong is that a channel has something to do with a processor. A channel is an IO line with an interrupt on its own. Each of these channels may end in a channel controller. To the channel controller one can attach 256 subchannels. The subchannels end in a device. This makes a total of 64k devices.
A modern G6 has 16 processors (390 architecture). 14 for workload, 2 for the IO subsystem, 2 in case two of the others die.
"Nearly everything relating to transactions was done forst on an OS/390, databases in general, relational databases, messageing and queueing software, & etc. are all areas where the intial and continuing innovation took place on OS/390s"
True. One of the last "innovations" of DB2 on 390 was to optimize the data distribution on the harddisks depending on the speed of the movement of the HD heads. The last 390 harddisk physically built was a 4 Gig drive (I beleave it was called 3390 model 4) in the early 1980s. The disks had a diameter of almost 1 yard. Since then IBM simulated these 3390s through (SCSI-) disk arrays. The controlling software of these RAIDs introduce special waits to not disturb and crash DB2 that relies on specific timings.
The last disk logically defined was a 8 Gig drive. In case all 64k devices are 8 Gig drives this makes 512 TB storage. This will be a boarder very difficult to cross.
Is OS/390 innovative? All I know is that the OS/390 filesystem is non-hierarachical, i.e. does not know of directories! The filesystem is not block oriented. If you append data to the end of a file the file may overflow. This means that the user must create a new, bigger file and copy the old file into the new one and delete the old one.
Programs in OS/390 must be started using a special "scripting" language to supply parameters!
I could go on with this list. 390 were nice in the 70es. They still do a good job in some places that can afford them and need high reliability. All I'm saying is that the future belongs to a different kind of machine (definitly not 31bit like S/390) with a different kind of OS.
IBM politics was that certain techniques (like the ceramic multi-chip modules, copper process, etc.) were reserved for the S/390s. This was the reason why the RS/6000s with AIX were never really competitive (S/70 AIX server).
When SUN brought their E10000 server into shops IBM thought they'd never loose to SUN they obviously started changing their minds. The (RS/6000 based) 24 processor S/80 outperformes the 64 processor E10000.
This new POWER4 design makes clear that IBM favours modern Unix-based RISC servers over the old S/390 mainframes.
This is a good thing especially for IBM S/390 customer who start having problems finding talented people who want to work with dinosaur machines and OSes. (IBM also has major problems implementing new or even innovative software for the S/390s. Exception: Linux/390 ;-).
Better IBM offers them a safe way into the RISC/Unix world (we are looking at huge amounts of enterprise critical data sitting on all these S/390s) than when they try to migrate on their own.
The SP/2 was a RS/6000 based numbercruncher. The machine that won the chess match agains Kasparow was SP/2 based. SP/2 is not a SMP machine but a cluster. The specific SP/2 machine is not built anymore. They call the series of machines just SP.
S390 is a totaly different processor architecture. Its design goes back some 30 years. Porting Linux to these machines has absolutely nothing to do with porting to the RS6000-based S-Series (S70, S80, ...) or the SP-Series. A port to this architecture already exists. It's the PPC Linux Port. I've seen a S70 running Linux recently.
True.