ASM Community

Just mailed one of my previous computer architecture professors to see if he knows the answer. :grin:

Well, there's one specific thing you could help me with: bilinear filtering. :alright: It's my biggest bottleneck in the pixel pipeline. I have an implementation that uses five MMX multiplications and does mipmapping at the same time, which runs in 25 clock cycles. ;)

I'm afraid that 'cheating' has it's toll on quality though...

Sure, for some things you just need pure power. But let's not forget that the mainstream CPU now sold runs at 2.4 GHz and the mainstream GPU clocks at 250 MHz. Of course graphics cards have a lot of parallelism and are fully pipelined, but a lot has changed since we played Quake 1 on our Pentium 200 MHz!

Besides, I had a discussion with Michael Abrash a while ago about the Pixomatic software renderer being used for Unreal Tournament 2003 (which will also be standard in UT2k4). He was able to tell me that the changes to the (hardware targetted) 3D engine were very minimal, but Pixomatic uses no special overdraw reduction method like span-buffering!

My own Quake 3 renderer also doesn't use any software-specific optimizations: Real Virtuality.

Yes you can. Especially in situations where brute force is of little use. I see more and more games which require at least a Geforce 4 not because of any advanced features but just for performance reasons because they only use very basic culling. In this case a software renderer could use things like a HOM or cache all rendering calls to perform deferred rendering. That way you can still get acceptable framerates at modest resolutions.

No it isn't. With SSE, I can use the rcp instruction which executes in one clock cycle and gives me at least 12-bit precision. That is sufficient for all slightly further away polygons. For the near polygons I add one iteration of Newton's reciproke algorithm, to get 24-bit precision. So, for just a couple of clock cycles I get perfect perspective correction everywhere. Apart from linear interpolation (not doing perspective correction), I don't think there are many ways to beat that.

I used a similar method for the Pentium II for a while. But once I decided to completely step to SSE, I found out the setup of this trick took longer than actual per-pixel correction. So -that's- pure software rendering power delivered by the CPU!

Nowadays I use per-polygon mipmapping for distant polygons and polygons that are 'flat'. Again it makes almost no difference in performance if I use per-pixel mipmapping for the near polygons or not. This time it's not thanks to SSE but thanks to the bsr instruction which implements a log2 function.

I used to hand-code everything too. But it's way too limited and totally unmaintainable. At one point I had a few dozen shaders but only a handful actually worked. You might think that's due to bad programming practice, and you're probably partially right, but the big culprit was the method itself. You simply can't optimize tons of functions at the same time and test them after every step. If you change one simple thing, all the rest can break. A temporary solution was to use one file with a lot of preprocessor conditional directives but it became a huge file which was unmaintainable in itself. Then I started doing the same thing but now with inline functions and templates. This worked much better but the executable's size just kept growing exponentially when I added a single new option! Plus, I still had to instantiate all of these template function and write a huge 'switch' construct to select the appropriate function. And by now I was already stepping far away from the absolute hand-optimized code, because many basic operations had to read their input from memory and write it back to memory. You can say what you want, but this is two times too many mov instructions because in many cases everything can stay in registers. All in all, I can say this was a time when I thought a lot about giving up or just turning to hardware rendering where much of it is just controlled by single transistors.

But then I saw the light. First I wanted to glue together the binary code of the functions that would compose the pixel pipeline (Pixomati still uses this with several advancements, and calls it 'stitching'). It didn't work flawlessly (basically because I wanted too many optimizations at once), but it solved the problem of the huge executable. A caching system made sure I didn't have to do it a lot every frame. The next step was clearly to completely do the assembly compilation myself. A few months later I had a very well working prototype. It read an assembly file filled with conditional compilation directives much like I had done before. You can still see part of such a file on the main page of SoftWire. It was also the basis of the Real Virtuality demo, where the Microcode.dat file is an encrypted assembly file. But the problem of unoptimal register use was still there, and the file was too long even though I had support for include and macros but they were cumbersome to use because of the way I had to control the conditional compilation from C++. I even missed the syntax coloring I had in C++ files. :rolleyes:

So I took a radical new route, which I later called run-time intrinsics. They are C++ functions that have the same name as assembly instructions, and thanks to several C++ features it looks completely like assembly:

if(sampler[stage].mipmapFilter == Sampler::FILTER_POINT)

{

	shufps(xmm0, xmm0, 0xFF);

	mulss(xmm0, xmm6);

	cvtss2si(ebp, xmm0);

	bsr(ebp, ebp);

}

All these functions and their 5000 variants were automatically generated and hold the ID number to the instruction table (which in turn I had generated from the NASM manual). They don't execute the corresponding assembly instruction immediately, but store the code in a buffer. After all required run-time intrinsics are called, the buffer is used to compile and load the actual callable function. Now the conditional compilation is just a matter of C++ conditional statements and functions that neither have to be inlined or templetized. State management can be very elegant, as you can see above. Now only the problem of register use and basic optimizations remained.

But this is where run-time intrinsics become really powerful. Nothing prevents you from replacing the above registers with functions that return the register to be used. So I implemented linear-scan register allocation and the result looked like this:

if(sampler[stage].mipmapFilter == Sampler::FILTER_POINT)

{

	shufps(r128(&UV), r128(&UV), 0xFF);

	mulss(rSS(&UV), r128(&W));

	cvtss2si(x32(&lod), r128(&UV));

	bsr(x32(&lod), r32(&lod));

}

