Adam Jackson wrote:
On Tuesday 05 April 2005 16:11, Brian Paul wrote:
Roland Mainz wrote:
Another item would be to look into what's required to support visuals
beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
(AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
re
On Tuesday 05 April 2005 16:11, Brian Paul wrote:
> Roland Mainz wrote:
> > Another item would be to look into what's required to support visuals
> > beyond 24bit RGB (like 30bit TrueColor visuals) ... someone on IRC
> > (AFAIK ajax (if I don't mix-up the nicks again :)) said that this may
> > requ
Adam Jackson wrote:
On Tuesday 05 April 2005 19:03, Ian Romanick wrote:
Adam Jackson wrote:
I have another one: Hide all the functions that start with XF86DRI*, and
expose them to the driver through a function table or glXGetProcAddress
rather than by allowing the driver to call them directly. Th
On Tuesday 05 April 2005 19:03, Ian Romanick wrote:
> Adam Jackson wrote:
> > I have another one: Hide all the functions that start with XF86DRI*, and
> > expose them to the driver through a function table or glXGetProcAddress
> > rather than by allowing the driver to call them directly. This wil
Nicolai Haehnle wrote:
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
interpolation errors in triangle rasterization (the software
routines). The full explanation is long, but basically there needs to
be enough fractional bits in
Ian Romanick wrote:
>
> For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
> driver interface. There is a *LOT* of crap hanging around in both libGL
> and in the DRI drivers that exists *only* to maintain backwards
> compatability with older versions of the interface. Since it's
On Tuesday 05 April 2005 22:11, Brian Paul wrote:
> If you increase MAX_WIDTH/HEIGHT too far, you'll start to see
> interpolation errors in triangle rasterization (the software
> routines). The full explanation is long, but basically there needs to
> be enough fractional bits in the GLfixed dat
Adam Jackson wrote:
I have another one: Hide all the functions that start with XF86DRI*, and
expose them to the driver through a function table or glXGetProcAddress
rather than by allowing the driver to call them directly. This will simplify
the case where the X server is itself linked against
On Tuesday 05 April 2005 14:06, Ian Romanick wrote:
> For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
> driver interface. There is a *LOT* of crap hanging around in both libGL
> and in the DRI drivers that exists *only* to maintain backwards
> compatability with older versions o
Keith Whitwell wrote:
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both
libGL and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface
Roland Mainz wrote:
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Si
Ian Romanick wrote:
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Since it's crap, I
For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
driver interface. There is a *LOT* of crap hanging around in both libGL
and in the DRI drivers that exists *only* to maintain backwards
compatability with older versions of the interface. Since it's crap, I
would very much lik
13 matches
Mail list logo
