On Wed, Jun 18, 2003 at 12:24:46PM +0600, Dimitry N. Naldaev wrote:
> HI
>
> Unfortunatly my notebook with Savage MX video subsystem is broken at the
> moment :',-( so I can not do real coding / testing for a while, but I am
> studing the problem an have some questions
>
> First of all, I have not any documentation for Savage chip, but I have
> Utah-GLX source and will refer to it
>
The Utah-GLX is only source of information in that respect. The way the
Utah-GLX defines and uses vertex arrays is not documented on the Savage4
Register reference - it must be documented on the BCI manual to which I
never got access to.
> 1. The Vertex Format.
> The r128 driver define vertex format in t_dd_vertex.h template as union of v,
> pv and tv structures and some arraies. The Utah Savage driver define vertex
> format in savage_hw.h as
>
> typedef struct _SavageVertex {
> float fX;
> float fY;
> float fZ;
> float fW;
> SavageColor stDiffuse;
> SavageColor stSpecularFog;
> float fU;
> float fV;
> } SavageVertex, *SavageVertexPtr;
>
> which do not correspond directly to structures in r128Vertex. The closest
> probably v fild of the union but compare to SavageVertex it have addition
> filds u1, v1, u2, v2, u3, v3
> SO question is how to right define vertex format for Savage in DRI (and what
> is function of filds u1, v1, u2, v2, u3, v3)?
The r128Vertex is similar to the D3D vertex format therefore it can be
described by the general template t_dd_vertex.h . Cards that don't
follow that have to code their own template. Examples are the 3DFX and
more recently the Mach64.
> 2.sending commands to hardware
> in Utah-GLX all simple. When we draw triangle, we put command and vertices of
> the trianle after command in the bci buffer. (savage_tri.h and savage_line.h)
> But in r128 we put _ONLY_ wertices in the dma buffer (r128_tris.c and
> t_dd_tritmp.h) and I can not find the place of code were we put command for
> hardware in the dma buffer :-( the dri tree is too big. . .
The 3D driver doesn't actually touch the hardware. It requests a buffer from the DRM,
fills it, and sends it back via an ioctl.
> 3. Tiny vertex
> What it is? and for what htey are used? are they correspond to the tv fild of
> r128Vertex? r128_vb.c define HAVE_TINY_VERTICES in 1 . . .
It's the ability to compactily describe vertices with just coords and
color, i.e., without having to zero-padding the other fields.
> probably I can use this format of vertex with Savage if I setup flags
> BCI_SKIP_W | BCI_SKIP_SPECULAR | BCI_SKIP_U | BCI_SKIP_V in the command
> Is this true?
Yes. Something like that.
> 4. GL context
> The definition of context for savage (savage_glx.h) in Utah-GLX is very simpl
>
> typedef struct _SavageContext {
> SavageBufferPtr pDrawBuffer;
> GLcontext *gl_ctx; // mesa context with all states and other goodies
> float fViewportHeight;
> } SavageContext, *SavageContextPtr;
>
> But the definiton of context for r128 (r128_context.h) in DRI more complex :-(
> what filds in the struct r128_context are specific for r128 hardware ???
>
> 5 Savage hardware registers mmap
> savage_hw.h define SavageRegs struct wich is, as I understand, mmap for
> hardware context regs. and we probably need to define something similar.
> what is the best place for this?
No. Or at least read-only, otherwise this would compromise the system
security. The 3D driver is an user application and can't be trusted. The
only trusted entities here are the DRM and the XFree86 2D driver. As
said above, the communication has to be done via buffers which are
dispatched by the DRM to the hardware. See
http://marc.theaimsgroup.com/?l=dri-devel&m=104635578704374&w=2
for more info.
This is also why that, spite you're doing excelent progress addressing
these libGL driver related issues, it's preferred to write a minimal DRM
first - just dispatch a single buffer (without queuing) to the hardware.
This would allow then for different people work on the DRM and on the
libGL driver without stepping on each other toes.
On Mach64 the development started the other way around - first the libGL
driver using direct access to the hardware via MMIO and the DMA done
aftewards -, and I think it was a big mistake becaused it lead to
the rewrite of several parts of the libGL driver since the paradigm was
completly different.
José Fonseca
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