You can find all the code that uses this system in swShader. The syntax isn't the most elegant but in the code I'm working with at the moment there is no notion of registers any more. I also added linear-scan copy propagation, dropping non-modified registers and loop optimization. The clipper and rasterizer also benefits from it because it only executes exactly those instructions that are required for a specific vertex format. Just as an example how extreme you can go: I even made the pixel byte size (for stepping over the scanline) a soft-wired constant. So when you switch color depth it generates a new function. Without soft-wiring, you had to either read it from memory every time (wasting precious L1 cache space) or write several rasterizer functions just for this which is insane and unmaintainable.

So this is where things stand now. It's flexible, it's fast, it's doesn't break when you add or optimize a feature, it's all-round elegant to use. Not? :cool:

There is totally no reason why 89 D8 01 C8 would be two or more micro-instructions. Depending on the CPU's implementation (instruction merging) it could be one, in which case it would be theoretically as efficient as a RISC wich uses the 3-operand model. Ok I know x86 does have it's flaws, but if you look at from an abstract point of view, with all its flexiblity, I think it's not so bad after all and will survive for at least another decade (even in emulated form).

You still have to calculate the clock frequency in. If they added it to the x86 architecture, they had to lower the clock frequency. And not only the instructions that effectively use three operands would suffer from it, but also the ones that could execute in less time. That's the whole idea behind micro-instructions: splitting up operations until you have micro-instructions that take the same time to execute so you don't have any waiting time. It also comes at a price of course, but I think it's still proving itself. If there was any other desktop processor that performed twice as good as x86, I don't think this forum would even exist. :grin:

It is, but the decoder of a modern Pentium isn't really that horrendously complex. Especially if you put this in contrast with the enourmous flexibility you get, I think it's all worth it. With a fixed instruction length, you've quite limited in extendability. If x86 started off with a fixed instruction length, it would have been crushed by every other processor with modern instruction sets a long time ago. Otherwise we'd still only be using 16-bit. I'm convinced that a CPU without extendability can't stay competitive for very long.

Nothing comes for free. Making the best of it is all we can do. But on the other hand, we -can- make the best of it. Many other architectures don't allow this. You can either look at all the things we don't get with x86, or you can look at all the things we do get and have already gotten.

Wrong. It varies as 1/w?.

True, but computing these lines is computationally expensive, even if mipmap LOD varied linearly. And you don't always end up with triangles again which complicates things even more.

Subdividing is extremely inefficient. Not only do you have to scan many more edges, you also get shorter scanlines which are less efficient with the cache and you have to do some setup multiple times.

Sub-pixel correction is implicit if you use a DDA, and you always need axis-aligned gradients for that. So, you're right, there's no extra cost per triangle there, but it's still far from optimal to go subdivide polygons.

Besides, related to what I said before, it would only be the near polygons that would really get subdivided. And since it only takes a couple of clock cycles extra to do per-pixel mipmapping, it has the same effect with much less effort and possibly better performance. I like things to scale well, so often I prefer per-pixel methods if it's possible to make it efficient without becoming totally unreadable or unflexible. If I add anisotropic filtering tomorrow I don't want to have to rewite much of my rasterizer.

Anyway, this wasn't about fast bilinear filtering at all, was it? :wink:

I never ask the question if something is really necessary. It's not I who decides how to use the renderer. If someone uses it as a reference rasterizer, for CAD or just wants one primitive to have trilinear filtering, I don't want any limitations. The whole strength of software rendering is that anything is possible!

By the way, I once did a test with 100 texture lookups (try that with hardware in one pass), and performance was still above 1 FPS! :grin: So I think trilinear filtering would scale very well too.

Very impressive for a Java demo! :alright: So did you use any special tricks for the bilinear filtering is is the classical formula? Ferformance looks very close to when I enable SSE emulation. How did you get Java to perform this good? Or ar the JIT-compilers nowadys really that efficient?

Well, if shader compilers are all you think about besides classes and your social life, they will come to you! :wink:

I never wanted to compete directly with a Geforce 4. I'm just trying to provide an alternative for the pathetic integrated graphics cards, plus offer support for things that are normally only available on high-end cards. For example that Geforce 4 doesn't support vs/ps 2.0, I do! And a 10x factor in performance is excellent in my opinion, and I can only hope this gap gets smaller as CPU parallelism increases (multi-core, hyper-threading with extra execution units). Last but not least there are always situations where software rendering can beat hardware rendering.

Not far from your Java engine? Don't underestimate these guys please... they have to deal with far greater overdraw, transparancy, alpha testing, mipmapping and many different stage operations. Furthermore, I noticed some rasterization cracks in your demo. That's unacceptable in a professional product and you can be sure that it takes extra computations to get everything right. By the way, I hope you've experimented with the ini file to get the quality right? Standard settings are not that optimal.

What do you mean "just a software-game"? Just the fact that it is targetted only at hardware rendering makes me believe the big switch was made there. And every engine just looks like the previous but with some extras. I studied the Doom III alpha and there is no reason why it would be impossible to render it in software. And stencil shadows are no problem at all. First, it's only 8-bit per pixel, secondly, MMX offers insane parallelism on this level. So there's no doubt it can run at one or less than one clock cycle per pixel. For a 2.4 GHz CPU that's 2.4 Gpixel/s and only 2.4 GB/s bandwidth so if that isn't competitive with current graphic cards? It's exactly one of those situation where the CPU is more efficient than the GPU because it's not wasting so much time for a simple operation.

