Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Nicolas Capens, posted on January 13, 2005




Image Description, by Nicolas Capens



It's been quite a while since I showed anything new here so I'll tease you with this cryptic development image of my project; swShader. The reason why I have been this quiet lately is not because I'm phasing things out, on the contrary, I'm too busy turning it into a finished product!

The image is a screenshot of the WHQL DCT, which is a free Direct3D conformance test suite from Microsoft. I've only recently started using it, but I expect it will be quite useful to test swShader's capabilities. The screenshot shows the simplest test of all, which checks whether pixels are filled correctly by comparing it to the reference rasterizer. Even with this simple test I detected a bug in the swShader render core and several in my Direct3D interface implementation. The good news is that things -can- now become practically bugfree.

Ironically, I was able to run a popular game before being able to run DCT tests! Of course most of you would rather see a screenshot of the game, but I'm keeping that for later to have a bigger impact. And let's face it, passing DCT tests is a more important breakthrough. ;-) I'm also in close contact with a company willing to invest in it so I can finally make some good money with it. That's probably bad news for anyone who wished to work with it for free, but I promise I'll keep contributing to the community as much as I can!

If you haven't already, please visit my new homepage for some more information: http://sw-shader.sourceforge.net

Best regards,
Nicolas "Nick" Capens


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Nick

January 14, 2005, 06:12 PM

One idea I'm considering to drastically increase fillrate is to render polygon edges at high resolution but do the shading at half resolution. This way a 1280x960 screen could show finely detailed geometry in the distance while big walls would just look a bit blurred at 640x480 resolution.

 
Scali

January 14, 2005, 06:21 PM



Nick wrote: The conclusion simply is that you don't need DirectX 9 hardware to use DirectX 9 effects. I already see people using the DirectX 9 interface for applications that would have worked fine with DirectX 7, but because everybody always wishes to use the newest API they neglect to support older hardware.


There's a difference between the DirectX 9 interface and DirectX 9 hardware.
Using the D3D9 interface doesn't mean you require D3D9 hardware. In fact, D3D9 allows you to do some things on D3D7 hardware that was there all along, but just wasn't exposed, like scissortest iirc.
Just look at HL2, it's a pure DX9 game (uses only the DX9 interfaces), but it has optimized renderers for D3D7, D3D8.0, D3D8.1 and D3D9.
Using the newest API can also be good for older hardware. The only exception is hardware that is too old to support the minimum driver requirements. But even on those multi-GHz Celerons you should never find that hardware, since even the Intel Extreme supports DX9.

Also, developers may not want to worry about hardware at all, but that is not a reality yet. I suppose they'll just get an extra thing to worry about if some people want to use their software with a software renderer (it will be orders of magnitude slower than hardware, so extra care must be taken to make sure the application is still usable, and behaves properly).

 
Nick

January 15, 2005, 04:08 AM

Scali wrote: There's a difference between the DirectX 9 interface and DirectX 9 hardware...

I know, but still people start using DirectX 9 features even if they could work without them. For example, nearly all DirectX 9.0c SDK samples use pixel shaders, so they don't run at all on my Intel Extreme Graphics 2. But most of these do things that are possible with the fixed-function pipeline as well. HLSL is also getting very popular but it excludes anyone with older hardware.

 
Nick

January 15, 2005, 04:18 AM

Won wrote: You know what would be interesting: if you extended SoftWire and swShader to use x86-64. Having twice the registers might give you some nice benefits. Also, multiprocessor Opterons scale in bandwidth as well as computation, and might make an interesting hardware platform. Maybe you can get AMD or something to sponsor you or something. :)

I'm saving for an Athlon 64 system as fast as possible so I can add these features. I'm also very much looking forward to dual-core processors because then the gap between graphics cards and CPUs will stop widening so fast.

Currently I don't have a penny though...

 
Joakim Hårsman

January 15, 2005, 06:43 AM

