Before I just launch into this, I will explain some of the motivation and
(brief) history that led to this document.
As near as I can tell, the GLX side of DRI has stagnated. I seems as though
we are approaching a critical mass to make some real improvements in that
area. Brian and I have had
Ian Romanick wrote:
Before I just launch into this, I will explain some of the motivation and
(brief) history that led to this document.
As near as I can tell, the GLX side of DRI has stagnated. I seems as though
we are approaching a critical mass to make some real improvements in that
area.
Title: AW: [Dri-devel] Adding GLX extensions?
Jens Owen wrote:
Oddly enough, ATI provides a libGL.so replacement in their package. I'm
not sure why they do this.
You don't neccessary need to replace libGL.so.1.2 If you do not, you just loose some extended functionality like GLX 1.3
Allen Akin wrote:
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote:
|
| How does one go about determining the (data structure / API) version of
| libGL.so?
As I understand it, there isn't a formal version number. Apps that
follow the Linux ABI shouldn't need to be aware of the
Ian,
I happened to be looking at glxcmds.c. The glXSwapIntervalSGI()
function is already there (along with most known GLX extension
functions). It's just a stub though. I had forgotten that I
added stub functions for most/all GLX extensions a few years
ago, hoping it would simplify things
On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote:
Allen Akin wrote:
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote:
|
| How does one go about determining the (data structure / API) version of
| libGL.so?
As I understand it, there isn't a formal version
Ian Romanick wrote:
On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote:
Allen Akin wrote:
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote:
|
| How does one go about determining the (data structure / API) version of
| libGL.so?
As I understand it, there isn't a formal
On Tue, Nov 19, 2002 at 09:53:28AM +0100, Johannes Rath wrote:
Jens Owen wrote:
Oddly enough, ATI provides a libGL.so replacement in their package. I'm
not sure why they do this.
You don't neccessary need to replace libGL.so.1.2 If you do not, you just
loose some extended
Ian Romanick wrote:
On Tue, Nov 19, 2002 at 10:55:12AM -0700, Brian Paul wrote:
Ian Romanick wrote:
On Tue, Nov 19, 2002 at 08:35:45AM -0700, Brian Paul wrote:
Well, there isn't an official query like this, but there is the
_glapi_get_version() function which returns the version of the
Ian Romanick wrote:
Hmmm...would adding it as a hard-coded extension make life easier for IHVs
that want to provide binary-only drivers but not necessarilly their own
libGL.so? I'm thinking ATI and PowerVR...
Oddly enough, ATI provides a libGL.so replacement in their package. I'm
not sure
-Original Message-
From: Ian Romanick [mailto:[EMAIL PROTECTED]]
Sent: 15 November 2002 20:40
To: DRI developer's list
Subject: Re: [Dri-devel] Adding GLX extensions?
[...]
Hmmm...would adding it as a hard-coded extension make life easier for IHVs
that want to provide binary-only
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote:
This would involve implementing glXSwapInterval() as an ordinary
function in libGL. It would simply stuff the interval value into
the __GLXContextRec struct (assuming it's per-context). Then, it
would be up to the DRI driver(s) to
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote:
|
| How does one go about determining the (data structure / API) version of
| libGL.so?
As I understand it, there isn't a formal version number. Apps that
follow the Linux ABI shouldn't need to be aware of the libGL version,
so there
If I do that, in glxinfo it only shows up in the 'client glx extensions',
which makes sense given the way I'm doing it. In the Nvidia driver, it
shows up in both 'client glx extnesions' and 'GLX extensions'.
Evidently, NVIDIA supports the extension for indirect rendering too.
NVIDIA's
Ian Romanick wrote:
Can I get a quick run-down of the GLX code so that I can know where to
begin?
Most of the server side support for GLX proper is in:
xc/programs/Xserver/GL/glx
This provides the main extension for indirect rendering and interfaces
with the ../dri and another glue piece
Jens Owen wrote:
Ian Romanick wrote:
Can I get a quick run-down of the GLX code so that I can know where to
begin?
Most of the server side support for GLX proper is in:
xc/programs/Xserver/GL/glx
This provides the main extension for indirect rendering and interfaces
with the ../dri and
Ian Romanick wrote:
On Fri, Nov 15, 2002 at 07:45:21AM -0700, Brian Paul wrote:
Jens Owen wrote:
Ian Romanick wrote:
Can I get a quick run-down of the GLX code so that I can know where to
begin?
Most of the server side support for GLX proper is in:
xc/programs/Xserver/GL/glx
This
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote:
Ian Romanick wrote:
I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
first because implementing it in any of the drivers that supports the vblank
syncing would be trivial. That way 99% of the work in not
Ian Romanick wrote:
On Fri, Nov 15, 2002 at 12:02:28PM -0700, Brian Paul wrote:
Ian Romanick wrote:
I'm going to implement SGI_swap_control (which adds glXSwapIntervalSGI)
first because implementing it in any of the drivers that supports the vblank
syncing would be trivial. That way 99% of
Since one of the ultimate goals of the texmem branches was to enable
implementing GLX_SGIX_pbuffer, I've been looking into adding extensions to
GLX. What I'd like to do is start by adding 2 (or 3) simple extensions to
get the hang of it, but I'm a bit stuck. There is GLX code in several
20 matches
Mail list logo