Never doubted that. I just wanted to react on your "per-pixel is insane" comment. It isn't insane if you use SSE, and it's even the most efficient and best scaling.

And what do you think polgons are like with a model that has 2000 and is only 200 pixels tall? And the trend isn't going to stop. But I use linear texture mapping in such cases anyway. :grin:

Run-time intrinsics give me all the abstraction I need. Plugging in a new algorithm, optimizing at a higher level, is a piece of cake. It's quite a lot harder to maintain your code if you're working with a dozen hand-optimized routines. Quite frankly I'd say there's not a single reason why to choose regular assembly above run-time intrinsics. I can just as easily optimize "performing the quickest operation possible" as much as "performing an operation as quickly as possible".

Then why does every game benchmark show that x86 still performs better? My guess is that the filter was just one specific example. I don't know much about the PPC's instruction set, but try to let it do a pavgb or pmaddwd. These instructions were added for specific algorithms that benefit a lot from them. I'm sure that once games run significantly faster on PPC, the x86 imperium would collapse. But until that day, I'm happy with ugly x86 because it does what I want it to do.

If they really are that much more powerful, then why aren't there x86 emulators, JIT-compilers and whatnot all over the place? Then after a transition phase, PPC would just totally take over. Ok, there's a lot more to it than that, but imagine Intel produced a modern desktop RISC processor. If x86 is really that inefficient it should be easy for them to use the JIT-compiler method. It's happened before with the far inferiour 68k. I can tell you, if it effectively would be better, it would already have been done!

Euhm, what are you trying to say? The formula is 1/w?, there ain't a way around that, and approximating it with 1/w (which you already have for perspective correction) or any linear approximation looks very bad.

I must admit I once tried something similar though. The idea was to calculate the mipmap level only every 16 pixels or so, keeping it constant in between. It worked, but resulted in zig-zag transition lines that were very clear to see. I reduced it to recalculating LOD every four pixels and it looked fine, but it wasn't faster. Sometimes you just can't approximate (any further) and expect it to look right and be faster.

Sure, you can triangulate those again. But that's yet another cost and added complexity.

Which brings me to another point... the mipmap boundaries are not straight. They are kindof radial. You don't see this on small polygons, but a big floor looks wrong without it. Here's one of my first screenshots with mipmapping: q3dm1.jpg. You can clearly see the mipmap transitions by altering your screen's gamma. I wouldn't find it acceptable if it looked any different. And I know the floor isn't one polygon, but then I just take advantage of constant mipmapping when a triangle's mipmap LOD doesn't change. And for the nearby polygons, it is -only- three more instructions as you can see in my previous post to perform per-pixel mipmapping. So any optimization is at most going to save the equivalent of one instruction. But all the added complexity, and having to interpolate more edges and more scanline setup makes me doubt it's all worth it. Subdividing polygons really sounds to me like a premature optimization that might work against you over time.

Yes, but only once. After that you just keep stepping discretely from one pixel center to the next. I found out this is faster than edge-aligned stepping with prestepping every scanline.

How can you light it (I mean, multiplying by diffuse, adding specular) before you have your filtered texel?

Well, first of all you need an impressive product. And yours is impressive, but I hate to tell you that real-time Java rendering has been done many times before and you even quote some products yourself. I'm sure it proves your interest in 3D rendering and Java, and you might get a job in this branch, but after reading a book like LaMothe's newest, anyone could copy it.

Advanced pixel shaders in software, completely compiled at run-time and optimized on the fly, that's something I haven't found anywhere else. I don't want to give myself too much credit, but I do think there's some brand new idea's in it, and it performs at a level that was considered totally unreachable for software rendering. And if you compare it with the reference rasterizer, an implementation written by professionals that work on it all day, I believe this is a nice achievement for four months of work aside my studies.

Secondly, and possibly more importantly, you need publicity. The scene isn't really surrounded by professionals looking for new talent. Have you tried gamedev, flipCode, beyond3d? I have, and everywhere I got very positive reactions. And the things that happen on these forums get spread around among professionals and if you're lucky one will contact you and if you succeed at convincing him of your qualities then you've hit the jackpot. :grin:

So, I wish you all the luck if you really want to go for it and if you know you're up to it! :alright:

Ok you do have a point there. My renderer has it's own specific interface, but I still want to create a Direct3D wrapper. It might not be the most efficient choice, but it will make it possible to reach a much bigger audience. Game companies rarely want to spend any time adding software rendering support, let alone adapt to -my- interface.

Pixomatic uses it's own interface in Unreal Tournament 2003 as well, but the calls were nearly directly compatible to Direct3D so the programmers got it completely working in just a few days. Mostly it was just disabling the advanced features. :grin:

I don't have UT2k3 on this system right now, but if I recall correctly the standard filtering just used upsampled mipmaps to fake bilinear filtering. But in the ini file you're able to choose the filter quality and change it to real bilinear!

I'm sorry but it's really Abrash who wrote the assembly code for Quake. Carmack is the brain behind the gameplay, which I admit was genious at the time. It's Quake that got me fascinated with 3D rendering.