You could always try to get AMD to sponsor you. As long as you can provide some nifty software DX9 demo that they can show at trade shows it might work. Intel used Heaven 7 to showcase their CPUs a couple of years back, and hw often sponsor modders to build neat cases they can show off with.

 
Scali

January 15, 2005, 09:30 AM

Well the point of the DXSDK samples is obviously to demonstrate the new features :)
In some cases they just demonstrate the same thing as in older SDKs, only in new ways. It would be rather pointless for the DX9 SDK to include only DX7 samples, would it not? Just download the DX7 SDK instead.

And HLSL works for all shader models, even ps1.1 (although it's rather cumbersome). But even for non-shader cards, you can code vertex shaders with HLSL, and get reasonable performance. So you still don't need DX9 hardware for using HLSL.
Anyway, non-shader cards will be phased out soon, even Intel offers ps2.0 on their integrated graphics now.

 
Nick

January 15, 2005, 04:47 PM

Scali wrote: In some cases they just demonstrate the same thing as in older SDKs, only in new ways.

Exactly. People love using the newest API even if an older one would have worked fine. And in rare but existing situations, a software renderer would work fine as well. So I combine maximum compatibility with the newest API.
Anyway, non-shader cards will be phased out soon, even Intel offers ps2.0 on their integrated graphics now.

Unfortunately a hardware upgrade is not like installing new software. Systems without ps 2.0 graphics are still sold in big quantities today. And it will take another 3-5 years before these newer graphics chips will be standard. swShader can be installed - today. Every month a new version will be released with new features and better performance.

Anyway, there's no point ending up in a discussion like this again. I don't need a big market to keep this product alive. And don't worry, it does exist.

 
Scali

January 15, 2005, 05:00 PM

Nick wrote: Exactly. People love using the newest API even if an older one would have worked fine.


I fail to see the link between an example for the SDK of a new API and the preference of people for that new API and the specific new technique.

Unfortunately a hardware upgrade is not like installing new software. Systems without ps 2.0 graphics are still sold in big quantities today. And it will take another 3-5 years before these newer graphics chips will be standard. swShader can be installed - today. Every month a new version will be released with new features and better performance.


Where can I get my new copy of swShader then? I only have an old version, which doesn't support a lot of what I consider core-features of DX9. Think of vs/ps1.x support, cubemaps, AA/AF, robust and fast support for stencilshadows etc.
In short, the swShader I have doesn't run any of my current DX9 code properly (which includes code that actually runs on eg Intel Extreme and GF256 cards).

Anyway, there's no point ending up in a discussion like this again. I don't need a big market to keep this product alive. And don't worry, it does exist.


If there's a market, you're going to need developers. Feel free to offer me a job. Looks like swShader needs a lot of work anyway, to achieve your goals.

 
shadowman131

January 16, 2005, 03:31 AM

Scali, for what it's worth, he's completely right.

I bought my laptop last december, 64 meg graphics without shaders of any kind. And anyway, Softwire and swShader are coming along at extraordinary rates given all of the nitpicky holes Nick has to fill with a software renderer. PLUS, my high school computer lab has two graphics cards, TNT2's, out of 65 computers even though they all have ~1.6 ghz processors. swShader would run programs better than their integrated cards, that's for sure.

Speaking of which Nick, are you going to dual-license for both OpenGL and DX? Or just DX?

Edit: When I said dual-license there, I really meant make an OpenGL version too :P

 
Nick

January 16, 2005, 04:41 AM

Scali wrote: I fail to see the link between an example for the SDK of a new API and the preference of people for that new API and the specific new technique.

Then I can't help you.
Where can I get my new copy of swShader then? I only have an old version, which doesn't support a lot of what I consider core-features of DX9. Think of vs/ps1.x support, cubemaps, AA/AF, robust and fast support for stencilshadows etc. In short, the swShader I have doesn't run any of my current DX9 code properly (which includes code that actually runs on eg Intel Extreme and GF256 cards).

You have to be patient.

I deliberately made this IOTD a teaser with a rather boring screenshot of the DCT instead of one of the games I'm able to run. Yes, there are still features to be added, optimizations to be implemented and bugs to be fixed. But if this screenshot is not an idication to you that things are going into the right direction then again I can't help you.
If there's a market, you're going to need developers. Feel free to offer me a job. Looks like swShader needs a lot of work anyway, to achieve your goals.

Are you implying I'm not a developer?

You gave arguments why swShader would have no or too small a market and now you want to join me? It's fine if you don't agree with everything I say but please try to stay coherent.

Besides, you very well know I'm a student, and I'm broke. How am I supposed to employ anyone with a total capital of, let's see... 250 euros? Oh I'm a few months late with rent too.

Last but not least, I've been working on software rendering technology since 2000. While those first years I did lots of experimenting with varying success, in the last year or so I've been working very focussed. So trust me, I have the knowledge and experience to know how to finish this product. And you're not the first person I would trust to 'help' me with that, or should I? Besides, I work bottom-top and I'm about 75% done (the hard part) so let me do that last 25% too ok?

 
Nick

January 16, 2005, 04:51 AM

shadowman131 wrote: Scali, for what it's worth, he's completely right.

It's certainly worth something to me. Thanks!
I bought my laptop last december, 64 meg graphics without shaders of any kind. And anyway, Softwire and swShader are coming along at extraordinary rates given all of the nitpicky holes Nick has to fill with a software renderer. PLUS, my high school computer lab has two graphics cards, TNT2's, out of 65 computers even though they all have ~1.6 ghz processors. swShader would run programs better than their integrated cards, that's for sure.

Exactly the kind of systems I'm aiming at...
Speaking of which Nick, are you going to dual-license for both OpenGL and DX? Or just DX?

Currently the plans are to finalize the DirectX 9 version this summer. After that there's a big chance I will work on an OpenGL 2.0 interface. That should really only take a few months to since it's a rather thin layer on the swShader core.

 
Scali

January 16, 2005, 07:07 AM

TNT2 is indeed hopeless yes.
Intel Extreme however supports dot3 and cubemaps, so you can do per-pixel lighting on that with multipass.
Like this old IOTD: http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63620
And you will see it runs significantly faster than a ~1.6 GHz computer can run the swShader demo with the same shading model (I should know, I wrote both).
So I think this would be a better way to go with these videocards.

 
Scali

January 16, 2005, 07:14 AM

Nick wrote: Then I can't help you.


So there is no link.

I deliberately made this IOTD a teaser with a rather boring screenshot of the DCT instead of one of the games I'm able to run. Yes, there are still features to be added, optimizations to be implemented and bugs to be fixed. But if this screenshot is not an idication to you that things are going into the right direction then again I can't help you.


Well I still want to see some of my older stuff working in swShader, and then I want to see if there are any CPUs on the planet that can actually beat the performance of an Intel Extreme.

Are you implying I'm not a developer?


I'm implying you're not developers.

You gave arguments why swShader would have no or too small a market and now you want to join me? It's fine if you don't agree with everything I say but please try to stay coherent. Besides, you very well know I'm a student, and I'm broke. How am I supposed to employ anyone with a total capital of, let's see... 250 euros? Oh I'm a few months late with rent too.


You say that there's a market and there's a company supporting you.

Last but not least, I've been working on software rendering technology since 2000. While those first years I did lots of experimenting with varying success, in the last year or so I've been working very focussed. So trust me, I have the knowledge and experience to know how to finish this product. And you're not the first person I would trust to 'help' me with that, or should I? Besides, I work bottom-top and I'm about 75% done (the hard part) so let me do that last 25% too ok?


I don't see why you wouldn't trust me now, I've given plenty of help already over the years. I just had concerns that it wasn't commercially viable. You say it is, well, good enough for me.

 
Nick

January 16, 2005, 06:15 PM

Scali wrote: TNT2 is indeed hopeless yes.

It's reality that many systems do have graphics hardware like that. So if anyone wants to include those into the target market of their modest application which uses DirectX 9, an efficient software emulator is their only option to ensure full compatibility.
Intel Extreme however supports dot3 and cubemaps, so you can do per-pixel lighting on that with multipass. Like this old IOTD: http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63620 And you will see it runs significantly faster than a ~1.6 GHz computer can run the swShader demo with the same shading model (I should know, I wrote both).

I ran your PhongCar2 demo on my Intel Extreme Graphics 2 in 1024x768 mode and it reached 32 FPS. That's nice but not what I would call significantly faster. Let's not forget I'm using 32-bit floating point per color component here.

By the way, only the NMF file importer is yours for the swShader Per-Pixel Lighting demo. So don't try to make any early conclusions about relative performance. Only I know where swShader is heading and how much more it can be optimized.

 
Nick

January 16, 2005, 06:53 PM

Scali wrote: So there is no link.

Oh there is a link. Don't mistake the lack of a satisfying proof (for you) for a counter-proof.
Well I still want to see some of my older stuff working in swShader, and then I want to see if there are any CPUs on the planet that can actually beat the performance of an Intel Extreme.

You could have asked that in a nicer tone too... Besides, I'm not going to fulfill your demands simply because I want to reach my own goals first. And performance is of secondary priority to me now. I have a good estimate about how much more performance I can get so to save me of the pure evils of premature optimization I'm focussing on features first.

Anyway, there should be satisfying proof in my previous reply.
I'm implying you're not developers.

Then why are you implying I should be 'developers'? What makes you think I can't handle it on my own and what makes you think you can help? Note once again that I have advanced much further than just what you see in this IOTD.
You say that there's a market and there's a company supporting you.

In a couple of weeks you'll know what company it is. So feel free to apply and try to convince them of your crucial expertise in software renderers.
I don't see why you wouldn't trust me now, I've given plenty of help already over the years. I just had concerns that it wasn't commercially viable. You say it is, well, good enough for me.

Plenty of help, over the years? Could you make a list of that? You've got a signal-to-noise ratio of -40 dB. I get the same kind of inpiration from listening to my pet.

 
Scali

January 16, 2005, 07:56 PM

It's reality that many systems do have graphics hardware like that. So if anyone wants to include those into the target market of their modest application which uses DirectX 9, an efficient software emulator is their only option to ensure full compatibility.


Not that many. Intel Extreme graphics is by far the most sold GPU out there today, I think we're talking 60% marketshare here.

I ran your PhongCar2 demo on my Intel Extreme Graphics 2 in 1024x768 mode and it reached 32 FPS. That's nice but not what I would call significantly faster. Let's not forget I'm using 32-bit floating point per color component here.


Excuse me, but at the start of this thread someone claimed his 3000+ reached 30 fps in 1024x768. Now, that would roughly be twice as fast as the ~1.6 GHz machine we were talking about, right?
Note also that PhongCar2 is the GF2-version, try PhongCar3 or PhongCar4 (can't recall which, hard to tell on my PC anyway) for an optimized version for Intel Extreme. It reduces a pass because it takes advantage of the extra texture stages, may give some extra performance from the Intel Extreme.
As for 32-bit floating point... it doesn't make a difference here. In fact, my code is more correct than yours, see below.

By the way, only the NMF file importer is yours for the swShader Per-Pixel Lighting demo. So don't try to make any early conclusions about relative performance. Only I know where swShader is heading and how much more it can be optimized.


The shaders are based on mine too, you just cheated a bit. v0 and v1 are not non-negative integers in your implementation. So I don't think your version of the code is compatible with any ps2.0 hardware. Only ps3.0 has real floats for the diffuse and specular interpolators.
So if you would run actual vs/ps2.0 code, you'd probably get a few fps less.
Other than that you cheat too, you don't renormalize per-vertex nor per-pixel. So your code is neither as correct, nor as robust as the code running in my PhongCar2 demo.
I thought you just used my shaders, but apparently you hacked them. I wonder how well the real shaders would perform.
So anyway, why are you 'optimizing' shaders instead of swShader itself then?

 
Scali

January 16, 2005, 08:10 PM

Nick wrote: Oh there is a link. Don't mistake the lack of a satisfying proof (for you) for a counter-proof.


There's plenty of proof that a lot of people still support DX7 hardware with DX9 apps.

You could have asked that in a nicer tone too... Besides, I'm not going to fulfill your demands simply because I want to reach my own goals first. And performance is of secondary priority to me now. I have a good estimate about how much more performance I can get so to save me of the pure evils of premature optimization I'm focussing on features first. Anyway, there should be satisfying proof in my previous reply.


I'm waiting for cubemap support for how long now? Well over a year I guess. I even explained how to implement it step-by-step.

Then why are you implying I should be 'developers'? What makes you think I can't handle it on my own and what makes you think you can help? Note once again that I have advanced much further than just what you see in this IOTD.


If you've made so much progress, you're doing a great job of hiding it.

In a couple of weeks you'll know what company it is. So feel free to apply and try to convince them of your crucial expertise in software renderers.


If they hired you, that won't be too hard :P

Plenty of help, over the years? Could you make a list of that? You've got a signal-to-noise ratio of -40 dB. I get the same kind of inpiration from listening to my pet.


Still the same arrogant Nick, I see.
Let's see... from the top of my head:
- Explanation of cubemap support
- Test application + shaders, with a few discovered bugs in the shader assembler/rasterizer and suggestions on fixing them
- Advice on faster perspective mapping
- Advice on faster z/stencil state processing
- Advice on various depth-sorting approaches
- Advice on rasterizing in larger blocks
- Advice on implementing dsx/dsy instructions

I'm sure there's a lot more we've discussed, but you get the idea.

 
El Pinto Grande

January 16, 2005, 08:28 PM

Would someone hand me the chips while i watch the fight.
It's getting dirty, i like that.

 
Scali

January 16, 2005, 08:45 PM

For those interested, I quickly hacked the shaders of my original version into a version that should be compatible with the PhongCar demo you can download at http://sw-shader.sourceforge.net
See here: http://scali.eu.org/~bohemiq/PhongCarShaders.zip
For some reason the shaders don't seem to work 100% in the new version, I get some weird white aliasing here and there.
It shouldn't do that on hardware, and I don't think it did that in the 0.3.0 version.

 
Revolver

January 16, 2005, 08:50 PM

Yeesh, is this going to continue on *forever*? Is it really necessary to keep badgering the guy regarding issues that Really Don't Matter?

 
Nick

January 17, 2005, 02:51 AM

Scali wrote: There's plenty of proof that a lot of people still support DX7 hardware with DX9 apps.

Good. Since it's not everybody you admit there's a market for swShader. Small maybe, but that's not your concern. Argument closed.
I'm waiting for cubemap support for how long now? Well over a year I guess. I even explained how to implement it step-by-step.

Cubemaps are supported. I have no oblibation to make a demo of every new feature. Argument closed.
If you've made so much progress, you're doing a great job of hiding it.

Thank you. But if you had any idea at all how complex it is to be able to run DCT tests, you'd realize just how much progress I made. And that's only a fraction of what I did.
If they hired you, that won't be too hard :P

Yeah sure... good luck then!
Still the same arrogant Nick, I see.

Yeah, I know I get arrogant, when people claim they know everything but in fact have no proof or anything to compare with of their own. If you think swShader has no future, fine, it's not your problem. If you think you could do better, then show me your fantastic software renderer again.
- Explanation of cubemap support

Five minutes of your time compared to the -days- I've spend studying and implementing it? Is that your "plenty of help"? No? I'll read on then...
- Test application + shaders, with a few discovered bugs in the shader assembler/rasterizer and suggestions on fixing them

You're right, these things were so crucial they determined the future of swShader completely. Not!
- Advice on faster perspective mapping

Interesting. Tell me then, how did I implement per-pixel perspective correction at 1 clock cycle per pixel? Plenty of noise you provided here.
- Advice on faster z/stencil state processing

No. Implementing these as separate highly optimized passes was my idea.
- Advice on various depth-sorting approaches

Which are worthless compared to the batch sorting I'm using.
- Advice on rasterizing in larger blocks

Really? I seem to recall vividly how a furious fan you were of the scanline based rasterizer. Without proof.
- Advice on implementing dsx/dsy instructions

Oh you probably meant this thread: http://www.beyond3d.com/forum/viewtopic.php?t=6871&highlight=dsx+dsy. Wait a second, you didn't post there...

Arguments closed.

 
Nick

January 17, 2005, 04:12 AM

Scali wrote: Not that many. Intel Extreme graphics is by far the most sold GPU out there today, I think we're talking 60% marketshare here.

Good. I didn't mention any quantities. Just the fact that there are people with TNT2's is good enough for me. Anyway I'm catching up with the Intel Extreme Graphics 2 quite nicely as well. But even if not, I don't care.
Excuse me, but at the start of this thread someone claimed his 3000+ reached 30 fps in 1024x768. Now, that would roughly be twice as fast as the ~1.6 GHz machine we were talking about, right?

You mean twice as fast for a car that only faces the camera half of the time. Besides, you should realize that you're comparing to my oldest pixel shader demo. And you also know fixed-point precision is much faster. So where's that significant performance advantage again?
Note also that PhongCar2 is the GF2-version, try PhongCar3 or PhongCar4 (can't recall which, hard to tell on my PC anyway) for an optimized version for Intel Extreme. It reduces a pass because it takes advantage of the extra texture stages, may give some extra performance from the Intel Extreme.

PhongCar3 renders at 35 FPS, PhongCar4 at 30 FPS.
As for 32-bit floating point... it doesn't make a difference here. In fact, my code is more correct than yours, see below. The shaders are based on mine too, you just cheated a bit. v0 and v1 are not non-negative integers in your implementation. So I don't think your version of the code is compatible with any ps2.0 hardware. Only ps3.0 has real floats for the diffuse and specular interpolators.

I'm cheating because I use -higher- precision? There's no compatibility problem at all since the integer still fits inside the mantissa. And current hardware implements ps 1.x shaders with floating-point registers as well.
So if you would run actual vs/ps2.0 code, you'd probably get a few fps less. Other than that you cheat too, you don't renormalize per-vertex nor per-pixel. So your code is neither as correct, nor as robust as the code running in my PhongCar2 demo.

Adding two nrm instructions to the pixel shader results in a performance drop from 41 FPS to 39 FPS. This illustrates perfectly just how much headroom I have for optimizations.
I thought you just used my shaders, but apparently you hacked them. I wonder how well the real shaders would perform. So anyway, why are you 'optimizing' shaders instead of swShader itself then?

Because at that time I was writing an article for ShaderX 2 and I had to finish a demo. So I didn't have the time for new core features and I used every reasonable trick to increase the framerate. Happy now?

 
Nick

January 17, 2005, 04:17 AM

Scali wrote: For those interested, I quickly hacked the shaders of my original version into a version that should be compatible with the PhongCar demo you can download at http://sw-shader.sourceforge.net See here: http://scali.eu.org/~bohemiq/PhongCarShaders.zip For some reason the shaders don't seem to work 100% in the new version, I get some weird white aliasing here and there.

Congratulations. You just proved that my one year old proof-of-concept was 'just' a proof-of-concept.
It shouldn't do that on hardware, and I don't think it did that in the 0.3.0 version.

Indeed it shouldn't do that on hardware. In fact it wouldn't do anything at all on a TNT2 or Intel Extreme Graphics 2.

You're not getting anywere. Goodbye.

 
Scali

January 17, 2005, 05:57 AM

Nick wrote: You mean twice as fast for a car that only faces the camera half of the time. Besides, you should realize that you're comparing to my oldest pixel shader demo. And you also know fixed-point precision is much faster. So where's that significant performance advantage again?


No idea, I suppose my 1.6 GHz CPUs are slower than yours, and my Intel Extreme adapters are faster than yours. But everyone can test that for themselves ofcourse.

I'm cheating because I use -higher- precision? There's no compatibility problem at all since the integer still fits inside the mantissa. And current hardware implements ps 1.x shaders with floating-point registers as well.


No, you're cheating because you're using the diffuse/specular rgb interpolators as floats, while in reality they are only supposed to work in the [0,+1] range on any < SM3.0 hardware. Why do you think I wrote my code the way I did, packing the vectors to [0,+1] range?
Just read the specs.

Because at that time I was writing an article for ShaderX 2 and I had to finish a demo. So I didn't have the time for new core features and I used every reasonable trick to increase the framerate. Happy now?


No I'm not, actually. You claim you can run DX9-shaders in software, then it turns out the shaders you use are outside DX9 specs, with the side-effect that they are slightly faster than proper DX9 shaders.

 
Scali

January 17, 2005, 06:10 AM

Nick wrote: Thank you. But if you had any idea at all how complex it is to be able to run DCT tests, you'd realize just how much progress I made. And that's only a fraction of what I did.


Yea, I now see what you mean. The 0.4.0 rasterizer isn't quite up-to-spec.

Yeah, I know I get arrogant, when people claim they know everything but in fact have no proof or anything to compare with of their own. If you think swShader has no future, fine, it's not your problem. If you think you could do better, then show me your fantastic software renderer again.


I have no proof? Right... You've seen my rasterizers, you've used my advice, heck, you've even used the PhongCar test I made and released it as an official demo. You're not only arrogant, you're ungrateful and downright rude too.

Five minutes of your time compared to the -days- I've spend studying and implementing it? Is that your "plenty of help"? No? I'll read on then...


After my explanation, there wasn't much studying left. I pretty much spoonfed the whole thing step-by-step.

You're right, these things were so crucial they determined the future of swShader completely. Not!


Apparently they were crucial enough to release as a demo. In fact, the only demo that actually uses (what should be) DX9 shaders?

No. Implementing these as separate highly optimized passes was my idea.


I didn't say you took my advice on all counts. I did give it.

Which are worthless compared to the batch sorting I'm using.


Exactly the advice I gave.

Really? I seem to recall vividly how a furious fan you were of the scanline based rasterizer. Without proof.


Well as we know by now, my idea of a scanline-based rasterizer is far different from your idea.

Oh you probably meant this thread: http://www.beyond3d.com/forum/viewtopic.php?t=6871&highlight=dsx+dsy. Wait a second, you didn't post there...


No, that's right, I gave that (and other advice) through email.
Remember? I told you that rendering in 2x2 blocks was how hardware did it, and that there was no reason for software not to do it like that... Hey look, you use 2x2 blocks now!

Arguments closed.


Yes, I suddenly don't like discussing things with you anymore.
I don't like people who first ask advice all around (not just me, plenty of questions on B3D and other forums aswell), then accept help from others, and in the end pretend to have done it all by themselves, and even go as far as to claim that others don't have the knowledge or experience that you have, or that they can't prove that they could write such a rasterizer aswell. And here's the kicker: Because you've been working on rasterizing since 2000!

You can bet I'll be in touch with that company.

 
Nick

January 17, 2005, 07:01 AM

You forgot explaining how I perform per-pixel perspective correction in one clock cycle.

 
Nick

January 17, 2005, 08:34 AM

Scali wrote: I have no proof? Right... You've seen my rasterizers, you've used my advice, heck, you've even used the PhongCar test I made and released it as an official demo. You're not only arrogant, you're ungrateful and downright rude too.

There are numerous projects with a rasterizer like yours. I'm not impressed. Just live with it.

You agreed to share your NMF loader, and I credited you for it. I do am grateful for that, but only that. Don't act like you wrote the whole demo.
After my explanation, there wasn't much studying left. I pretty much spoonfed the whole thing step-by-step.

Wrong. It did take a lot of extra effort to implement correctly. Your spoonfeeding was limited to giving me commands. And I didn't need a lesson in the theory. In fact I didn't need anything at all. I implemented it when it was ready to be implemented.
Apparently they were crucial enough to release as a demo. In fact, the only demo that actually uses (what should be) DX9 shaders?

I was working on a demo anyway. In fact I already had the teapot demo with vs 2.0 and ps 2.0 shaders. You just provided me with a more interesting model and a matching normal map. And it was and still is a proof-of-concept. I never claimed full compliance back then.
Exactly the advice I gave.

Could you tell me then what batches I was talking about, how I produce them at minimal cost and how they are sorted?
Well as we know by now, my idea of a scanline-based rasterizer is far different from your idea.

Yes, and worthless.
No, that's right, I gave that (and other advice) through email. Remember? I told you that rendering in 2x2 blocks was how hardware did it, and that there was no reason for software not to do it like that... Hey look, you use 2x2 blocks now!

I already knew that hardware rendered 2x2 pixels in parallel. What I didn't have was a rasterizer to efficiently determine coverage of those quads. Right after my NVIDIA internship I derived the formulas and implemented them in assembly.
Yes, I suddenly don't like discussing things with you anymore.

That's a logical consequence of having no valid arguments... and having no goal.
I don't like people who first ask advice all around (not just me, plenty of questions on B3D and other forums aswell), then accept help from others, and in the end pretend to have done it all by themselves, and even go as far as to claim that others don't have the knowledge or experience that you have, or that they can't prove that they could write such a rasterizer aswell. And here's the kicker: Because you've been working on rasterizing since 2000!

I can ask for ideas all I want. Nobody is forced to give it. And on a public forum a idea becomes public property. The internet if full of ideas and most of it is for free. That's how it works. It's not worth anything until it's implemented. Besides, I believe I'm very generous by making most of it open-source, writing articles and helping other people on forums.

Mostly I start a topic on a forum when I already have an approach I want to try and I just seek confirmation or strong counter-arguments. What you did was flood me with with hundreds of things. Sure, some of it was useful, but if I was to try and compare it all I would still be working on the quad rasterizer today. Your arguments are just not coherent. So don't try to take credit for more than you're worth.

And yes I've been working on software rendering since 2000. I was a student then and I'm still a student. I did all of it in my spare time and five years ago I barely knew C. I gained a lot of experience over these years and it's not going to be easy for anyone to instantly catch up with that. So don't take it as an insult when I don't accept your claims without proof.
You can bet I'll be in touch with that company.

Good luck. How will you convince them of your expertise in software rendering?

 
Nick

January 17, 2005, 09:21 AM

No, you're cheating because you're using the diffuse/specular rgb interpolators as floats, while in reality they are only supposed to work in the [0,+1] range on any < SM3.0 hardware. Why do you think I wrote my code the way I did, packing the vectors to [0,+1] range? Just read the specs.

Oh come on! Just replace them by texture coordinate registers then. Works perfectly for that demo, without any noticable performance hit.
No I'm not, actually. You claim you can run DX9-shaders in software, then it turns out the shaders you use are outside DX9 specs, with the side-effect that they are slightly faster than proper DX9 shaders.

And that makes my claim that I can run DirectX 9 shaders in software any less true? This very IOTD is about the ability to reach full conformance.

Just tell me, what are you trying to get at?

 
Scali

January 17, 2005, 09:48 AM

Nick wrote: Oh come on! Just replace them by texture coordinate registers then. Works perfectly for that demo, without any noticable performance hit.


There was a reason why I didn't use a texcoord.

And that makes my claim that I can run DirectX 9 shaders in software any less true? This very IOTD is about the ability to reach full conformance. Just tell me, what are you trying to get at?


It just makes your demo invalid.

 
Scali

January 17, 2005, 09:58 AM

I thought you were through with this argument. I know I am.
You just made it into some silly flamewar.
You sure know how to impress people.

 
This thread contains 92 messages.
First Previous ( To view more messages, select a page: 0 1 2 3 ... out of 3) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.