Another raytracer.

[Stonemonkey]

something liek this:

Code: [Select]

sub render_thread(world as world_struct pointer)
    dim as integer x,y
    dim as single d
    dim as integer pointer display=world->display+(world->y_start*world->wwidth)
    dim as vector_struct pointer vector=world->vectors+(world->y_start*world->wwidth)
    for y=world->y_start to world->y_end
        for x=0 to world->wwidth-1
            *display=raytrace(world,vector)
            display+=1
            vector+=1
        next
    next
    world->busy=0
end sub

sub render_world(world as world_struct pointer)
   
    dim as integer y=0,i=0
   
    dim world_thread(0 to 3) as world_struct
    dim as any pointer thread(0 to 3)
    world_thread(0)=*world
    world_thread(1)=*world
    world_thread(2)=*world
    world_thread(3)=*world
   
    while y<world->height
        i=(i+1)and 3
        if (@world_thread(i))->busy=0 then
            (@world_thread(i))->y_start=y
            (@world_thread(i))->y_end=y+9
            (@world_thread(i))->busy=1
            thread(i)=threadcreate(@render_thread,@world_thread(i))
            y+=10
        end if
    wend
   
    threadwait(thread(0))
    threadwait(thread(1))
    threadwait(thread(2))
    threadwait(thread(3))
   
end sub

with the field   'busy as integer'   added to the world_struct type.

Does it in blocks of 10 rows at a time, the current values need the screen size to be some multiple of 10 in height.

[Jim]

You have to watch out for that - the while loop that is checking for busy is very tight - it has no sleep in it so it will take up 100% cpu doing very little.  The correct way to do this is to use semaphores, but I'm not sure FB supports them directly - you might have to use Windows API.
eg. Windows has a function that says
Sleep until one or more of the threads completes and then tell me which one(s) it was.

Jim

[Stonemonkey]

yep, i was wondering about that, i don't think fb can do that and sleep wouldn't be much help either.

[Stonemonkey]

Is it something like this:

Code: [Select]

WaitForMultipleObjectsEx(4,@thread(0),0,1,0)

added into the loop?

[Jim]

Yes, something very like that - then check the return code (or the busy flags of all threads) to see which one to start next.  Is it known whether FB's thread handles are compatible with Windows ones?

Jim

[Stonemonkey]

I have no idea and i'm just trying to make some sense of the standard access rights although i'm just looking at it kind of blankly atm.

[Stonemonkey]

Something I'm not to sure about is bAlertable, the description is a little confusing.

[Jim]

Set it to false.  There are many things that can be waited on - thread and process handles, semaphores, events, and overlapped IO, etc.  Overlapped IO is where you tell Windows to go and read or write a load of data, and then go to sleep until the read or write is completed.

You want to set the timeout to INFINITE.

Jim

[Stonemonkey]

Now, if i put in the for loop to test each thread, it crashes/closes. doesn't do that if i just loop i in the while wend loop though. (not just with putting in infinite etc. was the same just before that too)

[Stonemonkey]

ok, found why it crashes, the for loop was letting it draw beyond the screen boundary.

[Stonemonkey]

I think I'm getting there now:

[taj]

any chance of an exe for the C weenies??

[Jim]

->Fryer, it might be interesting as an experiment to colour code which areas are rendered by which cpu/thread.  I see you've made each thread do 10 lines at a time.  Good for debugging

->chris, it's exactly the same as one of the previous exes, except it's now using 4 concurrent threads to do the rendering.  This is making it 2-3x faster on my Core2, and it should help all the P4 HT people, and anyone lucky enough to have a Core2 Quad!

Jim

[Clyde]

Stonemonkey dude, it crashes my end.

[Stonemonkey]

Nice idea to see what goes on Jim, I'll give that a go.

Sorry Clyde, I take it you're not running the latest version of FB atm?

[Shockwave]

Won't run here either (FB1.5) so cant give feedback on speed and such, sorry I bet it looks nice though.

[Stonemonkey]

Sorry about that, it still just looks the same as before. The only thing is now it's multithreaded so it'd hopefully run a bit better on muti core/cpu machines although mine isn't. It's just turnde into a bit of an experiment tbh, here's how it stands atm with colour banding showing up which thread is rendering.

.exe

[Clyde]

Doh! Silly me I'll need to bung on V17b.
And Mate thats mega impressive welldone indeed dude.
 

[Shockwave]

looks great and seems to run quicker on dual core too

[Stonemonkey]

Cool and thanks.

Another thing I'm wondering about this is sharing the data between the threads, there's stuff about locking memory (with mutexlock). I can see the point in doing that when a thread is writing to memory but in this case I don't write to any of the shared memory so to me that's not really an issue, is that right or is there anything else that should be taken care of?