It's not a matter of judging, it's a fact that UT2k3 has an overdraw of three on average, is filled with transparent objects and surfaces with alpha testing and has more than double the polygon count on a level than the average Quake 3 map. They used VTune all the way to get the absolute best performance. I certainly know they're not holy, but these are professionals who have done grapics programming all their life. So, again, don't underestimate these persons that you don't really know and which you're trying to measure up with.

Oh... Could you please point it out for me because it's not supposed to happen. Are you sure it's not a crack in the map?

Ok, no problem. I can only tell what I see!

Well, sure, from the current point of view there's nothing exciting about Quake 3 any more. But at that time I very well recall that people were totally amazed by it. And I still see a lot of engines today are based on the Quake 3 engine or similar technology. And if anyone said a a few years ago that it's all possible in software they totally wouldn't believe him. So that's why I think it's just as much a 'hardware' game today as it was back then.

In a few years or so, I'm quite sure that Doom III will have nothing exciting any more and making it run in software will be looked upon as trivial.

You know, this has puzzeled me for a while now too: it seems like everything new doesn't look as impressive any more. It's as if yesterday I was totally hooked up on spherical harmonic lighting and today it seems like I've known it for years. I don't have a complete explanation for the feeling but I think it's because 3D rendering is so popular nowadays that everybody wants to do it and it's not special any more. I try to resist that feeling though, and just continue with what I find exciting at the moment...

It's been a while since I looked at the algorithm, but I believe it's possible to do n lights in one pass if you have n stencil buffers. It's a nice example of a situation where using your own interface has great advantages. :o Wouldn't it be likely that next generation graphics cards and APIs support multiple stencil buffers as well? Clearly the current situation is sub-optimal for hardware as well.

A lot of things are for free on hardware, but not everything, and I expect this to get worse in the future. On the other hand, this means you'll only be 'paying for what you get'. The reason for this would be that the increasing programmability demands to get rid of the totally pipelined structure (you can't afford a dozen dividers in one pipeline) and share the resources. Surely a lot of the sub-operations will remain fully pipelined, and texture samplers will always be able to deliver a texel per clock. The GPU will remain faster than the CPU simply because it's designed for dedicated graphics tasks, but they certainly will look a lot more alike in the future. And when that happens, people with software rendering expericience will have certain advantages.

"Not doing something" is very relative. There's still setup required and you're still linearly interpolating, and you're risking that it only works well under specific circumstances. The rcpss takes just a -single- clock cycle, which is used most of the time, and Newton's reciprocal algorithm takes just four extra. But ok, let's assume you can do it in three per pixel. What is that going to change about overall performance if the whole pipeline takes 100 clock cycles? I know I have to start small but in my opinion there are a lot more productive things to do than get this optimal.

By the way, there's another reason why I think this can be categorized as premature optimization. Do you know how the psx/psy shader instruction works? Ignore the rest of the paragraph if you do. It computes the gradient of -any- shader register by looking at it's value in the surrounding pixels. In hardware, this is easy, because most implementations have four (or two times four) pipelines that run in parallel. They all work on the same 2x2 block of pixels, so when they all execute the psx/psy instruction at the same time, they just have to look at each other's value of the register to compute the differential. One very important use of it is mipmapping arbitrarily deformed textures. For example a 'swirl' effect needs a different mipmap level in the center than on the edges. This mipmap level has to be computed per-pixel and a fast way to get the texture gradients is to use the psx/psy instructions.

Supporting these instructions is crucial to make many per-pixel effects look completely right (else you get aliasing or blurring effects). But now we're not working with scanlines any more, but with 2x2 pixel blocks. So all the time you've spend optimizing the scanline based mipmap level computations, and probably also the perspective correction, is lost once you step to this method. Of course you can still use the old method if no per-pixel texture effects are used, but I hope you understand why I prefer spending my time on new things once I get satisfactory performance while keeping full flexibility, then standing still getting a performance increase that would have been possible by overclocking. ;) Trust me, I've done my share of week-long optimization of one tiny piece of code. only the bilinear filtering code was really worth it...

So there are no games that are properly optimized for x86 and PPC that can be used to convince people of the superiour RISC architecture? That's a real big shame. I mean, I'd be glad to admit its superiority if I see some hard numbers!

I did a bit of looking up and found out the PPC has out-of-order execution and several hundreds of intructions? Where's the line between CISC and RISC really? I have to admit the instructions look more coherent and general though...

You're almost making me believe it's a bunch of chimps working at Intel. :notsure: I know IDCT isn't a filter in itself, but it's one way to go implement one. Signal processing never was my favorite course. :sweat:

Ah, yes, I overlooked the problem of having different virtual memory models. But still, if the PPC was so much more efficient than x86, wouldn't that become of lesser importance? I really do want to believe you that it's more efficient but, and I don't mean this in the negative way, there seem to be a lot of excuses why they can't be directly compared to each other. And I understand the historical advantages x86 has but I find it hard to imagine that a superiour technology can't win from it.

Are you sure they would want Itanium for the desktop market? It's a really expensive chip to produce, and it's EPIC architecture is more optimal for workstation applications I think. Of course that could all change... Anyway, I'm placing my bet on extended hyper-threading and extra execution units for the next five or ten years. :alright:

Loops can be quite inefficient when jump misprediction occurs, which will happen a lot in this case. Ok I mustn't exaggerate this but there are other reasons which I've mentioned before why I wouldn't want this extra loop.

