26 replies to this topic

[Mihail121]

he-hey! i wrote one too... don't i deserve a credit ??? :D

[Nick]

Yeah, it looks a lot like the rasterizer I've been using in swShader for years. But, you have a nice way of handling the triangle in two pieces!

Besides, the rasterizer using half-space functions isn't perfect you know. The trivial implementation looks really elegant and small but it has flaws and is slow. To get good performance (only slightly faster than the scanline rasterizer) I had to use many many tricks that make things a lot messier. And converting it to MMX/SSE is madly complicated, even though I have years of assembly experience. :blush:

[davepermen]

now i feel .. scared... NICK HAS PROBLEMS WITH ASSEMBLY!!

okay.. i definitely stay with raytracing for EVER. never looking back at rastericers AT ALL! :D

[anubis]

Quote

okay.. i definitely stay with raytracing for EVER. never looking back at rastericers AT ALL!

yeah man... thanks for ruining my life by getting me hooked up on this you bastard !!! it's your fault... just so that you know :D

[Nick]

davepermen said:

now i feel .. scared... NICK HAS PROBLEMS WITH ASSEMBLY!!

Hehe, I knew that was going to be interpreted wrongly. :rolleyes: The problem lies with SoftWire really. My automatic register allocator is currently unable to produce sufficiently efficient code. It puts things in registers that could really stay in memory, and vice-versa. So it creates a lot of spilling code (writing registers to temporary memory places to free them for other data), and also redundant copies (even though it uses copy propagation). I can add hints but that's not really elegant. The problem is more fundamental, in the way SoftWire works. It cannot look ahead at what data will be needed most, or even needed at all.

This problem has been there from the start, but it was never experienced as a problem before because the generated code was still close to optimal, with only tiny inneficiencies. With the new rasterizer and quad pipeline, register pressure is really high. Every single component requires a full SSE register. So storing two 4D vector per pixel means eight registers are needed per quad, that's all of them. It's obvious that even a simple shader uses more than two vectors, and then I'm not even talking about temporaries that are needed for the SSE implementation, or things like z and w and the gradients. So SoftWire has a really hard time keeping the most useful data in registers.

Anyway, don't panic, I know what needs to be done. I have to rewrite it so that registers aren't allocated immediately, but only when their associated variables are really used. Absolutely all register allocation operations (including copy propagation) have to be deferred to the very last moment. The implementation of it is very tricky since the generated code obviously has to be correct no matter what situation.

Either way, that was what I referred to when saying the assembly implementation is "madly complicated". It should be worth it though, because I still have good hopes it will be 50-100% faster than processing one pixel at a time...

[davepermen]

anubis said:

Quote

okay.. i definitely stay with raytracing for EVER. never looking back at rastericers AT ALL!

yeah man... thanks for ruining my life by getting me hooked up on this you bastard !!! it's your fault... just so that you know :D

you love it, you just don't wanna tell, right?

but it IS to love, and you know it! :D

[davepermen]

Nick said:

.....softwire bla......

okay, got the problem now. you changed very much your bottlenecks, and softwire was optimized for the old days..

but yes, it should give 50 - 100% speedboost for SURE.

and this will rock. it will be about the most optimal written software renderer ever.. and still 100% dynamic.

softwire rocks! :D

can't wait for the next swshader demos :D

i wish you, as always, all the best.. while i try to get my raytracing-stuff working :D (with softwire in, of course)