OpenGL 3.0 spec released!
On Wed, Aug 06, 2008 at 12:39:15PM +0300, Pasi Kärkkäinen wrote: > Hi list! > > It seems OpenGL 3.0 will be (finally) released at Siggraph! > > http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// > > OpenGL BOF > > SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire Grand > Hotel - Wilshire Room > > OpenGL 3.0 new features > Specification Review Jeremy Sandmel, Apple > > GLSL 1.3 new features New Shader language definition Bill Licea-Kane, AMD > > OpenGL 3.0 ISV PerspectiveDaniel Koch, Transgaming > Discussion of benefits OpenGL 3.0 provides ISVs Rob Barris, > Blizzard > > etc.. > "The Khronos. Group announced today it has released the OpenGL® 3.0 specification" http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/ http://www.khronos.org/opengl/ http://www.opengl.org/registry/doc/glspec30.20080811.pdf http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.08.pdf http://www.opengl.org/documentation/specs/glx/glx1.4.pdf http://www.opengl.org/documentation/specs/glu/glu1_3.pdf -- Pasi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL 3.0 release at siggraph
On Wed, Aug 06, 2008 at 11:55:29AM -0700, Ian Romanick wrote: > Pasi Kärkkäinen wrote: > > | It seems OpenGL 3.0 will be (finally) released at Siggraph! > > Yes, finally. :) > > | > http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// > | > | OpenGL BOF > | > | SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire > Grand Hotel - Wilshire Room > > I will be at SIGGRAPH and at the BoF this year...in case anyone wants to > meet up and hang out or something. > Nice. Too bad I can't be there. Would be nice to see Siggraph once.. Maybe you can post here and let us know what happened and how it was :) -- Pasi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
OpenGL 3.0 release at siggraph
Hi list! It seems OpenGL 3.0 will be (finally) released at Siggraph! http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// OpenGL BOF SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire Grand Hotel - Wilshire Room OpenGL 3.0 new features Specification ReviewJeremy Sandmel, Apple GLSL 1.3 new features New Shader language definitionBill Licea-Kane, AMD OpenGL 3.0 ISV Perspective Daniel Koch, Transgaming Discussion of benefits OpenGL 3.0 provides ISVs Rob Barris, Blizzard etc.. -- Pasi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GSOC '08 hardware accelerated video decoding
On Tue, Apr 01, 2008 at 12:50:08PM +0300, Pasi Kärkkäinen wrote: > On Fri, Mar 28, 2008 at 12:08:38AM -0400, Younes M wrote: > > Hi, > > > > I recently posted to the Nouveau mailing list about this, but for > > those who don't participate in that one I thought I would also post > > here since it seems to concern DRI as much as Nouveau. I intend to > > submit an application for a project that will attempt to implement > > XvMC in terms of Gallium3D. I've come up with a preliminary proposal > > and was hoping people would be willing to give it a quick read and > > give me some feedback; opinions, corrections, concerns, etc. An HTML > > version is here: http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml and > > a text version is below. > > > > Hi! > > Link that I just happened to find a couple of days ago: > > http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf > > Might be worth checking out.. > And forgot to mention that the pdf above is about: "XvMC for H.264/AVC" "Current work at 'h264' branch of git://people.freedesktop.org/~zhen/videoproto" -- Pasi - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GSOC '08 hardware accelerated video decoding
On Fri, Mar 28, 2008 at 12:08:38AM -0400, Younes M wrote: > Hi, > > I recently posted to the Nouveau mailing list about this, but for > those who don't participate in that one I thought I would also post > here since it seems to concern DRI as much as Nouveau. I intend to > submit an application for a project that will attempt to implement > XvMC in terms of Gallium3D. I've come up with a preliminary proposal > and was hoping people would be willing to give it a quick read and > give me some feedback; opinions, corrections, concerns, etc. An HTML > version is here: http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml and > a text version is below. > Hi! Link that I just happened to find a couple of days ago: http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf Might be worth checking out.. -- Pasi - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ARB float texture/framebuffer extensions are out
Hi! ARB released a couple of days ago the long waited float extensions.. http://oss.sgi.com/projects/ogl-sample/registry/ARB/color_buffer_float.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/half_float_pixel.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_float.txt http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012662 There seems to be some IP issues.. does that mean these extensions can't be implemented in Mesa/DRI ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)
On Wed, Oct 27, 2004 at 04:31:13PM -0700, Ian Romanick wrote: > Dieter Nützel wrote: > > >gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main > >-I../../src/mesa/glapi -I../../src/mesa/math > >-I../../src/mesa/tnl-I../../src/mesa/shader -I../../src/mesa/swrast > >-I../../src/mesa/swrast_setup -Wall -O -march=athlon -ansi -pedantic -fPIC > >-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > >-DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM > >-DPTHREADS -I/usr/X11R6/include glapi/glapi.c -o glapi/glapi.o > >In file included from glapi/glapi.c:129: > >glapi/glapitemp.h: In function `NoOpGetInfoLogARB': > >glapi/glapitemp.h:3783: error: parameter name omitted > >glapi/glapitemp.h:3783: error: parameter name omitted > >glapi/glapitemp.h:3783: error: parameter name omitted > >glapi/glapitemp.h:3785: error: parse error before ',' token > > I just saw this as well. It appears to be related to the recent GLSL > changes. I'll try to poke around at it tonight, if nobody beats me to it. > So GLSL will be supported in Mesa/DRI in the near future? :) -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Software emulation of shaders.. sw-shader
Hello! When browsing the web I found this: http://sw-shader.sf.net. It's full software implementation of DX9 for windows.. using SIMD/SSE/MMX. Could this help Mesa in any way? Mainly the shader optimizations.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote: > Brian Paul schrieb: > >Pasi Kärkkäinen wrote: > > > >>Hi all! > >> > >>>From the www.opengl.org: > >> > >> > >>OpenGL 2.0 specification available for download > >> > >>http://www.opengl.org/documentation/opengl_current_version.html > >>http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf > >> > >>Any plans for 2.0 support in Mesa? I think the biggest "todo" is the > >>sw-emulation of glsl? > > > > > >Yeah, implementing the shading language will be a huge project. It > >would be nice if a group of volunteers would work together to implement it. > > > >I'll probably start working on some of the infrastructure for 2.0 > >support in the near future. But the GLSL parser and code generator will > >be the bulk of the 2.0 work by far. > > > >-Brian > > > > Some modifications to Mesa are necessary: > -Change glColor3 behaviour, > -Seperate legacy and generic vertex attributes. > GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2 > needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3 > allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program > (assuming both extensions present) there may be no attribute aliasing. > -I dont' know about GL_ARB_texture_non_power_of_two and > GL_ARB_draw_buffers. Are they supported already? > -The rest should be there. > > I planned to do some work towards shader support, but wanted to wait for > The 2.0 spec to be released to see what would change. I probably won't > find much time before mid-october or so. This is what I had in mind: > > Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader, > GL_ARB_fragment_program and GL_ARB_fragment_shader that create some > intermediate representation. > Then, at least four backends: One for SSE to get fast software > rendering on newer x86, one that interpretes for the architectures where > there is no compiling backend, one for the new intel chips and their > fragment program support and finally, one for the Wildcat VP > (I don't have docs for it though and doubt that I will ever get any, > I haven't asked Intel about i915 yet). > > So get get something running I would first craete the > GL_ARB_vertex_program frontend. Then the interpreting backend. If it's > at least as fast as the solution we have now, we can already put it in > Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend. > Hmm.. is it possible to use the frontend compiler which is available from 3dlabs website? Or does it help anything.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
OpenGL 2.0 specification available for download
Hi all! >From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest "todo" is the sw-emulation of glsl? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tv-out of radeon mobility as another display?
On Sat, Jan 17, 2004 at 10:08:54AM -0800, Alex Deucher wrote: > In theory this is possible, all you really need to do is direct one of > the crtcs to output to the tv-out port rather than one of the monitor > ports. unfortuantely I don't know anything about tv out on radeon. if > the gatos drivers support clone mdoe, 3D should work on the cloned > head. you might have more luck inquiring on the gatos list. > OK. I'll check gatos list. I'm interested in using my vj-application with my laptop.. which means, that I can see the control-gui and the preview-window on the laptop itself (:0.0), and the "master-output" (only the opengl rendered video) on the another output (tv-out, :0.1). - Pasi Kärkkäinen > Alex > > --- Pasi K?rkk?inen <[EMAIL PROTECTED]> wrote: > > Hello! > > > > Is it possible with the current (DRI) drivers to use tv-out as > > another > > display? Built-in LCD/VGA being the first display (:0.0), and tv-out > > as the > > second display (:0.1) ? > > > > How about (3d) acceleration on the tv-out? Does mergedfb help with > > this? > > > > gatos project seems to have some tv-out drivers available too.. > > but they support only "clone"-mode. > > > > If I remember correctly, this is supported under windows. > > > > Thanks. > > > > -- Pasi K?rkk?inen > > > >^ > > . . > > Linux > > /-\ > > Choice.of.the > >.Next.Generation. > > > > > > --- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel -- ^ . . Linux /-\ Choice.of.the .Next.Generation. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tv-out of radeon mobility as another display?
Hello! Is it possible with the current (DRI) drivers to use tv-out as another display? Built-in LCD/VGA being the first display (:0.0), and tv-out as the second display (:0.1) ? How about (3d) acceleration on the tv-out? Does mergedfb help with this? gatos project seems to have some tv-out drivers available too.. but they support only "clone"-mode. If I remember correctly, this is supported under windows. Thanks. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GLSlang approved by ARB
quote from opengl.org forums: "3DLabs have released their GL2 SDK today and claim that the latest version of glslang was approved by the ARB at the June meeting. There's a revised version of the spec and some examples." http://www.3dlabs.com/support/developer/ogl2/index.htm -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ARB_vertex_buffer_object extension posted!
Hello! If you have not yet noticed, ARB_vertex_buffer_object extension has been released! http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt ARB_pixel_buffer_object should follow soon too.. You can also find the slides about this extension shown in the Game Developers Conference 2003 from here: http://www.r3.nu/~cass/gdc_slides/GDC2003_OGL_BufferObjects.ppt DRI should be able to support these after Ian Romanick completes the texmem-changes sometime in the future.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Buggy OpenGL Init/Quit in SDL (with Mesa)
Hello!
I have been debugging a problem I am seeing with SDL when used with glew (glew
is OpenGL extension handler library, http://glew.sf.net).
When you use Mesa-based OpenGL drivers, and your app is using SDL for
OpenGL, and you link your program with glew, _SDL_ starts to segfault in
X11_GL_Shutdown().
The segfault happens when the following code from X11_GL_Shutdown() is run:
if( this->gl_data->glXReleaseBuffersMESA ) {
this->gl_data->glXReleaseBuffersMESA(GFX_Display,SDL_Window);
}
*segfault*
First I was sure, that the problem/bug is in glew, because the above code starts
to segfault after you link with glew libraries.. without glew everything
works well.
But after talking with DRI developers (Ian Romanick) it seems the real bug
is in SDL.. glew just exposes it somehow.
SDL does not check if the OpenGL driver really supports
glXReleaseBuffersMESA(). SDL should parse the extensions string to see if
the extension is really supported. The code currently (from SDL 1.2.5) is
like this:
this->gl_data->glXReleaseBuffersMESA =
(void (*)(Display *, GLXDrawable)) dlsym( handle, "glXReleaseBuffersMESA" );
That is wrong, because for example with my Matrox G400 the driver does NOT
support that extension (if you look "glxinfo", glXReleaseBuffersMESA is not
in the list of supported extensions), but it is included in the Mesa OpenGL
library and dlsym() finds a pointer for it..
Now when that function is called in X11_GL_Shutdown() in SDL it causes the
segfault I'm seeing.
This obviously does not happen with Nvidia's drivers, because they do not include
that function in the libGL.so.
Ian Romanick also stated that glXReleaseBuffersMESA() should not be called
in any case when Mesa is loaded as libGL.so .. any ideas why that piece of
code is in SDL ?
When I remove glXReleaseBuffersMESA() code from SDL everything runs fine!
Really simple application for testing this is available from
http://nrg.joroinen.fi/sdl-glew-bug.tar.gz. It should compile out of the box
and segfault if you are using DRI drivers (at least if segfaults with my
G400 and with couple of other people's G400 too, both Debian and Redhat).
I really would like to get this solved, because SDL segfaults every time I
try to use it (with glew).
Thanks!
-- Pasi Kärkkäinen
^
. .
Linux
/-\
Choice.of.the
.Next.Generation.
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] missing xf86strtof definition
On Fri, Feb 07, 2003 at 07:27:42AM -0700, Brian Paul wrote: > Alan Hourihane wrote: > >On Fri, Feb 07, 2003 at 01:06:22AM +, Alan Hourihane wrote: > > > >>On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote: > >> > >>>in XFree86 log > >>> > >>>Symbol xf86strtof from module > >>>/usr/X11R6/lib/modules/extensions/libGLcore.a is unresolved! > >>> > >>>this function doesn't exist in XFree86 trunk, nor DRI trunk (going by > >>>grep), how ever it is used in extras/Mesa/src/imports.c > >>> > >>>did someone forget to commit its definition? > >> > >>Good catch. Just committed a fix for it. > > > > > >Mmmm. Looking at Mesa though, it doesn't define it's wrapper interface > >for strtof() either, and I can't see it being used within Mesa too. > > > >It's wrapping calls xf86strtof() or strtod() - is that intentional ? or... > > > >Should this be removed from imports.c ? > > AFAIK, I've never used strtof/strtod in Mesa until in the current 5.1/trunk > code. I need it for fragment program parsing. > Hmm.. does this mean Mesa is going to have ARB_f_p support (in software?) ? How about ARB_v_p ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] A question, about Rage128 and news in DRI
On Mon, Feb 03, 2003 at 02:27:43PM +, Alan Cox wrote: > On Mon, 2003-02-03 at 12:45, Stefan Lange wrote: > > VIA/S3 has been contacted several times already, whether they'll allow > > the integration of S3TC-support in the DRI. Unfortunately they never > > answered. So it's not very likely that you'll S3TC in DRI in the near > > future. Things might change some time, if you're lucky, but I doubt it > > I'm talking to someone senior at VIA about this however its a slow > process and we've had our new year, and now the chinese new year in the > way. > Great! Let's hope you have more luck than the others had.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Debian packages of upcoming xfree86 4.3 with DRI?
On Sun, Jan 26, 2003 at 04:06:26PM +0100, Michel Dänzer wrote: > On Sun, 2003-01-26 at 15:10, Pasi Kärkkäinen wrote: > > > > Does someone have up to date Debian packages for testing the DRI of upcoming > > xfree 4.3 ? > > http://penguinppc.org/~daniels/README > Thanks! Seems to be upgraded a couple of days ago.. nice. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Debian packages of upcoming xfree86 4.3 with DRI?
Hello! Does someone have up to date Debian packages for testing the DRI of upcoming xfree 4.3 ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Newer Radeon cards and ATIs driver
On Fri, Jan 24, 2003 at 06:18:46PM +0100, Gregor Riepl wrote: > On Thursday 23 January 2003 21:50, Pasi Kärkkäinen wrote: > > I recommend using some library which has up-to-date header file and code to > > automatically set up all supported extensions.. > > > > http://glew.sf.net is one of these. It supports most of ARB-, EXT-, ATI- > > and NVIDIA-extensions under both Linux and Windows. > > > > Thanks a lot, this really helped me! > So actually the libGL isn't really responsible for the extensions and they can > be directly accessed... just as I thought > It seems that it's no different under windows. ATI supplies a header file with > their examples and you have to load the EXT function pointers up yourself. > Yep. And glew will load the function pointer automatically if it is supported by the driver.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Newer Radeon cards and ATIs driver
On Wed, Jan 22, 2003 at 06:11:09PM -0700, Brian Paul wrote:
> Gregor Riepl wrote:
> >For all those who don't know yet:
> >ATI has released a closed source driver which should support most ATI
> >based video cards. You can grab it on www.ati.com. (It's an rpm though)
> >
> >This is quite nice, since the open source drivers support almost no
> >advanced features of the newer cards.
> >Now the problem is, I just started with OpenGL programming and wanted to
> >try out those cool features recent 3d chips offer: vertex & pixel shaders,
> >ATI Truform, etc.
> >But for some reason _none_ of these functions, not even the simplest
> >OpenGL 1.3/1.4 extensions (let alone ATI stuff) seem to be implemented in
> >their GL library/header files.
>
> You should be able to use the Mesa/DRI/XFree86 gl.h and glext.h headers.
> glext.h has most of the newest extensions.
>
I recommend using some library which has up-to-date header file and code to
automatically set up all supported extensions..
http://glew.sf.net is one of these. It supports most of ARB-, EXT-, ATI- and
NVIDIA-extensions under both Linux and Windows.
Example code:
#include "glew.h"
glewInit();
if (glew.ARB_fragment_program)
{
// use pixel shaders here
}
if (glew.ARB_texture_env_combine)
{
// use texture env combiners here
}
and so on..
-- Pasi Kärkkäinen
^
. .
Linux
/-\
Choice.of.the
.Next.Generation.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
On Thu, Nov 21, 2002 at 04:33:47PM +0100, Alexander Stohr wrote:
> Hello,
>
> i know that DRI is targeting open source development,
> but i know myselves that for a developer there can
> always be a need for a 2nd source driver reference.
> There are several other reasons why an alternate
> Linux driver might be of interest for the audience.
>
> So please excuse me for posting this information to your lists.
>
> So this passed the news wires today:
> ATI drives graphics performance for Linux users with new unified driver
> http://mirror.ati.com/companyinfo/press/2002/4574.html
>
> The drivers can now be downloaded for free at www.ati.com
> (see e.g. Linux & FireGL 8800).
>
> The drivers should run on Linux/x86 with glibc 2.2,
> some common kernel modules do come precompiled and
> a build environment for gcc2.96 and gcc3.2 is included,
> thus making that drivers compatible with
> e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions.
>
> Supported cards should be (list might not be complete):
> - ATI Radeon 8500 {/DV/LE}, 9000 {/PRO}, 9500 {/PRO}, 9700 {/PRO} -> "Built
> by ATI"
> - ATI FireGL 8700, 8800, E1, X1, Z1/X1-128MB (just announced for retail),
> Mobility
>
> I installed that drivers and tested them a tiny little bit.
> Simple applications like glxgears do perform very well and
> they are working quite nice for ut2003_demo (S3TC!), Maya and Houdini.
> My impression is that things like Quake, Chromium or Blender should work.
> I just had a few minutes of a one-man tournament session this noon.
>
> I tried XVideo support and it showed that the CPU usage of TOP
> was higher than that of the video player application. Features
> that you will on FireGL boards are Overlays and PBuffer rendering
> support.
>
> Please excuse me again, i furthert want to give a few of the end
> users an alternative to the dri drivers, which are often only
> really useable if you do have downloaded som 60 MB of CVS sources
> and built whole XF86 with a not totally trivial process.
>
> Let me express that i do _not_ object to any of the DRI-Devel works.
> DRI did great job and it resolves for situations where ATI
> cant provide solutions as of today and possibly long term.
> Just saying embedded Radeon chipsets, ATI chipsets on BSD,
> old ATI chipsets prior to the R200 and further any sort of
> experimental and custom extensions to the DRI open source
> drivers.
>
> Let's hope, no one does mind this mailing.
>
> -Alex.
>
> PS: not speaking for my employer, just documenting things that
> are already publicly availabel.
Quote from the webpage (URL above):
"The new unified driver provides robust OpenGL® 2.0 support for many of ATIs
award-winning graphics boards including:"
Does these drivers _really_ have OGL 2.0 support?
-- Pasi Kärkkäinen
^
. .
Linux
/-\
Choice.of.the
.Next.Generation.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI (Mesa) support for ARB_{fragment|vertex}_program extensions
Hello! http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_program.txt Now when ARB has approved extensions for both pixel- and vertex-shaders, are there any problems supporting these in DRI/Mesa? At least r200 hardware supports these features.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Press release: Redhat - DRI
On Thu, 18 Oct 2001, Jeffrey W. Baker wrote: > > > On Thu, 18 Oct 2001, Pasi Kärkkäinen wrote: > > > > > "Red Hat Hires Former DRI Developers" > > > > http://biz.yahoo.com/bw/011017/172084_1.html > > It doesn't say that at all, as far as I can see. > Sorry, that was taken from the www.linuxgames.com - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Press release: Redhat - DRI
"Red Hat Hires Former DRI Developers" http://biz.yahoo.com/bw/011017/172084_1.html - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, what's the plan?
On Thu, 27 Sep 2001, Dacobi Coding wrote: > Hello people! > > I was just wondering, what's the plan regarding > Radeon 8500 DRI support? > > I been hearing rumors about ATI switching to > a unified driver structure much like Nvidia's. > Can anyone verify wether this is true or not, > and if it is true, how it will affect the DRI project? > 283. Support Radeon 7500, 8500 and Rage128ProII (#4941, ATI Technologies). That's from the XFree86 changelog. I don't know more about that.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] OpenGL 2.0
From slashdot: "3Dlabs is trying to drive the graphics interface away from hardware specific extentions, as seen in DirectX. Instead, they are proposing an open (no NDA) dialog on OpenGL 2.0. The guidelines mention good-ol-fashioned platform independence (linux included) and emphasis on programmability, time control and memory managemenmt." http://www.3dlabs.com/opengl/ogl2.pdf - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon on KT7A
On Wed, 30 May 2001, Alan Hourihane wrote: > > I replaced -s 0:0.0 with the "address" of Radeon, and tried both of > > those.. didn't help. Still crashes in the same way as without that > > setpci-setting.. > > > > Any other ideas? > > > No. No. That's exactly why I asked for the lspci -vv output to check where > things where. > > Please use -s 0:0.0 > OK. When I do that, the whole box crashes immediately after I press enter..:( even sysrq wont work anymore.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon on KT7A
On Tue, 29 May 2001, Alan Hourihane wrote: > On Tue, May 29, 2001 at 10:43:29PM +0300, Pasi Kärkkäinen wrote: > > > > On Tue, 29 May 2001, Alan Hourihane wrote: > > > > > Can someone send me a copy of lspci -vv on this motherboard. > > > > > > I may have a workaround if someone would like to test. > > > > > > > Ok, here is the output of "lspci -vv" just after booting to linux > > (textmode), and when under X. > > > > If you have something to try, I'm willing to test.. > > > O.k. > > Try this before running the Xserver. > > setpci -s 0:0.0 0x50=0xFF > > if 0xFF doesn't do anything try 0xEA. > > Please let me know. > I replaced -s 0:0.0 with the "address" of Radeon, and tried both of those.. didn't help. Still crashes in the same way as without that setpci-setting.. Any other ideas? - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon on KT7A
On Wed, 30 May 2001, Alan Hourihane wrote: > > When I do that, the whole box crashes immediately after I press enter..:( > > even sysrq wont work anymore.. > > > O.k. Can you check your BIOS for something called "AGP Driving Value" ? > usually in "Chipset Features Setup". Set this to 0xFF. > > Also check for another option called "AGP Driving Control" and > make sure it's set to MANUAL (the other option is AUTO). Then it allows > you to enter a hex digit. Use the following... > > If yours is a KT133 board try 0xE7, if it's a Apollo Pro 133A try 0xDA. > > See if that helps. > Tried 0xFF, 0xE7 and 0xDA. Crashes with all of them. MB has KT133A-chipset (Abit KT7A). - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon on KT7A
On Wed, 30 May 2001, Alan Hourihane wrote: > On Wed, May 30, 2001 at 04:59:44PM +0300, Pasi Kärkkäinen wrote: > > On Wed, 30 May 2001, Alan Hourihane wrote: > > > > > > When I do that, the whole box crashes immediately after I press enter..:( > > > > even sysrq wont work anymore.. > > > > > > > O.k. Can you check your BIOS for something called "AGP Driving Value" ? > > > usually in "Chipset Features Setup". Set this to 0xFF. > > > > > > Also check for another option called "AGP Driving Control" and > > > make sure it's set to MANUAL (the other option is AUTO). Then it allows > > > you to enter a hex digit. Use the following... > > > > > > If yours is a KT133 board try 0xE7, if it's a Apollo Pro 133A try 0xDA. > > > > > > See if that helps. > > > > > > > Tried 0xFF, 0xE7 and 0xDA. Crashes with all of them. MB has KT133A-chipset > > (Abit KT7A). > > > Can you try adding this (after you've done them changes) to your XF86Config > file in the Device section. > > Option "AGPMode" "4" > Didn't help. Still crashes. I've got "Fail Safe Defaults" in BIOS, plus the changes above, and 4x agpmode in XF86Config. Any other ideas? (Reading older posts, if the Rate parameter is set to zero, people noticed crashes.. I'm trying to change it). - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon on KT7A
On Tue, 29 May 2001, Alan Hourihane wrote: > Can someone send me a copy of lspci -vv on this motherboard. > > I may have a workaround if someone would like to test. > Ok, here is the output of "lspci -vv" just after booting to linux (textmode), and when under X. If you have something to try, I'm willing to test.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) Subsystem: ABIT Computer Corp.: Unknown device a401 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] 00:0f.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA+ AGP- 64bit- FW- Rate= Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) Subsystem: ABIT Computer Corp.: Unknown device a401 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] 00:0f.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[Dri-devel] Radeon on KT7A
Hello! Anyone who has Radeon working without crashing on Abit KT7A ? BIOS settings seem to be very effective on this MB.. with "Fail Safe Defaults" whole machine crashes immediately after starting OpenGL-app. With some BIOS tweaking I'm able to run 3D for a couple minutes (and then we go..) Could people post their BIOS-settings? (ie. what you have changed from the Fail Safe Defaults). I'm using XFree86 4.0.3 (Debian unstable) and Warp's dri-packages for Debian. Thank you. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] G400 and blending
On Fri, 20 Apr 2001, Jon Pennington wrote: > On Fri, Apr 20, 2001 at 04:43:55PM -0600, Brian Paul wrote: > > Pasi Kärkkäinen wrote: > > > > > > Hello! > > > > > > Are there known blending bugs in the mga-driver (g400)? When I render many > > > additive polygons on the top of each other with small alpha-value > > > (something like 0.05) the result is something it shouldn't be with g400. > > > With software-mesa it's correct as well as with nvidia's drivers. > > > > > > If this is not a known issue, I might do little app that demonstrates > > > this.. > > > > I've found that the accuracy of blending isn't always very good on > > some hardware. Not much can be done about that. > > > > -Brian > > Pasi, does this happen if you're running Windows drivers on the same card? > Well that's something I didn't think about :) I'll try it (maybe tomorrow) and post the results. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] G400 and blending
Hello! Are there known blending bugs in the mga-driver (g400)? When I render many additive polygons on the top of each other with small alpha-value (something like 0.05) the result is something it shouldn't be with g400. With software-mesa it's correct as well as with nvidia's drivers. If this is not a known issue, I might do little app that demonstrates this.. Thank you.. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linking problem with libGL.so in .deb's
On Sun, 1 Apr 2001, Zephaniah E. Hull wrote: > On Sun, Apr 01, 2001 at 11:16:13AM -0700, Daryll Strauss wrote: > > On Sun, Apr 01, 2001 at 02:07:36PM -0400, Zephaniah E. Hull wrote: > > > > > > Actually, the problem is that libGL itself was miscompiled, I'm working > > > on tracking this down and properly fixing it. > > > > > > > Actually, after a little more checking (thank god for tee and regular > expressions) it seems that the problem is that xc/lib/GL/dri/dri_glx.c > uses va_start and friends without including stdarg.h > > That used to work due to either inter-dependences between other header > files which are being included, or due to va_start now being a #define > instead of a real function (I'm not sure if it was a real function > previously). > > However, in either case, recent changes in libc6 and gcc in Debian > exposed this, making libGL compile but fail to work with the error in > the previous messages. > > A (very simple) patch is attached. > Is this patch going to be included in the next build? - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linking problem with libGL.so in .deb's
On Sun, 1 Apr 2001, Joseph Carter wrote: > On Sun, Apr 01, 2001 at 05:52:22PM +0300, Pasi K?rkk?inen wrote: > > Is anyone else getting this: > > > > /usr/lib/libGL.so: undefined reference to `va_start' > > /usr/lib/libGL.so: undefined reference to `va_end' > > collect2: ld returned 1 exit status > > > > While trying to link your own (SDL/OpenGL) app to libGL.so.. > > > > > > I'm using debian unstable and todays .deb's of dri. > > The problem is a gcc bug recently uncovered by recent glibc. What version > of gcc-2.95 do you have installed? It was supposed to be fixed by now. > At any rate, a workaround is to make sure you explicitly link everything > whether you use them explicitly or not. For example GTK apps needed to > actually be linked against xlib and the like. Something related to -fPIC > I think. > Package: gcc Status: install ok installed Priority: standard Section: devel Installed-Size: 52 Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> Source: gcc-defaults (0.7) Version: 1:2.95.3-7 Provides: c-compiler Depends: cpp, gcc-2.95, cpp-2.95 Recommends: libc-dev Suggests: task-devel Description: The GNU C compiler. The default GNU C compiler for Debian GNU/Linux systems. . This is currently version 2.95.3 for this architecture (i386). . NOTE: This is not a final release, but taken from the CVS gcc-2_95-branch (dated 20001229). This is the version that is in unstable currently.. Ok, I'll try adding the libs to the commandline of linker.. > 2.95.3.ds5-10 is what I have and it claims to fix the problem. > Hmm.. is it somewhere as a .deb ? - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Linking problem with libGL.so in .deb's
Hello! Is anyone else getting this: /usr/lib/libGL.so: undefined reference to `va_start' /usr/lib/libGL.so: undefined reference to `va_end' collect2: ld returned 1 exit status While trying to link your own (SDL/OpenGL) app to libGL.so.. I'm using debian unstable and todays .deb's of dri. - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