Hey I'm not trying to to annoy you. I actually like these discussions and I'm still very grateful that you've opened my eyes about the out-of-order scheduling!

Now where were we... Is it that you sample the texel for the next pixel while performing the lighting for the current pixel? I always found that a really interesting idea, but I never tried it. My main reason has always been that it would require extra copy operations. But since you've repeated so many times that the L1 cache is nearly as fast as registers, I feel forced to try it out. It's really trivial now to change my pipeline to try it out as soon as possible and tell you the results tomorrow. Thanks for the idea!

Ok that was probably a bit too rude of me. Of course it's not just copying from a book, it's applying all the theory and using it together with a lot of intelligent creativity to create new things. I've helped tons of newbies write their own software renderer but most of them just give up after a month because the math is too hard or because they can't find information about things they should actually be able to figure out by themselves. So yes, it requires a certain talent. And it's not like I think I'm the king of the world but I do think I have that talent and maybe more importantly, the perseverance. All my programming has always somehow been in relation to software rendering. When I developed SoftWire I wanted it to be an independent project but every feature I added was useful for software rendering. And I don't feel offended but I want you to know that LaMothe's latest book has learned me nothing new about 'Advanced 3D Graphics and Rasterization'. And I doubt if you find anything about run-time intrinsics in any book either.

Wow, wow, lean back! A discussion where people agree on everything doesn't make anyone learn anything, isn't it? So I'm sorry if you haven't learned anything from me yet but I think giving direct arguments (call it arrogance if you want) is an effective way to know where I'm right and where I'm wrong. And it's not because I don't agree on certain things that I don't respect you, because I certainly do. But I also like you to understand that I have been doing this stuff for nearly five years and some of the methods and priciples that have proven very useful to me are hard to let go off if you prove me they can be improved or are plain wrong. So please, give it a bit of time to let me experience things the hard way instead of just telling me it's this or that way and expecting me to believe you. I don't want to put you under any kind of pressure but some more examples and demos to show your theories work would give it a lot of extra force. Because, I myself have very often been wrong about something I've completely worked out in theory but which proved to have negative side-effects in practice. And I wouldn't be surprised if your mipmap sub-division theory has the same destiny...

About the 18 FPS, I'd like to stress that no optimizations have been made to reduce overdraw. It's a hardware-like brute-force rendering and Quake 3 was never designed for any software rendering. I'd really like to know what software engines would run circles around it while offering the same quality. Or you could teach me the hard way and write a faster one yourself after which you'd be my new god. ;)

Interesting. Could you help me find a link to their technology?

I'm sorry to dissapoint you. But may I ask what would have impressed you? And I don't think it would be fair to demand things you haven't already seen being done better.

Ok, first of all, Abrash is not my hero or idol but I do have a great respect for him. Secondly, I happen to have reference rasterizer code that I'm sure you do not have. And it is so horribly slow because of the tons of control statements, because it loads/stored every operand from/to memory and because it has it's own classes for 12-bit, 24-bit and even 32-bit floating-point emulation. Comparing that to run-time generated code where all conditional statements have been eliminated, registers are used optimally, and MMX/SSE is used for native support of adequate vector types results in more than 10x performance increase! It's not like it's suddenly useful as a replacement for high-end hardware, but it makes the reference rasterizer useful for more than generating just one image or testing shaders in 160x120 resolution.

Yeah people are hard to impress nowadays aren't they... :tongue:

Well, it's true, but seriously now, I don't know which IOTD it is so I'm not referring to it but you don't stand out in the crowd with things that have been done many times before. "I have a Direct3D demo" doesn't sound half as cool as "I have a new technology" even if that technology is just a trick in Direct3D. If you know you have something cool, wrap it up in a nice package. And don't be afraid to stand on the shoulders of others. Innovate, but don't reinvent the wheel unless it has nice chrome rims with per-pixel photon perturbation, euh, ... ;)

I wan't planning to, but now that you mention it... just kidding. :grin: But why are you so opposed to Quake 3 and Abrash and now Unreal?

How can you judge Pixomatic in UT2k3 if you haven't even seen it? I think that's pretty unfair. And yes, their demo from RAD Game Tools isn't that impressive. Their -real- demo is the UT2k3 renderer.

Again, why are you so looking down upon Abrash? It is he who invented the texture coordinate increment trick with sbb that executes in just five clock cycles per pixel in the innermost loop. There have been several talented people working with 3D software rendering at that time but I don't think anybody had a faster method. It's only simple -after- it's been done. It's like my linear-scan copy propagation algorithm. I searched long to see if something similar didn't already exist, but everybody seems to be using coalescing and such in a graph. So I worked on it myself and after a week of experimenting with methods that did not work or did not perform optimally I came up with an elegant solution that has only a tiny compromise. It's almost trivial when I look at it again, but you can trivialize anybody's work without truely realizing how much work went into it. And I'm not saying you can't reproduce that, but I would be very grateful that you can stand on the shoulders of such people and save yourself a lot of time and do more productive things.

