-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Deucher wrote: > 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?
Ish. If more drivers supported the RGB Xv formats, we might be able to talk the Adobe guy into adding Xv acceleration into Flash. As is, Flash is RGB-based, and they're not interested in bundling a YUV conversion library just for Xv. (Never mind that they're ALREADY doing YUV->RGB in software for Flash Video...) It's just a thought, since I bet we could equip all the DDX drivers with RGB Xv a LOT faster than we could support GLSL and FBOs in Mesa. That's really the only reason I brought it up. Hmm. Now that I think about it, there's a lot of reasons to use Xv in Flash. In video mode, especially full-screen, it would be a lot faster to draw the video controls in YUV mode, and just pass a YUV panel into Xv, than to do the software conversion. But then again, we don't have Flash source code, so this is the best short-term solution I can come up with. Or I guess we could just keep on pluggin' and ignore Flash-specific needs for now. ~ C. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN2W0ACgkQeCCY8PC5utBolgCcDG7jVBYBlb1ibyigXVGs9xdp kEoAn08behFXqrT6EbEv1ymE+zhDEfvj =Pqdp -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
