First, as the GP said, there is no fixed function pipeline on modern GPUs. When you submit a primitive (or a batch of primitives) with fixed-function functionality, the driver converts the current fixed function operations into appropriate shader programs and sends it on down the pipe.
Agreed. However, because the guys at NVIDIA don't have to write their code in CG or VP or HLSL, they may have access to some additional means of optimizations that take advantage of some lower-level assembly actually implemented by the hardware.
Secondly, the "fixed function pipeline" for vertex processing is ludicrously simple. There's actually really nothing that's done, save multiplying the vertices by the appropriate matrix (world * view * proj, in the usual case).
Funny. I thought it usually also does illumination, which can be complicated by two-sided lighting, for example.
Anyhow, I have had tests where loading the most trivial vertex program may cause a slowdown over using the standard OpenGL functionality. But I can't recall all the details of the test, so it may be that my conclusions are flawed. My conclusion was that there may be overheads associated with the use of user-written vertex programs that could stem either from lack of access to the most optimized programming level or from some other part of the driver related to having user-loaded programs running. I do understand that the standard programs run on the same hardware units and that there are likely different "fixed-function" programs for different settings of global state to avoid branching.
Sorting is not the problem to be solved. It is a piece of the solution to MANY problems. So for lots of problems you would like to solve on the GPU, you need to do sorting, and doing it on the GPU avoids constantly moving the data back and forth between the CPU and GPU.
It is important because sorting is an important algorithmic building block for solving many problems. If you want to solve important problems entirely on the GPU (which has many more GFLOPS available than the CPU, if you can manage to use them efficiently), then you need to be able to do the sorting component of those larger algorithms.
The most fair comparison in the study is really the comparison against previous GPU sorting implementations. This new work is clearly a big improvement in the state of the art in GPU-based sorting.
On the other hand, at least for the vertex processors, it does seem that running the "fixed function pipeline" is generally faster than loading your own program (especially if your own program tries to be as general as the fixed function program. I assume this is more due to specialized microcode rather than separate transistors.
It is true. The GPU floating point implementations are not IEEE compliant. There is an interesting study on the floating point behavoir of the GPU here (and the associated pdf)
It probably does run under linux. The main problem with GPGPU programs under linux (on NVIDIA) until recently was the lack of "render to texture" functionality. This meant that you had to render to a pbuffer and then do a copy operation to make that data a readable texture for the next pass. However, the latest NVIDIA drivers for linux support frame buffer objects, which provide the same functionality (and then some).
One guy even wanted to tell us that our relatives wouldn't be allowed to take pictures at our own fucking wedding!
Usually when a photographer says something like this, they just mean that they don't want your friends and relatives standing around taking photos of the posed shots the photographer is taking. Then the subjects are looking all over the place, flashes are going off from different directions, etc., and it can mess up the shots.
On the other hand, maybe the guy you are talking about was just nuts.
I've got a cheap Epson stylus color 777. The fact is, the epson print heads clog all the time, regardless of the ink, especially if you do not print frequently enough. One trick that works sometimes (besides running the head cleaning over and over again), is to clean the heads, let it sit for a few hours, and then repeat. This apparently gives the clogged ink a bit of time to dissolve or loosen.
Anyhow, I've used the inks from inksupply.com with good results. I think if you plan to use third party inks, you should use a brand that has a good reputation in online forums (e.g., alt.comp.periphs.printers), and not just the absolutely cheapest price (it is still MANY times cheaper than buying new cartridges).
It may be possible to set up a continuous ink system . I know, for example, that inksupply.com offers continuous flow ink systems that use some tube connections to feed the cartridge directly from bottles of ink. (but they currently only support Epson)
Slashdot Mirror
Thanks a lot! Now I've got milk spewing out of my nose. Do you know how hard it is to clean out all those nasal passages?!
Actually, let me go one step further. It still IS a great game. :-P
> Are you saying Tetris was a great game?? Yes.
I do wonder how much R&D went into Tetris. :-)
Does it really require a gang to do this in cyberspace?
Yes, my post was a bit haphazard...
First, as the GP said, there is no fixed function pipeline on modern GPUs. When you submit a primitive (or a batch of primitives) with fixed-function functionality, the driver converts the current fixed function operations into appropriate shader programs and sends it on down the pipe.
Agreed. However, because the guys at NVIDIA don't have to write their code in CG or VP or HLSL, they may have access to some additional means of optimizations that take advantage of some lower-level assembly actually implemented by the hardware.
Secondly, the "fixed function pipeline" for vertex processing is ludicrously simple. There's actually really nothing that's done, save multiplying the vertices by the appropriate matrix (world * view * proj, in the usual case).
Funny. I thought it usually also does illumination, which can be complicated by two-sided lighting, for example.
Anyhow, I have had tests where loading the most trivial vertex program may cause a slowdown over using the standard OpenGL functionality. But I can't recall all the details of the test, so it may be that my conclusions are flawed. My conclusion was that there may be overheads associated with the use of user-written vertex programs that could stem either from lack of access to the most optimized programming level or from some other part of the driver related to having user-loaded programs running. I do understand that the standard programs run on the same hardware units and that there are likely different "fixed-function" programs for different settings of global state to avoid branching.
Sorting is not the problem to be solved. It is a piece of the solution to MANY problems. So for lots of problems you would like to solve on the GPU, you need to do sorting, and doing it on the GPU avoids constantly moving the data back and forth between the CPU and GPU.
It is important because sorting is an important algorithmic building block for solving many problems. If you want to solve important problems entirely on the GPU (which has many more GFLOPS available than the CPU, if you can manage to use them efficiently), then you need to be able to do the sorting component of those larger algorithms.
The most fair comparison in the study is really the comparison against previous GPU sorting implementations. This new work is clearly a big improvement in the state of the art in GPU-based sorting.
On the other hand, at least for the vertex processors, it does seem that running the "fixed function pipeline" is generally faster than loading your own program (especially if your own program tries to be as general as the fixed function program. I assume this is more due to specialized microcode rather than separate transistors.
It is true. The GPU floating point implementations are not IEEE compliant. There is an interesting study on the floating point behavoir of the GPU here (and the associated pdf)
p.s. - if the grandparent was a joke that meant "can I run linux on the GPU", then I guess either my joke meter is broken or it just wasn't funny :-)
It probably does run under linux. The main problem with GPGPU programs under linux (on NVIDIA) until recently was the lack of "render to texture" functionality. This meant that you had to render to a pbuffer and then do a copy operation to make that data a readable texture for the next pass. However, the latest NVIDIA drivers for linux support frame buffer objects, which provide the same functionality (and then some).
Who compares cell phones based on operating system?
Umm.... nerds?
It is actually a fork of Judaism (claims to be the true prong of the fork) and hence claims to date back to Adam and before the creation.
Judaism does NOT claim to date back to creation.
I think that it can help to take better photos. But it won't turn you into a Pro.
No, but I would think it could help you learn photography faster, because you can see the picture immediately and make as many attempts as you like.
The only difference is that a professionnal photographer, unlike me, knows how to take good poses
Plus, using a photographer makes it easier for you to be in the pictures!
One guy even wanted to tell us that our relatives wouldn't be allowed to take pictures at our own fucking wedding!
Usually when a photographer says something like this, they just mean that they don't want your friends and relatives standing around taking photos of the posed shots the photographer is taking. Then the subjects are looking all over the place, flashes are going off from different directions, etc., and it can mess up the shots.
On the other hand, maybe the guy you are talking about was just nuts.
I'll still be buying 2600 with cash...
Uh, oh! Are they coming after Atari 2600 owners now?! Time to make myself scarce...
Well, MS has to expand its market *somehow*
(+1) funny, IMHO!
What idiots do you have to proof your servers against? :-)
Anyhow, I've used the inks from inksupply.com with good results. I think if you plan to use third party inks, you should use a brand that has a good reputation in online forums (e.g., alt.comp.periphs.printers), and not just the absolutely cheapest price (it is still MANY times cheaper than buying new cartridges).
Is each color in its own cartridge on your printer?
It may be possible to set up a continuous ink system . I know, for example, that inksupply.com offers continuous flow ink systems that use some tube connections to feed the cartridge directly from bottles of ink. (but they currently only support Epson)