Brian Paul wrote:
Unfortunately, my Matrix G400 card died a while back so I can't test this.
I have a G400 I've been meaning to offer to the DRI project. If it
would be useful to you or another developer, I'll be happy to donate it.
-Chris
--
Christopher Dewey
[EMAIL PROTECTED]
On Mon, Mar 10, 2003 at 11:50:23PM +, Keith Whitwell wrote:
> There's a slight misconception happening here -- the 'ctx' argument doesn't
> exist. The function should read something like:
>
> void swv3f( GLfloat x, GLfloat y, GLfloat z )
> {
> GET_CONTEXT_FROM_THREA
José Fonseca wrote:
On Tue, Mar 11, 2003 at 12:01:16AM +, Keith Whitwell wrote:
Jon Smirl wrote:
--- José Fonseca <[EMAIL PROTECTED]>
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract
Title: AD 1
It has never been easier !
Wholesale
FDA Approved Medications
Online Consultations for NO CHARGE!
I MiIt's Easy.
How arNo Embarrassment.
Whats up DISCREET & FAST DELIVERY.
SIMPLE & SECURE ORDERING.
Get Viagra and other Meds.
NO PHYSIC
Marcelo E. Magallon wrote:
On Tue, Mar 11, 2003 at 12:27:40AM +, Keith Whitwell wrote:
> libGL.so provides a dispatch table that can be efficiently switched.
Yep, I've read how that's implemented in Mesa. It's really nice once
you figure out what's going on (the code of course looks a loo
On Tue, Mar 11, 2003 at 12:01:16AM +, Keith Whitwell wrote:
> Jon Smirl wrote:
> >--- José Fonseca <[EMAIL PROTECTED]>
> >wrote:
> >
> >>Yes, this works as you say _if_ the method isn't
> >>virtual, or at least
> >>the exact type of the class is known at compile
> >>time, i.e., it's not an
> >>
On Tue, Mar 11, 2003 at 12:27:40AM +, Keith Whitwell wrote:
> libGL.so provides a dispatch table that can be efficiently switched.
Yep, I've read how that's implemented in Mesa. It's really nice once
you figure out what's going on (the code of course looks a look more
terrifying than you
Keith Whitwell wrote:
>
> libGL.so provides a dispatch table that can be efficiently switched. The
real
> 'gl' entrypoints basically just look up an offset in this table and jump
to
> it. No new arguments, no new stack frame, nada -- just an extremely
efficient
> jump. Note that this is the
On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote:
>
> Unless C++ can figure out at compile time *exactly* which class is being
> invoked, I think... It's hard to know.
It can, with templates.
> Anyway, I don't think Jose really wanted a virtual member here, as he
> definitely se
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 11:08:23PM +, José Fonseca wrote:
> But the function I put in the table _was_ an ordinary function, and
> not a C++ method, and no redirection call would take place with
> inlining. That was the point of the explanation...
Uhm... how do y
On Mon, Mar 10, 2003 at 11:59:05PM +, Keith Whitwell wrote:
> > > class TNL {
> > > // A OpenGL function
> > > virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) = 0;
> >
> > ^^^
> > pure virtual method. Depending on what you want to do with this,
> > this will i
On Tue, Mar 11, 2003 at 12:42:26AM +0100, Marcelo E. Magallon wrote:
> On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
>
> > struct function_table {
> > ...
> > void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
> > ...
> > } driver;
> >
> > and
> >
>
On Mon, 10 Mar 2003 23:43:37 +
José Fonseca <[EMAIL PROTECTED]> wrote:
> Jon Smirl,
>
> I took the liberty of CC'ing the lists again as it is a very valid point
> you make here.
>
> On Mon, Mar 10, 2003 at 03:17:56PM -0800, Jon Smirl wrote:
[snip]
> > _cdecl handler(Context* self, sfactor, d
Jon Smirl wrote:
--- José Fonseca <[EMAIL PROTECTED]>
wrote:
Yes, this works as you say _if_ the method isn't
virtual, or at least
the exact type of the class is known at compile
time, i.e., it's not an
abstract Context *, but actually a non-abstract
RadeonContext *.
It works for virtual methods
On Tue, Mar 11, 2003 at 12:33:53AM +0100, Felix Kühling wrote:
> On Mon, 10 Mar 2003 22:23:07 +
> José Fonseca <[EMAIL PROTECTED]> wrote:
> [snip]
> > As I said above this can be done in C++, and without damage to
> > efficiency.
> >
> > Imagine you have a TnL abstract class:
> >
> > class TN
On Mon, Mar 10, 2003 at 11:08:23PM +, José Fonseca wrote:
> But the function I put in the table _was_ an ordinary function, and
> not a C++ method, and no redirection call would take place with
> inlining. That was the point of the explanation...
Uhm... how do you inline a function call
Marcelo E. Magallon wrote:
On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
> struct function_table {
> ...
> void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
> ...
> } driver;
>
> and
>
> class Context {
> ...
> void BlendFunc(GLenum sfactor,
--- José Fonseca <[EMAIL PROTECTED]>
wrote:
> Yes, this works as you say _if_ the method isn't
> virtual, or at least
> the exact type of the class is known at compile
> time, i.e., it's not an
> abstract Context *, but actually a non-abstract
> RadeonContext *.
It works for virtual methods and ab
Felix Kühling wrote:
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca <[EMAIL PROTECTED]> wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y, GLf
Jon Smirl,
I took the liberty of CC'ing the lists again as it is a very valid point
you make here.
On Mon, Mar 10, 2003 at 03:17:56PM -0800, Jon Smirl wrote:
> --- José Fonseca <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Mar 10, 2003 at 10:36:21PM +, Keith
> > Whitwell wrote:
> > > No, because o
On Mon, Mar 10, 2003 at 10:23:07PM +, José Fonseca wrote:
> struct function_table {
> ...
> void (*BlendFunc)(GLcontext *ctx, GLenum sfactor, GLenum dfactor);
> ...
> } driver;
>
> and
>
> class Context {
> ...
> void BlendFunc(GLenum sfactor, GLenum dfactor);
> ...
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca <[EMAIL PROTECTED]> wrote:
[snip]
> As I said above this can be done in C++, and without damage to
> efficiency.
>
> Imagine you have a TnL abstract class:
>
> class TNL {
> // A OpenGL function
> virtual void Coord3f(GLfloat x, GLfloat y, GLflo
José Fonseca wrote:
On Mon, Mar 10, 2003 at 10:36:21PM +, Keith Whitwell wrote:
No, because one of the things C++ does is pass around an extra parameter --
namely the 'self' pointer. The 'real' prototype looks something like:
void Context::BlendFunc( Context *self, GLenum sfactor, GLenum
On Mon, Mar 10, 2003 at 10:36:21PM +, Keith Whitwell wrote:
> No, because one of the things C++ does is pass around an extra parameter --
> namely the 'self' pointer. The 'real' prototype looks something like:
>
> void Context::BlendFunc( Context *self, GLenum sfactor, GLenum
>
José Fonseca wrote:
On Mon, Mar 10, 2003 at 09:11:06PM +, Keith Whitwell wrote:
José Fonseca wrote:
What disptach table would you be referring to, glapi or the TnL
one? The
problem with disptach tables is that they completely break the OOP
concept as they work with regular functions instead
On Mon, Mar 10, 2003 at 09:11:06PM +, Keith Whitwell wrote:
> José Fonseca wrote:
> >What disptach table would you be referring to, glapi or the TnL
> >one? The
> >problem with disptach tables is that they completely break the OOP
> >concept as they work with regular functions instead of objec
José Fonseca wrote:
On Mon, Mar 10, 2003 at 08:32:18PM +, Keith Whitwell wrote:
José Fonseca wrote:
Once textures are finished, the most tricky will be the software
rasterizer and the TnL module. For these my idea is to make the
driver
able to switch rasterizers and/or TnL modules in real t
On Mon, Mar 10, 2003 at 08:32:18PM +, Keith Whitwell wrote:
> José Fonseca wrote:
>
> >Once textures are finished, the most tricky will be the software
> >rasterizer and the TnL module. For these my idea is to make the
> >driver
> >able to switch rasterizers and/or TnL modules in real time, wi
José Fonseca wrote:
I'm just giving a quick update of the Mesa C++ wrappers, in case anybody
wants to discuss it a little in today's meeting.
Wrappers C functions to all the GL context callbacks are already in
place at http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.cxx . (These
were first genera
I'm just giving a quick update of the Mesa C++ wrappers, in case anybody
wants to discuss it a little in today's meeting.
Wrappers C functions to all the GL context callbacks are already in
place at http://jrfonseca.dyndns.org/projects/dri/cpp/mesa.cxx . (These
were first generated by a little Pyt
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
4:00PM EST or 1:00PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous IRC m
Hello list, there seem to be 2 bugs with the mach64 driver (for
some time now, but they still appear with latest branch 0-0-5 with
XV/tvout patch from Leif).
- in Emilia Pinball (the problem was reported by someone in july but no
one answered), some textures don't appear right (they look quite
str
Michel Dänzer wrote:
On Son, 2003-03-09 at 12:11, Mike A. Harris wrote:
At the bottom of the page:
* 7X00 denotes a R100 based card.
Should be removed, as Radeon 7000, is RV100, not R100.
And what's the difference between the two, in particular as far as the
drivers are concerned? :)
The RV1
Chris Rankin wrote:
Hi,
I have installed XFree86 4.3 on my Linux-2.4.20 SMP machine (with Matrox
G400), and recompiled xscreensaver 4.08 against the new libraries.
However, all of the OpenGL hacks now core-dump when they try to run on
the root window. They all run fine inside their own windows.
On 9 Mar 2003, Michel Dänzer wrote:
>> * 7X00 denotes a R100 based card.
>>
>> Should be removed, as Radeon 7000, is RV100, not R100.
>
>And what's the difference between the two, in particular as far as the
>drivers are concerned? :)
My point is to provide documentation that is technically
35 matches
Mail list logo