Well at that time I was a newbie at graphics rendering, yes. But before that I've also done some work on a computer with a green screen I don't even remeber the name of, and on a Commodore 64 as well. I wrote a symbolical differentiator (to x) and drew the graphs which I could zoom in on interactively (adaptive refinement) until the point of numerical imprecision. :cool: None of it I found in books either, I had only just learned differentiation at school. And the first book I bough was Real-Time Rendering from Moller & Haines, after the Quake 3 demo when I had already started with swShader. It now servers as a little reference sometimes. Just two weeks ago I recieved LaMothe's book, and now it's only sitting there on my bookshelf just so I can say I have it. By looking at the table of content I knew it was going to be a waste of money before I bought it, so I'll just have to be happy with its pretty cover...

I've never seen chop liver have such a furious discussion with me, so I guess not. Care to tell a bit more about yourself?

I didn't say you can't, I just said you shouldn't underestimate anyone you're trying to compete with.

It's true. That demo doesn't show the full potential of Pixomatic. And I never said anyone's name has to be Abrash to be talented or experienced, I'm just saying he is is a great example of someone who is.

Ah, yes, you could be referring to two things: That Quake 3 level has a lot of tiny ledges. From certain angles it can look like cracks but if you get closer and look it it from above or below you see it's really thin polygons. A second effect is that in some places I should have used texture clamping so avoid that seams appear where two polygons with different textures meet. The information is stored in the shader files but I never bothered implementing it. I'm quite confident there are no real cracks caused by rasterization because I did various tests and the math is is discrete and exact in theory.

When you start the Quake 3 demo and turn around 180 degrees, there are 6000 polygons effectively being drawn, and there's 2.5x overdraw. So, no doubt your Java renderer is powerful, but who are you trying to fool? The lightmaps in Quake 1 are static, in the sense that they are premodulated with the texture and placed in a cache. Quake 3's lightmaps are dynamic, and you can't see it in my demo but I do sample and filter the lightmap at every pixel.

I fully agree that shadowmaps are far superiour. I once had a discussion about it at Beyond3D and the main reason why stencil shadowing is so popular is because it works on old hardware without precision issues.

Ok, one extra multiply per texture then. And eliminating these few extra instructions is going to make it super fast? And you still need the control for the sub-spans. Either you do it with an extra loop or you unroll it. The first solution requires extra inc/cmp/jmp instructions or so per pixel which makes the optimization rather pointless. The second solution also requires some setup but let's assume it's averaged out to less than a few clock cycles per pixel. Then you still have to deal with more jump mispredictions (a Pentium 4's 20-stage pipeline easily makes any optimization futile) and longer code. That's not really an option for my shader cache. So it's a balance of flexiblity and performance here as well. And like I said before I don't like spending my time implementing something that poses an architectural limitation that might later just become depecated. Per-pixel perspective correction works, let's move on...

Well if it's 100 clock cycles per polygon extra only then it would be fine. But there are things that have to be computed per scanline and new things to be done per pixel as well. You can't just move everything out of the inner loop. K.I.S.S. is also standard optimization theory.

I once tried to move perspective correction (here we go again) into a second loop back when I worked on a Pentium II. The main advantage was that loop unrolling was no problem and no emms was needed in the actual pixel loop. Luckily it did pay off and simple scenes were faster but there was one thing I overlooked... The z-buffer prevents that -any- further calculations are being done per-pixel. But with this extra loop I had no other choice than to compute perspective correction for every pixel. So in practice in a scene with overdraw it wasn't faster. I tried to solve the problem but every extra measure made the gains from a separate loop undone or marginally small.

Anyway, I tried sampling one texel in advance and got 48 FPS instead of 47 for a skybox scene. Might have been the wind...

I still think it's all very relative. A Pentium 4 core is already pretty much RISC-like, and the decoder is quite efficient to provide the required abstraction layer. Likewise, I don't think it's impossible that extended instruction merging could eventually become very much VLIW-like.

It's more elegant and requires less instructions to perform certain tasks, yes, but concluding from this that it's inherently faster...

That's very correct. But if a technology can keep on top for several years, only then people will start to realize it's worth investing in it. And with 'on top' I mean it has to run x86 with an emulator and beat it in every area! Otherwise we're just talking about a marginal difference that can be compensated by other technology and it's best to stick with x86 in that case. It's all about economics after all.

Like I said before, it adds a lot more side-effects than just a jump misprediction. All these negative effect may very well add up to 100 clock cycles, which corresponds to the single clock cycle you were trying to save per pixel. And even if you do have a speedup, it would be one "you'd never even notice". So I'm not going to spend my time on something that makes my code a lot less elegant and might limit me in the future.

Many other people don't, some do.

Looks sweet. Couldn't find any reference to run-time compilation though.

Wait a second. First you say you know several engines that would run circles around my renderer, and now you say it's an easy win because nobody does software rendering anymore. Ok then I guess...

As I said a few lines above, Quake 1 does only one texture. It also does mipmapping per polygon, has ten times less polygons in a map, uses a span buffer to reduce overdraw to zero and the BSP cells do not overlap and are completely convex. So, I'm quite sure it was pretty neat back then, but it's not like it's going to run circles around my renderer if it supported dynamic lightmaps, accurate mipmapping and high-poly BSPs with concave elements.

Recompiling that BSP so it has convex cells would make it have too many splits and a deep tree. Span-buffering isn't optimal for this situation you said yourself. And dynamic lightmapping and accurate mipmapping is not something you get for free either. The only thing that seems doable to me is create a map with portals like Unreal, to get rid of overdraw issues. But I have little interest in that because I love the stuff below the rendering API interface more. that's also why I won't make any engine-specific optimizations.

I'd honestly be thrilled to see it. Good luck with the automatic portalizer!

Yeah that's like your favorite football team saying "we could have won today be we didn't feel like it just to prove a point which we are sure of already". Seriously, any idea isn't worth a thing before it has been put into practice.

But I do understand you don't have the time or rather do something else. But then if I were you I wouldn't start claiming I can do this or that way better. I would just keep it for myself until I can prove it or make some suggestions that I am eager to learn about myself and be willing to admit if it was wrong.

Yes, for a Java engine it's pretty damn good and I don't think I've ever seen such performance before. :alright: But you have to stop claiming you could do better than me without showing anything. I'm very willing to believe you and admit I'm wrong but you won't get far with theory.

Well then, allow me to give you a rotten response as well. Until I see a demo of yours that proves me wrong, -I- am the one with the fastest Quake 3 software renderer. And the only person who at the moment I do believe can beat me is Abrash because he's doing something similar. All the rest is just a lot of moving air.

Because you wouldn't have said those ridiculous things about only being 10x faster than the reference rasterizer if you knew how it works. And the stuff below is even more convincing:

If you had the code you would have known that they did include several optimizations that must have taken some time to implement. Either that, or you're just playing stupid. So instead of just bluffing, prove it or admit it.

Humm, where do I get the pixomatic stuff? I do have UT2k3, and I'd like to see if the pixomatic plugin thingy is worth anything - the RAD GameTools certainly wasn't.

C0D1F1ED, your engine might be all fast and dandy etc, but the quake3 demo looks... bland and extremely washed-out. Try reducing the gamma? Would be a better show-off if it actually looked good ;)

