 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen schrieb:
>> Saul Luizaga wrote:
>>> keep diluting/lying yourself, you're doing a great job, keep it up!
>> That would be "deluding", not "diluting". :-)
>
> Like it makes any difference? Just show him where the fluoride lake is.
That would be a different guy... or at least I'd think so.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Saul Luizaga schrieb:
> keep diluting/lying yourself, you're doing a great job, keep it up!
Given up on the OpenCL topic entirely?
Maybe I was right to start the discussion with a loud groan after all.
So long.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Aug 2009 23:34:29 +0200, clipka wrote:
> Stephen schrieb:
>>> Saul Luizaga wrote:
>>>> keep diluting/lying yourself, you're doing a great job, keep it up!
>>> That would be "deluding", not "diluting". :-)
>>
>> Like it makes any difference? Just show him where the fluoride lake is.
>
> That would be a different guy... or at least I'd think so.
It is. I'm quite surprised by Saul in this subthread, because this type
of response isn't what I recall being typical of him.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 17 Aug 2009 23:34:29 +0200, clipka <ano### [at] anonymous org> wrote:
>Stephen schrieb:
>>> Saul Luizaga wrote:
>>>> keep diluting/lying yourself, you're doing a great job, keep it up!
>>> That would be "deluding", not "diluting". :-)
>>
>> Like it makes any difference? Just show him where the fluoride lake is.
>
>That would be a different guy... or at least I'd think so.
Company?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Saul Luizaga wrote:
> Chambers wrote:
>> Saul Luizaga wrote:
>>>> No, you didn't even ask a question.
>>>
>>> news://news.povray.org:119/4a850da7@news.povray.org, check the last
>>> paragraph, proves you wrong. Did you liked to be corrected?
>>
>> Yes, I do as a matter of fact. I don't like being wrong.
>>
>> ....Chambers
> yeah, right.... hahaha
Now you're just being insulting, assuming that I'm making a joke or
something.
I mean, sure it hurts my pride when I'm wrong, but that's a price I'm
able and willing to pay. Quite simply, I'm trying to be the best
possible version of myself. I know I have several flaws, many of which
I'm not even aware, so it helps me overall when they're brought to my
attention.
Obviously, I hope that people bring my flaws to my attention in the
kindest possible way, but even if they don't I try to make the most of it ;)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen wrote:
> Like it makes any difference? Just show him where the fluoride lake is.
You can lead a nut* to fluoride, but you can't make him drink until you
take his tinfoil hat away ;)
*Not directed at anyone here.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> I was thinking more along the lines of each surface possibly having a
>> different code path for computing illumination. Rays in the same
>> bundle can't take different code paths.
>
> Sure they can, you just have an "if" in the shader code based on some
> flag in the ray data.
Problem: when you come to a branch, all units in that block have to take
the same branch.
Thus, branching is discouraged.
>> Indeed, that's where I read about the render queue approach. (No, I
>> don't remember where *exactly*.)
>
> Damn. If you think up *anything* you think is new, you can be
> guaranteed that someone else somewhere has already thought of it :-)
> The internet just makes it easy to find that person!
I know I saw a whitepaper on the render queue method back in the 90s,
but I don't remember the author. In fact, most of the work done on
computers with graphics was theorized back in the 70s and 80s, but is
only in the last 5 or 10 years being widely implemented due to
sufficient hardware support now being available.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> I was thinking more along the lines of each surface possibly having a
>>> different code path for computing illumination. Rays in the same
>>> bundle can't take different code paths.
>>
>> Sure they can, you just have an "if" in the shader code based on some
>> flag in the ray data.
>
> I was under the impression that all cores in the bunch would have to
> take the same branch of the if - you can't have half go one way and half
> go the other. (That's what makes it a SIMD architecture.)
In fact, I think NVidia does allow alternate code paths - but the unit
executes both code paths, and then discards the one you don't need.
> Again, depends on whether you're writing a shader, or using a GPGPU system.
Same thing nowadays, its just the shaders are written in a dialect of C
that's more capable than the ones used for graphics.
>> Nah it's no problem :-) Modern GPUs don't have any limit on loops or
>> number of instructions or anything like that.
>
> But they don't allow recursion. That's the issue.
To be precise, they don't allow indefinite recursion. You can actually
have recursion where you specify the number of levels at compile time.
After that, however, you can't change it without compiling a new shader.
> Do you know how hard it is to draw a cube made of 8 cubes and measure
> all their sides? Do you know how long it takes to expand (x+y)^9
> manually, by hand? Do you have any idea how long it takes to figure out
> what the pattern is and where it's coming from?
>
> ...and then I discover some entry-level textbook that tells me how some
> dead guy already figured all this out several centuries ago. AND FOR
> ARBITRARY EXPONENTS!! >_<
Isn't that what Pascal's triangle is for?
> Why do I bother?
Be honest, it's because you enjoy it :)
Heck, I expanded the evaluation of a bezier patch to give cubic
functions by hand. A bicubic equation fully expanded takes about half
of a standard sheet of notebook paper, but then there's the derivation
which takes a few pages ;)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I was thinking more about how to store the scene on the GPU efficiently,
>> if you just have a triangle list it is relatively simple.
>
> Again, depends on whether you're writing a shader, or using a GPGPU
> system.
It still runs on the same hardware though, which is highly optimised for
graphics operations, you need to be aware of this no matter how you shape
your code.
> But they don't allow recursion.
Yes that was what I said earlier, for something like raytracing to unlimited
depths I think the CPU needs to step in every so often to process the
current set of rays (ie kill and spawn rays where appropriate).
Of course if you want to limit yourself to a fixed depth (ie a max trace
level of 8 or whatever) then you can "unroll" the recursion so it works on
the GPU. Might not be as efficient as letting the CPU do it though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I was under the impression that all cores in the bunch would have to
> take the same branch of the if - you can't have half go one way and half
> go the other. (That's what makes it a SIMD architecture.)
I'm sorry for jumping in, here, but surely you mean SMP, not SIMD?
SIMD is single-instruction multiple data.. e.g. performing an add on 4
WORD values simultaneously with one instruction.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
