The previous mail got badly formated. I'm sending again the broken lines.
...
: /* placeholder for a command */
0004: /* VERTEX_1_S */
0008: /* VERTEX_1_T */
000c: /* VERTEX_1_W */
0010: /* VERTEX_1_SPE
On 2002.03.02 23:02 Keith Whitwell wrote:
>
> > > To do that in a secure manner, these commands should be either
> verified or
> > > even written by the DRM. A good way to do this would be have a
> template in
> > > the DRM for generating a set of functions for each of those generated
> by
> > >
> > To do that in a secure manner, these commands should be either verified or
> > even written by the DRM. A good way to do this would be have a template in
> > the DRM for generating a set of functions for each of those generated by
> > t_dd_vbtmp.h. (If this idea is viable, while DMA is not en
On Sun, Mar 03, 2002 at 11:44:44PM +0100, Laurent Pinchart wrote:
> I'll have a look at that.
>
> Which CVS branch should I start with ?
On the glide side you want to use glide3x, but I don't think they ever
created any branches there. There are glide3x for V3 and glide3x for
V{4,5} branches whi
Michael wrote:
>
> On Sat, Mar 02, 2002 at 03:40:02PM +, José Fonseca wrote:
> > This buffer is then used to render the primitives in _tris.c. This vertex
> > data is intended to be copied almost verbatim into DMA buffers, with a
> > header command, in most chips with DMA.
>
> In the (mesa-4
José Fonseca wrote:
>
> Since I still haven't gathered the means to make some external debugging
> on the mesa-0-0-3-branch I've chosen to invest my time in better
> understand the logic of a mesa driver, especially the *_vb.c and *_tris.c
> files. I would appreciate if someone reviewed these not
I'll have a look at that.
Which CVS branch should I start with ?
Laurent Pinchart
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sat, Mar 02, 2002 at 03:40:02PM +, José Fonseca wrote:
> This buffer is then used to render the primitives in _tris.c. This vertex
> data is intended to be copied almost verbatim into DMA buffers, with a
> header command, in most chips with DMA.
In the (mesa-4-branch) radeon driver the v
On Sun, Mar 03, 2002 at 01:20:54PM +0100, Laurent Pinchart wrote:
> > Removing Glide by adding only the appropriate functionality to the
> > driver would be a good project for someone who wants to start working
> > close to the hardware. It's pretty well defined and can be done in
> > chunks. You
Since I still haven't gathered the means to make some external debugging
on the mesa-0-0-3-branch I've chosen to invest my time in better
understand the logic of a mesa driver, especially the *_vb.c and *_tris.c
files. I would appreciate if someone reviewed these notes and correct me
when I'm
On Don, 2002-02-28 at 10:05, Roger While wrote:
> I am getting the following (permanent) error on logging out
> from KDE :
> [drm]radeon_cp_indirect - process using buffer owned by 0
>is the PID of the X server and the "owned by" is always 0.
> The effect is that
Michael wrote:
>
> On Fri, Mar 01, 2002 at 05:42:38PM +, Keith Whitwell wrote:
> > In the meantime I'me about to commit something rather nice: A dedicated
> > Begin/End engine for the radeon tcl driver with dynamic code generation for
> > commands like glVertex, glColor, etc.
>
> Looks good
> Removing Glide by adding only the appropriate functionality to the
> driver would be a good project for someone who wants to start working
> close to the hardware. It's pretty well defined and can be done in
> chunks. You can steal code from Glide as necessary.
What about the GLIDE license ? Is
On Fri, Mar 01, 2002 at 05:42:38PM +, Keith Whitwell wrote:
> In the meantime I'me about to commit something rather nice: A dedicated
> Begin/End engine for the radeon tcl driver with dynamic code generation for
> commands like glVertex, glColor, etc.
Looks good.
Are you still in the proces
14 matches
Mail list logo