And bruce-li, what about calming down a bit?

Why would they choose to do something else. Don't change a winning team. And there's not an endless range of game genres to work on. Id clearly focusses on first-person shooters, let others work on what they do best.

Do you know one person who didn't learn most of his knowledge from other people? Or maybe you were born with the same knowledge you know now? Besides, like I said before, an idea isn't worth anything until it has been put into practice. The most successful people in the world are the ones who put other people's ideas into reality.

I am not a newbie. And I do know stencil shadows. And as far as I know the Unreal engine has always run perfectly on multiple APIs. Many times when there's a problem it's actually a driver bug. So what makes you say it sucks?

Too bad but I was referring to UT2k3. Don't judge and underestimate things you don't really know.

Even if he wasn't the first one to use such instruction for texture mapping, he was still the first one to apply it in x86. Could you please show me a reference about the addx trick that dates LOONG time before '94? And he did a lot more work for Quake, like the artificial intelligence core. But I'm sure you find that trivial as well...

Yes I'm very interested. What's your age, what do you study, what's your real name, where do you live? It's great you're so good at all this but if you sign it with just Bruce-li, well, you'll be just as anonymous as the brilliant Amiga programmer who used addx for texture mapping. Or maybe it might have just been Abrash after all...

And before you ask: I'm 21 years old, I'm in the third year of civil engineering in computer science at the university of Ghent, my real name is Nicolas Capens and I live in Sint-Niklaas, Belgium but in the week I stay in Ghent.

Well then I still don't fully understand why you attack his work so personally. It might be just a feeling, but it's like he's done you something wrong, or you're just yealous of him.

He's not my hero. He's just one of the many persons I respect, something you don't seem to be able to do.

Nobody. What you see is what you get. At least I do have a Quake 3 software rendering demo. So who were you trying to fool again?

Sometimes it is. A Newton-Rhapson division approximation takes extra instructions but it's certainly faster than a one division at full precision.

Anyway, what I was referring to is that one extra instruction isn't going to kill performance. And if it makes my code more elegant and general I'm glad to sacrifice a little performance if that would really be the case. It's one of the reasons that made "premature optimization is the root of all evil" a famous quote. And before you try to 'win' this discussion again with things like changing subject and returning my question, yes I do know that's not totally exact the original words.

Yes, great isn't it? With that amount of overdraw and other inefficiencies in the Quake 3 rendering system being due to really being targetted at hardware rendering, it ain't bad at all. With portal clipping and fine-tuning some other parts of the render pipeline it should be possible to reach a stable 20 FPS or so. So, if I were you I'd start writing such engine right away so you can finally put some proof on the table.

I never said you need them all, did I? I even said "or so" to mean the most optimal combination for the situation.

Of course it's much slower! It's not using any SSE instruction. You don't have to convice me that without SSE it's much more efficient to do perspective correction every 16 pixels or so. I used it several times myself when I was developing on a Pentium II. Don't compare apples and oranges. Without SSE and per-pixel perspective correction it might have been a lot harder to get the flexiblity and performance I have now with swShader.

No, clearly you are the newbie, because the Pentium 4 actually has 28 stages if you count them all in, of which 20 are behind the trace cache thus are critical to jump misprediction. I hope this is where you start to realize that other things you've said might just be plain wrong as well. It's not because you were right about the out-of-order execution that all I say makes no sense. I started this thread with the best intentions of learning something new, and I'm thankful you showed me my error, but stop calling me naive and you might learn a few things yourself.

That's correct I've only really worked with x86. But it's not always the most optimal solution that wins. And I do believe x86 is a "good solution" if you look at everything is has accomplished. I'd be glad to admit another architecture is superiour if it proves so on all areas.

