Page 1 of 7 123 ... LastLast
Results 1 to 10 of 64

Thread: Nextgen-software rendering

  1. #1

    Nextgen-software rendering

    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/


    It doesnt matter in which language are you programming. It matter what can you create in this language. I see the future of pascal in Free Pascal - the only free way for the future...

  2. #2

    Re: Nextgen-software rendering

    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
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  3. #3

    Re: Nextgen-software rendering

    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
    It doesnt matter in which language are you programming. It matter what can you create in this language. I see the future of pascal in Free Pascal - the only free way for the future...

  4. #4

    Re: Nextgen-software rendering

    i have got an access violation, screen:




    My cpu is an Athlon II M300, with SSE4A instruction set
    From brazil (:

    Pascal pownz!

  5. #5

    Re: Nextgen-software rendering

    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)?
    Vampyre Imaging Library
    Earth Under Fire (PGD Big Boss 3rd place)
    Domains Of Chaos (PGD Multiplexity 5th place)

  6. #6

    Re: Nextgen-software rendering

    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
    The views expressed on this programme are bloody good ones. - Fred Dagg

  7. #7

    Re: Nextgen-software rendering

    Quote Originally Posted by arthurprs
    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.

    Quote Originally Posted by 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)?
    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.


    Quote Originally Posted by 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
    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..
    It doesnt matter in which language are you programming. It matter what can you create in this language. I see the future of pascal in Free Pascal - the only free way for the future...

  8. #8

    Re: Nextgen-software rendering

    .. and Galfar... nice project with your image library.
    I am planing to use your image library instead of DevIL with your permission.
    It doesnt matter in which language are you programming. It matter what can you create in this language. I see the future of pascal in Free Pascal - the only free way for the future...

  9. #9

    Re: Nextgen-software rendering

    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
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  10. #10

    Re: Nextgen-software rendering

    Quote Originally Posted by 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
    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.

    It doesnt matter in which language are you programming. It matter what can you create in this language. I see the future of pascal in Free Pascal - the only free way for the future...

Page 1 of 7 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •