The attached patch implements mach64_draw_point() and mach64_draw_line()
in the same vein as tris and quads (actually most of the code is just
copied from those functions), i.e. insecure client-side PIO/MMIO
register programming. This diff is against
xc/lib/GL/mesa/src/drv/mach64/mach64_tris.
Over the next week Keith Whitwell and I are planning to merge trunk
into the mesa-4-0 branch then the result into the trunk.
David
--
David Dawes
Senior X Architect Tungsten Graphics, Inc
www.XFree86.org/~dawes www.tungstengraphics.com
_
On Sunday 10 February 2002 05:08 pm, Gareth Hughes wrote:
> How do you prevent a client-side "driver" from sending down blit
> commands, without inspecting the DMA buffer?
The operations are two distinct beasts with similar interfaces. You can send
register/value pairs or tell the engine to bl
Gareth Hughes wrote:
>
> It's a damned slow chip. With anything over about a 4-500MHz
> processer, you'll still be able to saturate the chip -- we got
> it to hit the hardware limit doing PIO with a 600MHz PIII, I
> seem to recall...
Actually, no, that was with the Utah-GLX style DMA with a muc
Frank C. Earl wrote:
>
> The command pathway doesn't seem to allow for that. Only the blit
pathway.
> I've coded only inbound to the aperture writes with that pathway, but not
> outbound (there's very little that anything other than the X server needs
to
> do that sort of thing).
How do you
On Sunday 10 February 2002 04:31 am, Gareth Hughes wrote:
> I don't think you should count on being able to reset the chip once
> you "detect" a lockup. Things like bus lockups are pretty fatal
> events. Besides, I've yet to see the sample code for resetting
> the ATI chips actually work reliabl
José Fonseca wrote:
>
> On 2002.02.10 09:31 Gareth Hughes wrote:
> > ...
> >
> > These chips can read
> > and write arbitrary locations in system memory. For all chips that
> > have this feature, the only safe way to program them is from within
>
> Which of the chips currently supported by DRI
On 2002.02.10 09:31 Gareth Hughes wrote:
> ...
>
> These chips can read
> and write arbitrary locations in system memory. For all chips that
> have this feature, the only safe way to program them is from within
Which of the chips currently supported by DRI is more similar in this [DMA
programmi
Frank C. Earl wrote:
>
> On Friday 08 February 2002 07:09 pm, José Fonseca wrote:
>
> > Does this mean that client code can lock the card but is not really
> > capable of putting the security of the system in danger?
>
> Depends on what you define as "in danger". It won't allow a user to
commi
On Friday 08 February 2002 07:09 pm, José Fonseca wrote:
> Does this mean that client code can lock the card but is not really
> capable of putting the security of the system in danger?
Depends on what you define as "in danger". It won't allow a user to commit
local or remote exploits to gain
10 matches
Mail list logo