But "would" just ain't worth anything until it is proven.

Who's being arrogant here? I -have- a product. And it might not be the absolute fastest that is theoretically possible, it's still one of the fastest and most flexible in practice. And that's all that matters. You can't sell a bear's skin before you've killed the beast!

Fine, then keep it that way and just admit there ain't going to be any proof that shows my renderer is slow like hell.

And do you really think the tricks you've used in your "age-old code" still work today?

I admit. There's still a lot of work to be done. But many of the tricks you're trying to shove down my throat either don't work as well in my situation as you think they do, or are very impractical and limit the renderer's flexibility and future extendability. But I would be very pleased to accept any suggestions from people who do work on advanced software renderers.

Seriously, what makes you think you're in the right position to say "it could be done better" and not even prove anything of what you say? Yes, it's true it could be done better. But you're not helping me by saying none of it is impressive and your Java demo (which I honestly do find impressive in it's context) which only supports a few render modes would perform much better if it used SSE.

I decompiled the jar file and there was just a handful of triangle functions in it. My renderer supports 9720 render states for the fixed-function shader and I haven't even exponentiated that by the 8 texture stages. The triangle rasterizer and clipper support nearly the whole FVF of DirectX whitout any redundant loop or arithmetic operation and the vertex pipeline is evolving in the same direction. You can see most of it for yourself in the open-source part of swShader. Proof. Practice. Power.

I never said it's perfect. And I sincerely am a sensible person but if you could just show me the things you're saying have any truth you'd gain a lot of credibility. Else you're right, you shouldn't even bother because most probably it will just work less ideal than you think. What makes you have such an enourmous believe in your theories if you're not doing software rendering any more and I'm working on it every day? Why can't you just admit that you -could- be wrong because you can't even prove things for yourself?

Well that's really great for you but I'm not working on a Java renderer with the same goals so some different rules apply. All I want to say is that, for the things I aim for, my renderer is pretty damn efficient and very little of what you've said will contribute to that.

I don't think I know everything better. Quit trying to think what I think and using it as an argument. Start looking a bit more at yourself to see who is naive and arrogant.

Enjoy finding an excuse for the 28 stage pipeline.

For starters, because BSP trees haven't been exactly optimal since T&L hardware was introduced.
You don't seem to understand anything that I'm saying.



The point is passing other people's work off as your own.



Your 'optimizations' didn't exactly convince me, nor the fact that you think they would actually be feasible in software.



You must have missed the part where I said it rendered everything as dynamic geometry.



I only judged what I knew. And I knew Pixomatic's example programs didn't impress me.



Or maybe I'm Abrash, you never know.



Not me personally, but the way he tries to achieve fame over other people's backs and pretends he invented everything himself and he's so hot etc, doesn't exactly appeal to me.



I respect many people, Abrash is just not one of them, and I have my reasons.



Yea, but the alternative was not doing the division at all. Your friend Abrash uses this method aswell by the way, it's mentioned on the Pixomat page.



I'm not fooling anyone. You've seen my Java engine, that's the last software engine I made anyway, the most feature-filled one. I don't think I have anything to prove regarding software rendering, actually.



Yea, and how much extra time do you think some ACTUAL shading would take (hint: per-pixel dot3, pow, normalmap)? How much overdraw do you think stencil shadows will generate (hint: backface culling does not work)? What do you think about scenes that don't have rooms with an average of 12 polys (hint: T&L is VERY slow on CPU, compared to modern GPUs)? How often do you think portal rendering will work in general, besides Quake levels (hint: outdoor scenes)?
You did say you want a GENERIC engine, as a replacement for hardware?



Who's talking about 16 pixels? I use adaptive scanline subdivision, remember? In the best case I have 1 div per 'width' pixels. And you're saying that SSE is not slower than that? And what about Abrash? Using SSE, but still subdividing his scanlines?



Well if you want to continue dreaming, go ahead. I don't care. Just don't expect me to help you when you've realized that Doom3 doesn't work in your engine afterall, and you realize that you might need some tricks-of-the-trade that people such as myself could provide.



Erm, the demo only uses a handful of shading options, what's your point? Besides, I wonder if you even understand how my engine works in depth... Why don't you convince me by explaining it.
Why do you want to make a competition out of this anyway? We're not on the same level. You obviously don't know much about hardware rendering, and I am not really interested in software rendering anymore, because I've been there, done that, and went as far as I would like to go, in Java even.



Well that's just the whole point, isn't it? I mean, even after you've seen my Java renderer, you still doubt that I have any knowledge whatsoever about software rendering, and just assume you know everything better than me, so you basically don't even listen to any advice that I'm trying to give.
You want to make a contest out of this all the time... "My engine is the best".
We could have shared ideas and worked on making the perfect renderer together, but instead you just seem to want to prove that you're better than everyone else, and end up not getting any help. Is that sensible?

Yea, that's what I've been saying, and I think I can say that I speak from experience.
There are some things that you just don't want to do in software, or at least, not in the way that hardware does it.



Well, as I say, if you go from 0.001 fps to 0.01 fps, what does it really matter? "I have a faster slideshow-generator than you do!"?
You'll never be able to render something like Doom3/HalfLife 2 in realtime with it.
You'd get a lot further if you'd write a realtime raytracer for it :)