[Openchrome-devel] Some HW related questions to VIA:

[Thomas Hellström]

Hi, Benjamin,
Thanks for your answer.

BenjaminPan at viatech.com wrote:
> Dear Thomas,
>
> We really appreciate that you can make time available to continue working on the OpenChrome 3D code especially knowing that you have been very busy with regular job. Therefore you bet we want to support you as much as we can.
>
> The reason that we don't have the PS instruction set for you right now is because the existing document was written by engineers during the development the 3D engines long time ago with everything including sample shaders reference to info from Microsoft under NDA at that time. Over the years, no one has asked for shader document so it hasn't been reviewed/researched for how much of those have become public info and how should the rest be rewritten.
>   

OK. I understand.
My primary interest in this was to get a feeling for the new 3D engine 
by putting together some EXA render acceleration support. All 3D engines 
I've worked with so far has had a rather free-standing pixel-shader 
documentation, which really helps a lot when it comes to figuring out 
how data is fed into and retreived from the pixel shader, how it's fired 
off, and what instructions are available.

> Regarding EXA, I supposed you want to use 3D engine to accelerate the composite extensions. Since this is a new frontier, there may be info that we can exchange or discuss for what can improve performance and what can not. Do you want to have an IRC session or start a separate subject thread for that?
>   

We could perhaps start a separate subject thread?

> One quick clarification, although AMD K8 / Athlon64 CPUs have memory attached to the CPU, linear address by direct frame buffer access still needs to be translated into physical address by graphics engine. So the access cycles is routed back-n-forth between CPU which memory is attached to, and chipset where graphics resides. That is why it is so slow compared to true "direct" access of P4 and K7 architectures where both graphics and memory are on the same side of the bus.
>   

Benjamin, The CPU-access slowness with K8M800 (K8) can be worked around 
by accessing the framebuffer pages directly by the CPU. (Not through the 
PCI resource).
I was not able to perform the same workaround with PM800 (P4) and KM400 
(K7), hence the question. It looks like "direct framebuffer access" is 
not enabled by BIOS and i was wondering whether there is a way to enable 
it from the host driver.

> VX800 doesn't support frame buffer dynamically allocated out of page-locked system memory as Intel does. So the use of system memory is mainly for texture and command buffers as AGP aperture space before - except now graphics is reported as PCI type hence GART function is part the graphics and not chipset.
>   

Yes. What I'm looking for is information on how to program the 
Graphics-only GART. To set up, say 16MB of non-contigous system memory 
for textures and comand / vertex buffers *in addition to* the 
BIOS-enabled frame-buffer.


Thanks.

/Thomas