Re: Vectors (cpu type idea)
- From: "cr88192" <cr88192@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 23 Jul 2008 10:24:48 +1000
"Wolfgang Kern" <nowhere@xxxxxxxx> wrote in message
news:g655l4$ac4$2@xxxxxxxxxxxxxxxxxxxxxxxx
"cr88192" wrote:
[accellerated...]
yes, these cards can do some things pretty quickly, it can be surprising.be
for the limited range of tasks that can be pulled off on it, the GPU can
fairly effective for bulk calculations.
for example, it is possible that the GPU could be used for decent-sized
neural net simulation or similar (future GPUs allowing for much bigger
nets). many things that would be done using much slower but direct
algorithms can be done on the GPU using "visual reasoning" based algos
(draw a bunch of stuff and process the results).
I heard about speach processing could use GPU features.
yes, I had considered this well...
this is actually how I was doing visibility calculations:
draw a bunch of stuff and what is visible, is visible...
but, there are still limits...
while you mention OpenGL ...
I haven't checked on it, an HLL-story anyway ?
I am not sure what you are asking exactly.
What type of source input ?
a special compiler ?
dedicated to certain hardware and drivers ?
well, in my case, usually I have taken a tweaky approach:
most data is presented as either texutres or is sent-in with GL's geometry
primatives.
processing itself can be done with vertex and fragment shaders.
results can be fetched back (for example, via retrieving values from the
framebuffer or an by rendering into an auxilary buffer, ...).
vertex and fragment shaders are written in GLSL.
there are other more involved options (such as CUDA and Brook), but I am
sticking mostly to more generic stuff: plain C and OpenGL (currently using a
lot of GL2.0 features though).
most of the rest of my renderer uses the GL1.1 featureset (AKA: the part
readily accessible from the headers on windows).
GL2.0 features are mostly confined to areas making use of shaders and
similar.
even then, one can still get some tasks done on the GPU using the GL1.1
featureset (just one is mostly confined to tasks that can be pulled off via
the built-in drawing features).
...
more recently, I have been doing a lot more 3D related stuff, and veryconsidering
recently have started again messing with physics simulation, me
adding several features to my physics engine:
soft-body physics (cloth, globs, ...);
particle simulation (for smoke and fire effects, ...);
ragdolls;
physics shaders;
...
[read ..]
My son bought himself a G7-studio some time ago. It teaches C-lite
and got almost all of the features you describe in the above and more,
like gravity center, friction, tension, liquids, fog, rain, snow, ...
well, these are newer features being added, not necessarily older features.
but, in most respects, I am not trying to do anything compelling or original
here, rather just implementing generally "useful" stuff.
a major emphasis is on API design, where I am following a very GL-like
design approach (aka: opaque get/set interfaces with integer handles and
properties). for example, fairly recently I changed the internals over to
C++ (a rarity in my case, given I mostly prefer C) without changing the
external API (namely, still C-based).
[read ..]
I tried DOOM3 with minor success, it's just too dark for my worn eyes :)
but I found an older 'knight-shift' game which runs smooth and fast
also on my old 500 MHz machine, even with many animated parts and
a lot of emmisive objects. The GPU does all the job almost alone.
part of both Doom3's lighting and performance issues is related to exactly
how all this is done.
a particular approach was used, which tends to give these kind of effects.
emulating this basic approach also seems to have emulated many of the
effects.
You'll find this minor bugs (late shadow update) in almost all games,
perhaps just to keep top speed for the front view.
yes, oh course, my current approach does not allow delaying shadows (I amredrawn
using the depth-fail shadow-volumes approach, which sadly has to be
every frame, and creates a totally huge amount of invisible geometry and
overdraw related to drawing the shadow volumes and then drawing the
lights
onto the surfaces...).
the result is that, for the Quake-1 maps, I get performance comprable to
what Quake-1 was getting on the original hardware it was targetting (good
old pentium 90s and pentium 133s).
of course, for a long time, I had been running it primarily on a 486DX-66try
and similar style HW (that is what my main computer had been at the
time),
so I had been fairly used to it lagging (or, for true terror, one could
to use HW accel on the then new S3-Virge and later S3-Trio-64 cards, for
questionable graphics at far worse framerates...).
yeah, my 486dx-100 is still here, even not used for years.
I used S3 cards for a long time, but I never figured any accellerators.
yeah.
the S3 cards technically had HW-accel, but it was so bad that it was
generally not used as such (it was typically far slower than any kind of SW
rendering).
long ago, the Voodoo cards were the major point I think when HW-accelstill
actually fully outdid SW rendering, my projects eventually changing focus
primarily to HW-accel primarily around the time when the GeForce-2 was
newer (and when I actually had one). I think prior to this, I had tried
doing some stuff using Mesa, but it was unacceptably slow at the time...
Let's wait and see, I may not be too old to start a new aera of
backwards enginering on DXnn and drivers ... :)
ok.
well, my case, mostly I am developing primarily in userspace on windows, but
I like GL over DirectX, for one reason, since when needed I can easily port
my code to Linux and reverse (and I also like the general approach of GL
more than that of DX as well...).
__
wolfgang
.
- Follow-Ups:
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- References:
- cpu type idea
- From: mcjason
- Re: cpu type idea
- From: santosh
- Re: cpu type idea
- From: Phil Carmody
- Re: cpu type idea
- From: mcjason
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: cpu type idea
- From: Wolfgang Kern
- Re: cpu type idea
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- Re: Vectors (cpu type idea)
- From: cr88192
- Re: Vectors (cpu type idea)
- From: Wolfgang Kern
- cpu type idea
- Prev by Date: Re: I pee in the open
- Next by Date: Re: I pee in the open
- Previous by thread: Re: Vectors (cpu type idea)
- Next by thread: Re: Vectors (cpu type idea)
- Index(es):
Relevant Pages
|