"Wolfgang Kern" <nowhere@[EMAIL PROTECTED]
> wrote in message
news:g670i8$lk9$1@[EMAIL PROTECTED]
>
> "cr88192" wrote:
>
>>>>> while you mention OpenGL ...
>>>>> I haven't checked on it, an HLL-story anyway ?
>
>>>> I am not sure what you are asking exactly.
>
> me not either :)
> I haven't the slightest clue what's behind OpenGL.
> Of course I can google for it and download Gigas, but before I
> waste time and disk-space I'd like to know what I may get.
>
> If OpenGL is what I think, it could be my key into analysing
> drivers/tools to finally get the missing information on how
> certain GPUs could be direct controlled at lowest level.
>
> I gave up on DirectX analysis, it's just too heavy detoured and
> dragged me through hundreds of dlls and into the kernel too often.
> And I wonder why it at all works any faster than linear VESA, ;)
> bypassing all these detours would free the CPU for other jobs
> during a GPU frame cycle.
>
oddly enough, it is often big and complicated structures that offer a lot
more in terms of performance than simpler structures...
but, yes, I think at least is should probably be a much more direct route,
taking note that GL tends to operate at a much lower level of abstraction
than DX (containing a good ****tion of a 3D engine as well as just
rendering
stuff...).
I think it is all faster than the linear framebuffer is because, somehow
or
another, the video card is capable of quickly pulling off a rather large
amount of operations (likely on of the bigger of these being that of being
able to efficiently draw all of these textured triangles).
an alternate historical route would likely have been, had HW accel not
come
around, the main CPUs gaining absurdly large vector processing abilities
(or, possibly GPU-like devices becomming popular as coprocessors, later
becomming integrated into the main processor).
actually, the few-big-processors + teh-crapload of smaller vector
processors, is likely to become a particularly major trend in computing I
think (albeit, the wall is likely to become far less blatant than the
present CPU/GPU split).
for example, speculating on some kind of possible future chip:
maybe 8 or 16 major cores (large shared-space x86-64 or similar);
maybe 512 or 1024 mini-cores, possibly each running a variant of 32-bit
x86
(possibly a subset of x86, but superset in the way of having a large
number
of SIMD and MIMD capabilities), these cores possibly running in a kind of
NUMA-like manner (there being a large number of disjoint maybe 256MB to
4GB
address spaces, each with some number of mini-cores sharing it), or
possibly
using the same basic address space as the main processor, but likely
having
fairly heavy-handed caching (possibly allowing exclusive-owner****p
behavior
or maybe even loose syncronization).
to the main app, these cores are likely to be accessed with some variation
of good old multithreading (the app itself operating probably mainly in
terms of the main processors, with many specialized tasks being offloaded
to
these smaller processors).
externally, they would likely somewhat represent ordinary processors.
(and me venturing further off into sci-fi land...).
I also figure that eventually, there may be robots or androids, which may
actually be allowed somewhat larger processors. for example, a number of
dies fused into some single much larger processor lump, possibly with some
kind of circulated liquid coolant and internal heat pumps (probably little
magnetically suspended brushless turbines, operating something much like a
tiny air conditioner).
me thinking, for example, the processor core being maybe 2in x 2in x 1in,
with the connectors on one side, and a big metal plate on the other
(heatsink goes here).
for example, one can retain a fairly small heatsink profile (and being
air-cooled), by using a heat pump and internal circulating fluids to
somewhat boost the heatsink temperature (the CPU cores are maybe 100F, but
the heatsink is 250F or 350F). then again, such an android would be a
mobile
space heater (circulating the heat through the android serving to keep the
thing warm, and also avoid it venting overly hot air...).
however, a 350F (177C) heatsink is likely to dissapate heat fairly quickly
(vs a larger cooler heatsink), partly because of the strong temperature
difference with the surrounding air. alternatively, the thing could be
fluid
filled, and use the bodies' surface area as a heat sink (heat pumps direct
heat from the processor to the bodies' fluid/coolant system).
of course, the future would probably need some kind of high-capacity
batter
as well (me just assuming people probably wont allow fission batteries for
things like this). maybe it would be liquid-fueled (like gasoline or
deisel), for example, operating a super-heated boiler, which spins a
turbine
powering a generator (batteries being used for power storage). maybe the
mechanical parts are primarily hydraulic (them using very high pressures
to
allow rapid flow rates, with generally high-speed valves allowing smooth
movement).
then again, it may well be this is not needed as well (instead human-like
AIs running on processors like in a laptop or cellphone), with large
solid-lump processors never really comming into style.
of course, all of this is going probably too far off in Sci-FI land I
guess...
> ...
>> vertex and fragment shaders are written in GLSL.
> ...
> Ok, I'll search for GLSL-tools and GL1.1/2.0 specs as well.
>
> [3D & game features ...] 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
> ****t
>> my code to Linux and reverse (and I also like the general approach of
GL
>> more than that of DX as well...).
>
> I hope GL is a less detoured story in the back ...
can't say, I have not looked as much at how this part works...
> __
> wolfgang
>
>
>
|
