Re: [Dri-devel] Updates to texmem-0-0-1 branch
On Thu, 14 Nov 2002 18:44:18 -0800 Ian Romanick [EMAIL PROTECTED] wrote: Over the next week or so I plan to do the same thing with the r128, i810, and i830 drivers. That will leave the gamma, sis, and tdfx drivers. If those don't get modified to use the new texmem interface, I won't lose any sleep. :) Once we're satisfied that radeon, r200, r128, mga, i810, and i830 work, I will recommend (baring issues wrt the XFree release) that the texmem-0-0-1 branch be merged into th trunk. If anybody cares about those other drivers, NOW is the time to get on board. Im awaiting a PCI Voodoo3 at the moment... --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
Im awaiting a PCI Voodoo3 at the moment... Sorry, I didn't make it this week. It will get shipped on monday, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
On Fri, 15 Nov 2002 11:39:55 +0100 (CET) Martin Spott [EMAIL PROTECTED] wrote: Im awaiting a PCI Voodoo3 at the moment... Sorry, I didn't make it this week. It will get shipped on monday, No rush - I wasnt criticising, just making the statement so people would know I intend to have a crack at Voodoo3 support and not drop any code on the floor. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Reduce Your Debt Interest Overnight! VCQI
--- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
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 ../mesa/src/X, I think, to complete the server side support. The client side support is in: xc/lib/GL/glx AFAIK, Brian uses lot's of magic and a couple of Newt's tails along with this module to build libGL.so Once I get started, I should be able to figure out the details submit some additions to the developer's FAQ. :) That would be great. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
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 another glue piece ../mesa/src/X, I think, to complete the server side support. The client side support is in: xc/lib/GL/glx That's basically it. If you've got detailed questions I can try to answer them. Adding new extensions which just add new enum values is pretty simple. Adding new GL/GLX functions is more work since you have to implement the GLX encode/decode functions and server-side dispatch. AFAIK, Brian uses lot's of magic and a couple of Newt's tails along with this module to build libGL.so It's not quite that bad, but there are a few sublties. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
Ian Romanick wrote: As everyone on dri-patches already knows, I've just commited a TON of changes to the texmem-0-0-1 branch. I modified the R100 R200 drivers to look more alike. I run the following from within the radeon directory to see the differences between the two drivers: for i in *.[ch] ; do diff -ud $i ../r200/$(echo $i | sed 's/radeon/r200/') done | less Piping it to wc instead of less shows only 17k lines of differences. :) Lots of the changes were silly changes to variable names or comments to make the diffs smaller. Once I got the diffs down to a manageable level, I was able to modify the R200 driver to use the texmem interface. Since I don't have access to a Radeon 8500, I have never actually tested any of this. Hopefully somebody that has such hardware will be able to finish it off from here. Over the next week or so I plan to do the same thing with the r128, i810, and i830 drivers. That will leave the gamma, sis, and tdfx drivers. If those don't get modified to use the new texmem interface, I won't lose any sleep. :) Once we're satisfied that radeon, r200, r128, mga, i810, and i830 work, I will recommend (baring issues wrt the XFree release) that the texmem-0-0-1 branch be merged into th trunk. If anybody cares about those other drivers, NOW is the time to get on board. As part of the work I've already done, I added utils.[ch] to the common directory. I plan to move more code to that file as I come across duplicated code in the drivers. In case there's anybody that hasn't noticed, I'm a big fan of factoring out common code. :) This sounds great, though I'm afraid it's going to complicate the merges coming up. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TCL/SW lighting differences
Felix Kühling wrote:
Hi,
I made a small programme to illustrate the TCL/SW lighting differences.
It displays a square consisting of 10x10 quads which is lit by one
lightsource. The distance between the lightsource and the square is
changed periodically. With TCL this has the desired effect, with
software lighting it doesn't have any effect at all. This looks like an
optimization that assumes lightsources to be at infinite distance. I
attached the programme. With a macro you can switch between diffuse and
specular lighting.
So the lighting problem described with FlightGear could actually be a
bug in FlightGear that just isn't visible with software lighting.
There's a bug in your program. The GL light position is a homogeneous
coordinate (4 components) but you're only providing 3 components:
GLfloat lightpos[3] = {0.0, 10.0, 0.0};
The 4th coordinate is effectively random. Changing this to:
GLfloat lightpos[4] = {0.0, 10.0, 0.0, 1.0};
Fixes the problem.
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TCL/SW lighting differences
On Fri, 15 Nov 2002 08:00:27 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[...]
There's a bug in your program. The GL light position is a homogeneous
coordinate (4 components) but you're only providing 3 components:
GLfloat lightpos[3] = {0.0, 10.0, 0.0};
The 4th coordinate is effectively random. Changing this to:
GLfloat lightpos[4] = {0.0, 10.0, 0.0, 1.0};
Fixes the problem.
Ok, thanks. I read the manpage of glLight again and tried it with
different values for the fourth component. For 1.0 and 0.0 hardware and
software TCL seem to behave identically. For all other values their
behaviour differs somehow. As I don't know how to interpret values other
than 0.0 and 1.0 I can't tell which behaviour is correct (maybe
both?).
-Brian
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TCL/SW lighting differences
Felix Kühling wrote:
On Fri, 15 Nov 2002 08:00:27 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[...]
There's a bug in your program. The GL light position is a homogeneous
coordinate (4 components) but you're only providing 3 components:
GLfloat lightpos[3] = {0.0, 10.0, 0.0};
The 4th coordinate is effectively random. Changing this to:
GLfloat lightpos[4] = {0.0, 10.0, 0.0, 1.0};
Fixes the problem.
Ok, thanks. I read the manpage of glLight again and tried it with
different values for the fourth component. For 1.0 and 0.0 hardware and
software TCL seem to behave identically. For all other values their
behaviour differs somehow. As I don't know how to interpret values other
than 0.0 and 1.0 I can't tell which behaviour is correct (maybe
both?).
According to the OpenGL specification, the user-provided light position
is transformed by the current modelview matrix, just like a vertex.
After putting some debug code into Mesa, light position {0, 10, 0, 1}
is transformed to { 0.00, 0.050437, -0.993759, 1.00 } while
light position {0, 10, 0, 2} is transformed to { 0.00, 0.050437,
-2.996257, 2.00 }.
So clearly the light's transformed Z position depends on the W component
in this example so I'd expect this to effect the shading as we've seen.
However, I tried various non-zero values for W with NVIDIA's driver and
got different results.
On a hunch, I tried dividing the transformed light position's X, Y and Z
by W in Mesa. After making this change, I get identical results to
NVIDIA's driver for any value of W.
But the spec doesn't say anything about dividing by W. Also, looking at
the SGI sample implementation, I can't find a division by W either.
I may have to ask someone about this, but as far as I can tell, Mesa's
doing the right thing.
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
On Fri, Nov 15, 2002 at 11:20:07AM +, Ian Molton wrote: No rush - I wasnt criticising, just making the statement so people would know I intend to have a crack at Voodoo3 support and not drop any code on the floor. I would hope Ian R's texmem stuff doesn't mean dropping the remaining drivers on the floor. That's not really a good choice. There's no problem with some drivers getting the features of texmem and some not, but dropping drivers is a bad idea. I'm glad you're interested in the tdfx. That's still one of the more popular cards out there and getting it updated and removing glide would be a big win. - |Daryll --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
On Fri, Nov 15, 2002 at 08:56:22AM -0800, Daryll Strauss wrote: On Fri, Nov 15, 2002 at 11:20:07AM +, Ian Molton wrote: No rush - I wasnt criticising, just making the statement so people would know I intend to have a crack at Voodoo3 support and not drop any code on the floor. I would hope Ian R's texmem stuff doesn't mean dropping the remaining drivers on the floor. That's not really a good choice. There's no problem with some drivers getting the features of texmem and some not, but dropping drivers is a bad idea. I'm glad you're interested in the tdfx. That's still one of the more popular cards out there and getting it updated and removing glide would be a big win. NONONONO! The drivers that aren't updated WILL REMAIN in the tree. There is NO INTENTION of removing any functional drivers. That said, the texmem support, particularly the supprt to be added in the texmem-0-0-2 branch will enable the support of a lot of (mostly) device independent features. Drivers that don't get texmem updates will quick lag wy behind the others. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
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 provides the main extension for indirect rendering and interfaces
with the ../dri and another glue piece ../mesa/src/X, I think, to
complete the server side support.
The client side support is in:
xc/lib/GL/glx
That's basically it. If you've got detailed questions I can try to
answer them. Adding new extensions which just add new enum values
is pretty simple. Adding new GL/GLX functions is more work since you
have to implement the GLX encode/decode functions and server-side
dispatch.
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 device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa-swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa-vbl_seq + rmesa-swap_interval;
}
else if ( getenv(LIBGL_SYNC_REFRESH) ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc-isDirect cases,
anyway).
You have two choices:
1. A dynamically registered extension
In October I implemented a new mechanism in libGL to allow runtime
addition of new GLX extensions (not just GL extensions as it did before).
This will allow new DRI drivers to better work with older libGL libraries.
Basically, the driver calls __glXRegisterGLXFunction() and
__glXRegisterGLXExtensionString() to tell libGL about a new GLX extension.
If the user calls glXGetProcAddressARB(glXFoobarEXT) they'll get a
pointer to the new extension. And calls to glXQueryExtensionStrings()
will return the string registered with __glXRegisterGLXExtensionString().
To pull this off, libGL has a list of function name/address structs:
static struct name_address_pair *Dynamic_GLX_functions = NULL;
which keeps track of the functions registered with __glXRegisterGLXFunction().
glXGetProcAddressARB() just searches that list.
So, in principle you could and a server-side-only GLX extension to
libGL without ever touching the libGL code. But you should really
put a glXSwapInterval() function in libGL so that one can directly
call it without needing glXGetProcAddressARB().
The new glXAllocateMemoryNV() function would be good to follow as an
example of this.
Your implementation of glXSwapInterval() should also search this list.
You can cache the result of the search if you want.
In the r200 driver you'd have an r200SwapInterval() function that
got called via the glXGetProcAddressFunction(). This function would
just store the interval value in the rmesa context struct (assuming
that this value is per-context state - the spec doesn't say!).
2. As a hard-coded extension
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 check if libGL was new enough
before grabbing that value from the context rec.
One problem with this approach is that the extension would appear
to be present for all drivers, when it really isn't. We'd need
a new mechanism for DRI drivers to enable/disable GLX extensions
in a manner similar to Mesa's _mesa_enable/disable_extension().
The other problem is it would require the user to have the updated
libGL.so in addition to the new r200_dri.so driver.
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension.
How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Updates to texmem-0-0-1 branch
Ian Romanick wrote: On Fri, Nov 15, 2002 at 07:46:22AM -0700, Brian Paul wrote: Ian Romanick wrote: As everyone on dri-patches already knows, I've just commited a TON of changes to the texmem-0-0-1 branch. I modified the R100 R200 drivers to look more alike. I run the following from within the radeon directory to see the differences between the two drivers: for i in *.[ch] ; do diff -ud $i ../r200/$(echo $i | sed 's/radeon/r200/') done | less Piping it to wc instead of less shows only 17k lines of differences. :) Lots of the changes were silly changes to variable names or comments to make the diffs smaller. Once I got the diffs down to a manageable level, I was able to modify the R200 driver to use the texmem interface. Since I don't have access to a Radeon 8500, I have never actually tested any of this. Hopefully somebody that has such hardware will be able to finish it off from here. Over the next week or so I plan to do the same thing with the r128, i810, and i830 drivers. That will leave the gamma, sis, and tdfx drivers. If those don't get modified to use the new texmem interface, I won't lose any sleep. :) Once we're satisfied that radeon, r200, r128, mga, i810, and i830 work, I will recommend (baring issues wrt the XFree release) that the texmem-0-0-1 branch be merged into th trunk. If anybody cares about those other drivers, NOW is the time to get on board. As part of the work I've already done, I added utils.[ch] to the common directory. I plan to move more code to that file as I come across duplicated code in the drivers. In case there's anybody that hasn't noticed, I'm a big fan of factoring out common code. :) This sounds great, though I'm afraid it's going to complicate the merges coming up. Yeah. I suspect that the path-of-least-resistance will be: 1. Merge DRI trunk and XFree trunk (for the XFree release). 2. Merge DRI trunk to the mesa-4.1 (or is it mesa-5.0?) branch. 3. Merge DRI trunk to the texmem-0-0-1 branch. 4. Merge the two branches. 5. Merge the unified branch into the trunk /after/ the last DRI-to-XFree merge. Ugh...that does sound like a pain...I think that will allow us to acomplish the most without disrupting the XFree release. Thoughts? I'd suggest holding off on further big clean-ups until after we've got everything else into the trunk. My next task on the 4-1 branch (really Mesa 5.0 now) is to bring the 5.0 sources into the xc/extras/Mesa directory. Do some testing, then merge into the DRI trunk (when it's OK with the XFree86 plan). I've never done a merge between two branches (one has always been the trunk) so I'm not sure if there's any gotchas there. -Brian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
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 device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa-swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa-vbl_seq + rmesa-swap_interval;
}
else if ( getenv(LIBGL_SYNC_REFRESH) ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc-isDirect cases,
anyway).
You have two choices:
1. A dynamically registered extension
[snip]
2. As a hard-coded extension
[snip]
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...
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension.
Okay. That's because that's the code that does the wire-protocol decoding
and dispatch, right?
How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
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'. From the
perspective on an ISV, where SHOULD it appear?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
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 the work in not device dependent.
:) In the R200 driver, the behavior of SGI_swap_control can be added by
changing r200WaitForVBlank to do something like:
if ( rmesa-swap_interval != 0 ) {
vbl.type = DRM_VBLANK_ABSOLUTE;
vbl.sequence = rmesa-vbl_seq + rmesa-swap_interval;
}
else if ( getenv(LIBGL_SYNC_REFRESH) ) {
...
The only catch is that I can find NO documentation of the GLX protocol for
it. Given that, I'm going to implement it for direct rendering contexts
only. I believe that this could be done by either adding a new entry point
to __DriverAPIRec or adding a swap_interval field to __DRIcontextPrivateRec
and adding a DRIswapInterval function to dri_util.c.
I would then fill-in glXSwapIntervalSGI in lib/GL/glx/glxcmds.c to look
either like glXSwapBuffers or glXUseXFont (for their gc-isDirect cases,
anyway).
You have two choices:
1. A dynamically registered extension
[snip]
2. As a hard-coded extension
[snip]
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...
I don't think it matters much either way.
What needs to be done in programs/Xserver/GL/glx/?
Nothing for a client-side-only GLX extension.
Okay. That's because that's the code that does the wire-protocol decoding
and dispatch, right?
right.
How do I get the
extension string exported? This also applies to the
GLX_ARB_get_proc_address string. :)
Add it to __glXGLXDefaultClientExtensions[] in glx/glxcmds.c
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.
From the perspective on an ISV, where SHOULD it appear?
[Note that GLX has 3 functions for querying extensions...]
From my understanding, it depends on the particular extension. If a GLX
extension really only is client-side-only, then it'll only appear in the
string returned by glXGetClientString(dpy, GLX_EXTENSIONS).
glXQueryServerString(dpy, scrn, GLX_EXTENSIONS) will return the names of
extensions that are implemented in the server. But you won't be able to
use them if the same extension isn't implemented on the client side by
libGL.
If a GLX extension is implemented by both client and server, then it should
appear in glXQueryExtensionsString(dpy, scrn) since it computes the inter-
section of the extension strings.
That said, I don't know why NVIDIA's driver returns GLX_ARB_get_proc_address
from glXQueryExtensionsString().
-Brian
---
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: non-NDA documentation.
Howzit? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. Heres a suggestion. Can people holding non-NDA chipset documentation please all send it to smitty and he can put it up on the site? If people are paranoid about being sued, I'll happily host it on mnementh.co.uk I'll quite happily stick just about anything up on the website if it's of a decent quality / standard. Not just up to me though. here is some driver documentation for VT8601A, without NDA: http://www.viavpsd.com/product/Download.jsp?motherboardId=3D21 (filename: DS8601A182.pdf) maybe thats a good starting point for new developers who have a notebook or thinclient with this chip. they could start writing a dri driver without waiting for docs. Somewhere I found info that the Blade 3d should be almost as good/fast as an i810, heres a forum for mvp4/ple133 mini-itx-board linux users: http://linitx.org/forum/ I'll also happily link to just about anything if it's of a decent quality / standard. Again its not just up to me though. Of course it'll need more than just this. g Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI site overhaul: What about the DRI Beginner's Guide etc. sections?
Howzit Dieter? Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. Any progress? With what excatly the guide in the subject line - I've never touched that. With the website see below. When will we see the move? Merged already. I pointed someone at the new site and first thing was 404 Not Found... Please give a URL, although iirc /site_update is no longer valid, I don't regard this as a problem as the correct URL is now just: http://dri.sf.net Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Ati Radeon 8500 - DRI howto.
Hello Bache Been real busy until last week with exams, spent the last week clearing certain backlogs, sorting out problems, etc. And now am answering DRI email. I've made a small howto for ati radeon 8500 with direct render support. I want opinions and suggestions, changes that can make the doc better. Please take a look at: http://looner.mine.nu/~bkw/dri_8500.txt I haven't had a look yet, but heard good things from those who had. If you will look after your howto I'd like to link to it from the main site as dcoumentation. Or put it on the same server if you no longer have any interest in it. Liam it depends --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] (±¤°í)¡Ú²ÞÀº ÀÌ·ç¾îÁø´Ù!!! Á¤¸» ²Þ°°Àº â¾÷/ºÎ¾÷!!!¡Ú
Title: (±¤°í)¡Ú¹«Á¡Æ÷,¼ÒÀÚº» â¾÷ÀÇ ±âȸ¸¦ ÀâÀ¸¼¼¿ä!¡Ú :: ¿¬¶ôó ¾È³» :: ÁÖ¼Ò : ¼¿ïƯº°½Ã ¼Ãʱ¸ ¼ÃÊ2µ¿ 1337-8 º¸Åëºôµù 405È£´ã´ç : ÁÖ¼¼ÈÆTEL : 080-224-5500»çÀÌÆ® : http://www.sohomart4u.com :: ±¤°í¾È³» :: ¿øÄ¡¾Ê´Â Á¤º¸¿´´Ù¸é ¸Ó¸®¼÷¿© »ç°úÀÇ ¸»¾¸À» ¿Ã¸³´Ï´Ù.º»¸ÞÀÏÀº ¹ß½ÅÀü¿ë ¸ÞÀÏÀÔ´Ï´Ù.º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í»çÇ׿¡ ÀÇ°ÅÇÏ¿© ¹ß¼ÛµÈ ±¤°í¸ÞÀÏÀÔ´Ï´Ù.±ÍÇÏÀÇ ¸ÞÀÏÀº ¸ÞÀϼöÁý ÇÁ·Î±×·¥À» »ç¿ëÇÏ¿© ÃßÃâÇÏ¿´À¸¸ç, ¸ÞÀÏÁÖ¼Ò ÀÌ¿Ü¿¡ ¾î¶°ÇÑ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù. ¼ö½ÅÀ» °ÅºÎÇÏ½Ç ºÐÀº ¿©±â¸¦ Ŭ¸¯ÇÏ¿© Áֽʽÿä.Ȥ¿© Ŭ¸¯ÀÌ µÇÁö ¾ÊÀ¸½Ã¸é [EMAIL PROTECTED] À¸·Î º¸³»ÁÖ½Ã¸é µË´Ï´Ù. If you want to be removed from our recipient list, please click [unsubscribe]. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
