On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad <[EMAIL PROTECTED]> wrote: > Hey Corbin, > > I'm forwarding this email to the public ML. Thanks for the feedback. > > Regrads, > > -------- Original Message -------- > Subject: Re: [Mesa3d-dev] glxinfo and "client glx vendor string" with > ATI cards > Date: Fri, 25 Jul 2008 10:50:07 -0700 > From: Corbin Simpson <[EMAIL PROTECTED]> > To: Alexandre Conrad <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexandre Conrad wrote: >> Philipp Klaus Krause wrote: >> >>>> """ >>>> Maybe this affects only the fglrx driver since I get this with my NVIDIA >>>> card: >>>> >>>> :~$ glxinfo | grep "client glx vendor" >>>> client glx vendor string: NVIDIA Corporation >>>> """ >>>> >>>> So the NVIDIA drivers (proprietary) seem to put some information here >>>> (thus enabling flash hardware accel). So I'm really not trying to make >>>> things incorrect, I'm just trying to make things more accurate by >>>> filling in more "fields" as it might have been "forgotten". Again, I'm >>>> not pointing my finger towards Mesa, I want to figure out who fills in >>>> this data. >>>> >>>> BTW, What does "SGI" stands for? >>>> >>> Nvidia uses their own GLX, so they put "NVIDIA corporation" in the >>> string. Everyone else uses the GLX initially made by SGI. SGI was a >>> vendor of highend graphics workstations, they played an important role >>> in OpenGL standardization. Lately they're more into supercomputing than >>> graphics. >> >> "Silicon Graphics" rang my bell but I was just unsure how they were >> related with "client glx vendor string" thing. That and why nvidia has >> something else than "SGI" makes sens to me now. >> >>> GLX is included in the Mesa tarball. You could change the vendor string >>> in /src/glx/x11/glxcmds.c (currently :static const char >>> __glXGLXClientVendorName[] = "SGI";). >> >> Great. I'll try to hack this, although I'm not sure to have the >> compiling skills... >> >> Thank you so much Philipp and Michel for your help and suggestions. This >> definitly cleared things up. I'll point this thread to Adobe. > > Howdy. Sorry for getting here late. :3 > > One more caveat: > > Flash requires the following extensions to be present, even if it is not > actually using them, before it will enable OpenGL mode: > > - - GL_ARB_multitexture (done) > - - GL_EXT_framebuffer_object (FBO -> mem manager) > - - GL_ARB_shader_objects > - - GL_ARB_shading_language_100 (GLSL) > - - GL_ARB_fragment_shader (done) > > So we need a memory manager for DRI, and also GLSL, before we can get > HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) > > There was also a blocker bug with Mesa-based libGL on the Adobe side, > but it's been handled. > > Oh, and finally, the only reason they're not using Xv is because only > one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- > theoretically, all of the textured-video Xv implementations could > support RGB, and this would be fairly easy (I've already got a > half-baked patch sitting around for this on xf86-video-ati...)
Actually the radeon overlay Xv adapter exposes RGB surfaces as well. Do RGB Xv surfaces really give you anything over using render? Alex ------------------------------------------------------------------------- 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=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
