Re: [CAD_CAM_EDM_DRO] Imbedded computers

Stephen Wille Padnos wrote:

>juan gelt wrote:
>
>
>
>>is it that you guys crave to run windows on this?
>>there are a couple real-time os that are nowhere near
>>so heavy on the graphics....
>>
>>
>>
>>
>It doesn't really matter. It's not the drawing that's the problem, it's
>the refresh.
>
>

That is unlikely. All video cards, including all on-board cards, have
dedicated fast video memory that does not affect the CPU. This is the
primary memory that the card uses. AGP cards also have high-speed
access to main memory for the purpose of storing textures used in 3D
rendering. When the video card is accessing main memory for rendering a
texture and the memory controller is busy the CPU has to wait if it also
needs to access main memory. If the time required for this transaction
is long low-latency operations can suffer. In AGP 3.0 the potential
impact of this contention is reduced with isochronous transactions which
guarentee that memory access will be short.

Screen refresh is performed from video memory, not from main memory, so
the bandwidth required has no impact at all on the CPU performance.
However, if an application (such as common FPS 3D games) is constantly
rendering frame data the video card will constantly be accessing main
memory, even if nothing is visably changing in the scene. In worst-case
senerios this can result in CPU performance impacts of 30%. Worst case
is generally only seen in games that demand high performance from both
the CPU and 3D video subsystems at the same time. Sitting around in
windows really shouldn't result in any noticable texturing-related
memory contention. In practice it is extremely difficult to track
problems with CPU performance to this sort of contention. For CNC
purposes configuring the AGP subsystem with no access to main memory
should eliminate this as a potentential source of problems. This will
of course impact the performance of your FarCry games while you are
waiting for that part to finish :D

The observation that the problem occurs with Mach mostly on mobo's with
Via chipsets and never Nvidea suggests that the problem is not with
memory contention, but with the Via hardware or drivers as used by
Mach. In the past there have been (difficult to solve) problems with
Via hardware working with the Direct3D API, so this would not be all
that surprising.

In a nutshell, I'd say that worring about video performance of an
on-board card should by waaay down the list of concerns, but to stay
away from Via chipsets (this is always good advice, Via has a reputation
of having issues).

Anyway, I don't mean to harp on it, I've just heard this warning about
onboard video memory contation and Mach go by a few times and was
curious if it was valid, or if the problem was more likely something
else. It is the latter IMO.

Dave K