Nextgen-software rendering

[herrcoolness]

Hey every one...
For first.. as i wrote on other forums.. my english is bad but i think understandable..

Ok now to the point.
I am writing in FPC a software renderer. My plan is to create 3d engine with integrated software rendering system. Rendering will go thru 3 deffered rendering stage's:
1. rendering depth and triangle id... good for first occlusion of pixels, objects, and for reducting texture access or pixel shading calculations,antialiasing
2. gathering information from rendered triangle pixels - reading material textures and
depth buffer and writing material attributes, and 3d pixel positions to a G buffer,
3. lightning and shadowing


For now i have:
- triangle rasterizer which draws the triangle on per tile basis (tile drawing increases cache hits).. i think the triangle rasterizer innerloop is nice optimized, but not the tile drawing...because i am in prototyping stage ..
(The idea is based on Nicolas Capens "Advanced Rasterization" article, but my algorytm is much faster, for example :
***i don't use rectangle traversal algorytm but algorytm more suited for tile scanlines of the triangle ,
***fast trivial accept and reject of tile vs triangle routines, where the idea is based on intel's document about larabee rasterization)
-hierarchical structure of tiles, for z-buffer occlusion (zmin-zmax-per tile),
later i use similar structure for g-buffer (but in 3d) tiles for faster rejecting and accepting of tile and light-volume-primitve in lighning stages ( cube-sphere, cube-cone checking)
-texture reading procedure prototypes
-sse4 instructions used, but fpc don't support them so i need convert some instructions to x86 byte code .. thnx to Nasm


I am playing with idea using NASM as ASM-JIT compiler because when you write a required raw instruction with registers (or memory pointer) without any header or additional info in to one file, the NASM compiler convert it to x86 byte-code and write it to output file. So i write in pascal a string with assembler program, write it to a file, execute nasm with this input file, i read the output file to memory, setup required call and variable pointers and viola... runtime-compiled procedure...

The page of my project http://sourceforge.net/projects/phenomenon/

[JSoftware]

Just add the instructions to fpc

Take a peek at x86ins.dat in the compiler/x86 dir. To use them in the internal assembler, you also need to add the code for it, but there are probably lots of examples you could look at there too

As for the engine, I get an access violation when I try to run the test

[herrcoolness]

The demo is in 1680x1050 resolution and in window mode using direct-draw interface.
What system do you have?
Your cpu supports sse4?
In the demo is just rotating quad with bilinear filtered texture .. just small test
and about the tip... i check it
.. i think.. next time, when i upload the source with demo... i reduce the resolution

[arthurprs]

i have got an access violation, screen:




My cpu is an Athlon II M300, with SSE4A instruction set

[Galfar]

Test demo runs at ~24fps on my 2.5Ghz Core2 Duo.

What about using for SSE2 instead of SSE4, at least for the demo (so people with older and/or AMD cpus can test it too)?

[czar]

didn't work for me either.. Double click test, screen flickers for a second I can see a box and then it stops. I am using a quad core intel with windows XP at 1680x1050

[herrcoolness]

i have got an access violation, screen:




My cpu is an Athlon II M300, with SSE4A instruction set

Thnx arthurprs ,the back-trace in the image helped me a lot to undersdand, where is the problem. There is just one place where i used sse4... and its in function "texturesampler_bilinear" in file "texture_calc_addr.inc".I readed, there is small incompatibility in sse4 instruction set between AMD and intel. I use intel quad-core. So for now the demo test will run just on intel processors, but i will change it.

Test demo runs at ~24fps on my 2.5Ghz Core2 Duo.

What about using for SSE2 instead of SSE4, at least for the demo (so people with older and/or AMD cpus can test it too)?

Gaflar, when the renderer will be complete, there will by more better processors,with sse5 or the larabee procesors. Its a long path which takes long time. Backwards compatibility can slow down the rendering because when i use 5 old instructions and not 1 new for doing the same thing.. its more work for the cpu. You know it. But i drop to sse3 because of the incompatibility in sse4 (4.1,4.2,4a) instruction set between intel and AMD or i will use only such like instructions, that are in both processors.

didn't work for me either.. Double click test, screen flickers for a second I can see a box and then it stops. I am using a quad core intel with windows XP at 1680x1050

Czar, there are 2 windows. one for graphical output and one (the console) for the text output. See in the console if there is an exception raised like by arthurprs. But the problem is you have intel-quad like i have, your card support 1680x1050, i have too XP.. If you can, upload pls the output of the console window like arthurprs.

Guys i learned little big more.. Thnx for the feedback..

[herrcoolness]

.. and Galfar... nice project with your image library.
I am planing to use your image library instead of DevIL with your permission.

[JSoftware]

Are you sure esi+tEXTURE_Header.addrcalc is 16-byte aligned? That could probably be the source of the problem

Mind you, I get the precisely same backtrace as arthurps on a 32bit core 2 duo

[herrcoolness]

Are you sure esi+tEXTURE_Header.addrcalc is 16-byte aligned? That could probably be the source of the problem

Mind you, I get the precisely same backtrace as arthurps on a 32bit core 2 duo

JSoftware i am using special sse_getmem,sse_freemem procedures which align pointer to the 16-byte boundary.

The texture header consists of "clampmin,clampmax,size:fvec4;wrapmask,addrcalc:iv ec4;". All this variables are 16-byte wide and the compiler is compiling all global variables in to 16-byte boundary's. See file "compilecfg.inc", there is compiler directive "{$CODEALIGN varmin=16}", which says to the compiler, that all global variables must be aligned to the 16-byte boundary. So qword, dword or byte variable is 16-byte wide too. So all variables can be easyly loaded with movaps and movdqa without an error or without to be mixed with other small (8,4,2,1 byte-wide) variables

.... aaand are sure, that your cpu support sse4? Because some intel-duo core doesn't support it.