Re: OpenGL and hardware acceleration
"Uday Verma" <[email protected]> Wed, 09 Jul 2008 15:00:34 -0800
| Newsgroups | gmane.games.devel.opengl |
|---|---|
| Organization | Fat City Network Services, San Diego, California |
| Message-ID | <[email protected]> |
------=_Part_4108_57107.1215640684909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline If you do want to take a look at such an analysis, I did one for one of my assignment at school. You can take look at it here: http://www.cs.uiowa.edu/~uverma/cwork/22c251_2/assign1/index.html (follow text for second image) . We compared rendering performances of several different primitive rendering techniques. My analysis might not be entirely correct though and are speculations more than anything :). -Uday On Wed, Jul 9, 2008 at 4:55 PM, Mohan Parthasarathy <[email protected]> wrote: > Uday, > > I mostly agree with what you say. If you are developing an application, it > makes sense to look at macro things rather > than the individual calls. My question is mostly academic i guess. > Sometimes, out of curiosity, you want to know what > happens under the hood. I am just writing a simple application (nothing > fancy enough to get into performance problems yet) and want to know the > software/hardware role. I guess Michael pointed out a few things already. > > thanks > -mohan > > > On Wed, Jul 9, 2008 at 1:15 PM, Uday Verma <[email protected]> wrote: > >> I don't understand why it is important to have a one to one mapping of >> which calls are accelerated and which ones aren't. My concern would be the >> calls that are taking too long to execute, which may or may not be because >> they are not accelerated. Once I figure out a bottleneck in my program, I >> would investigate it further. >> >> Also, I like to think of constructs as accelerated/unaccelerated and not >> calls, how they perform better than other similar constructs (VBOs vs. >> Display Lists vs. Immediate). A driver might optimize calls to avoid >> unnecessary data flow across slower AGP and PCI-E busses but that is >> entirely up to the driver. >> >> I would rather just think of my implementation of something (rendering a >> scene, special effects, shaders, passes) as a whole and try to optimize that >> using the tools available. >> >> -Uday >> >> >> >> On Wed, Jul 9, 2008 at 12:30 PM, Mohan Parthasarathy <[email protected]> >> wrote: >> >>> Dave, >>> >>> Thanks. Agreed, that trying to infer anything based on an implementation >>> is not a good idea. But it would be nice if there >>> was some sort of a table that can describe what APIs are accelerated by a >>> given hardware. I understand that there may >>> be constraints under which the software fallback will be used. But then >>> having a simple one-to-one mapping would be >>> good to have. >>> >>> -mohan >>> >>> >>> >>> On Tue, Jul 8, 2008 at 7:35 PM, Dave Astle <[email protected]> wrote: >>> >>>> The thing about OpenGL is that it doesn't actually specify that >>>> anything has to be accelerated, nor does it include APIs to query whether >>>> specific features are implemented in hardware. So something that is hardware >>>> accelerated in one implementation might not be in another, and the only way >>>> to know for sure is to do performance profiling. You're not going to be able >>>> to glean anything useful from Mesa when it comes to this. In fact, having >>>> access to source code from several commercial OpenGL drivers, I'd caution >>>> against drawing any conclusions about driver internals from what you see in >>>> Mesa. >>>> >>>> If you really want to understand the internal workings of OpenGL, I'd >>>> recommend the spec itself, as well as whitepapers from NVIDIA and ATI. >>>> >>>> *Dave Astle* >>>> Staff Engineer, Advanced Content Group, QUALCOMM >>>> Executive Director, GameDev.net <http://www.gamedev.net/> >>>> Four-time author, Cengage Learning <http://glbook.gamedev.net> >>>> >>>> >>>> Mohan Parthasarathy wrote: >>>> >>>> Hi, >>>> >>>> Yes, i do have a graphics card and the acceleration is also working. >>>> When you download mesa, you also get >>>> a open source driver with it. I was trying to understand more about the >>>> internals on the driver acceleration e.g., >>>> what openGL APIs are accelerated etc. ? >>>> >>>> -mohan >>>> >>>> >>>> On Tue, Jul 8, 2008 at 4:25 PM, Gernot Ziegler <[email protected]><[email protected]>wrote: >>>> >>>>> Hej Mohan, >>>>> >>>>> Mesa is a purely software-based driver. >>>>> >>>>> Do you have any graphics card in your system? In that case, there >>>>> should be an OpenGL-capable driver. >>>>> >>>>> I suppose you use Linux? If yes: Use "glxinfo" to verify which driver >>>>> is running on your system. >>>>> >>>>> I am new to OpenGL. I have been reading books and trying out different >>>>>> programs. I downloaded the latest >>>>>> Mesa source code to understand more on what operations are accelerated >>>>>> by >>>>>> the driver. Some of them are >>>>>> obvious where the driver initializes the functions in ctx->Driver.XXX. >>>>>> For >>>>>> some others, it is hard to follow. >>>>>> For example, i could not find whether glVertex2f() is accelerated or >>>>>> not. It >>>>>> is hard to find whether the software >>>>>> fallback or the driver function is called. Is there a good >>>>>> documentation for >>>>>> the 3D driver interfaces with the >>>>>> Mesa framework so that one can understand the full flow of the OpenGL >>>>>> (from >>>>>> App -> driver) ? I searched but >>>>>> could not find a document on this. Any help would be appreciated. >>>>>> >>>>>> thanks >>>>>> mohan >>>>>> >>>>>> >>>>> Servus, >>>>> Gernot >>>>> >>>>> GPU. 3D Vision. Europe. Future. Now. >>>>> Drop by: www.mpi-sb.mpg.de/~gziegler<http://www.mpi-sb.mpg.de/%7Egziegler>- >>>>> www.geofront.eu >>>>> >>>>> ----- FAQ and OpenGL Resources at: >>>>> http://www.geocities.com/SiliconValley/Hills/9956/OpenGL >>>>> >>>>> -- >>>>> Author: Gernot Ziegler >>>>> INET: [email protected] >>>>> >>>>> Fat City Hosting, San Diego, California -- http://www.fatcity.com >>>>> --------------------------------------------------------------------- >>>>> To REMOVE yourself from this mailing list, send an E-Mail message >>>>> to: [email protected] (note EXACT spelling of 'ListGuru') and in >>>>> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L >>>>> (or the name of mailing list you want to be removed from). You may >>>>> also send the HELP command for other information (like subscribing). >>>>> >>>> >>>> >>> >> > ------=_Part_4108_57107.1215640684909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline If you do want to take a look at such an analysis, I did one for one of my assignment at school. You can take look at it here: <a href="http://www.cs.uiowa.edu/~uverma/cwork/22c251_2/assign1/index.html">http://www.cs.uiowa.edu/~uverma/cwork/22c251_2/assign1/index.html</a> (follow text for second image) . We compared rendering performances of several different primitive rendering techniques. My analysis might not be entirely correct though and are speculations more than anything :).<br> <br>-Uday<br><br><div class="gmail_quote">On Wed, Jul 9, 2008 at 4:55 PM, Mohan Parthasarathy <<a href="mailto:[email protected]">[email protected]</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Uday,<br><br>I mostly agree with what you say. If you are developing an application, it makes sense to look at macro things rather<br>than the individual calls. My question is mostly academic i guess. Sometimes, out of curiosity, you want to know what<br> happens under the hood. I am just writing a simple application (nothing fancy enough to get into performance problems yet) and want to know the software/hardware role. I guess Michael pointed out a few things already.<br> <br>thanks<br>-mohan<br><br><br><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Wed, Jul 9, 2008 at 1:15 PM, Uday Verma <<a href="mailto:[email protected]" target="_blank">[email protected]</a>> wrote:<br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c"> I don't understand why it is important to have a one to one mapping of which calls are accelerated and which ones aren't. My concern would be the calls that are taking too long to execute, which may or may not be because they are not accelerated. Once I figure out a bottleneck in my program, I would investigate it further.<br> <br>Also, I like to think of constructs as accelerated/unaccelerated and not calls, how they perform better than other similar constructs (VBOs vs. Display Lists vs. Immediate). A driver might optimize calls to avoid unnecessary data flow across slower AGP and PCI-E busses but that is entirely up to the driver.<br> <br>I would rather just think of my implementation of something (rendering a scene, special effects, shaders, passes) as a whole and try to optimize that using the tools available.<br><br>-Uday<br><br><br><br></div></div> <div class="gmail_quote"><div><div></div><div class="Wj3C7c"> <div><div></div><div> On Wed, Jul 9, 2008 at 12:30 PM, Mohan Parthasarathy <<a href="mailto:[email protected]" target="_blank">[email protected]</a>> wrote:<br></div></div></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="Wj3C7c"> <div><div></div><div> Dave,<br><br>Thanks. Agreed, that trying to infer anything based on an implementation is not a good idea. But it would be nice if there<br>was some sort of a table that can describe what APIs are accelerated by a given hardware. I understand that there may<br> be constraints under which the software fallback will be used. But then having a simple one-to-one mapping would be<br>good to have. <br><font color="#888888"><br>-mohan</font></div></div></div></div><div><div></div><div> <br><br> <br><div class="gmail_quote"><div><div></div><div class="Wj3C7c"><div><div></div><div>On Tue, Jul 8, 2008 at 7:35 PM, Dave Astle <<a href="mailto:[email protected]" target="_blank">[email protected]</a>> wrote:<br> </div></div></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div bgcolor="#ffffff" text="#000000"><div><div></div><div class="Wj3C7c"><div><div></div><div> <font size="-1"><font face="Verdana">The thing about OpenGL is that it doesn't actually specify that anything has to be accelerated, nor does it include APIs to query whether specific features are implemented in hardware. So something that is hardware accelerated in one implementation might not be in another, and the only way to know for sure is to do performance profiling. You're not going to be able to glean anything useful from Mesa when it comes to this. In fact, having access to source code from several commercial OpenGL drivers, I'd caution against drawing any conclusions about driver internals from what you see in Mesa.<br> <br> If you really want to understand the internal workings of OpenGL, I'd recommend the spec itself, as well as whitepapers from NVIDIA and ATI.<br> </font></font> <div> <p><b>Dave Astle</b> <br> Staff Engineer, Advanced Content Group, QUALCOMM <br> Executive Director, <a href="http://www.gamedev.net/" target="_blank">GameDev.net</a> <br> Four-time author, <a href="http://glbook.gamedev.net" target="_blank">Cengage Learning</a> </p> </div></div></div></div></div><div><div></div><div> <br> <br> Mohan Parthasarathy wrote: <blockquote type="cite"><div><div></div><div class="Wj3C7c"><div><div></div><div>Hi,<br> <br> Yes, i do have a graphics card and the acceleration is also working. When you download mesa, you also get<br> a open source driver with it. I was trying to understand more about the internals on the driver acceleration e.g.,<br> what openGL APIs are accelerated etc. ? <br> <br> -mohan<br> <br> <br> </div></div></div></div><div class="gmail_quote"><div><div></div><div class="Wj3C7c"><div><div></div><div>On Tue, Jul 8, 2008 at 4:25 PM, Gernot Ziegler <a href="mailto:[email protected]" target="_blank"><[email protected]></a> wrote:<br> </div></div></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c"><div><div></div><div>Hej Mohan,<br> <br> Mesa is a purely software-based driver.<br> <br> Do you have any graphics card in your system? In that case, there should be an OpenGL-capable driver.<br> <br> I suppose you use Linux? If yes: Use "glxinfo" to verify which driver is running on your system. <div> <div><br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I am new to OpenGL. I have been reading books and trying out different<br> programs. I downloaded the latest<br> Mesa source code to understand more on what operations are accelerated by<br> the driver. Some of them are<br> obvious where the driver initializes the functions in ctx->Driver.XXX. For<br> some others, it is hard to follow.<br> For example, i could not find whether glVertex2f() is accelerated or not. It<br> is hard to find whether the software<br> fallback or the driver function is called. Is there a good documentation for<br> the 3D driver interfaces with the<br> Mesa framework so that one can understand the full flow of the OpenGL (from<br> App -> driver) ? I searched but<br> could not find a document on this. Any help would be appreciated.<br> <br> thanks<br> mohan<br> <br> </blockquote> <br> </div> </div> Servus,<br> Gernot<br> <br> GPU. 3D Vision. Europe. Future. Now.<br> Drop by: <a href="http://www.mpi-sb.mpg.de/%7Egziegler" target="_blank">www.mpi-sb.mpg.de/~gziegler</a> - <a href="http://www.geofront.eu" target="_blank">www.geofront.eu</a><br> <br></div></div></div></div><div class="Ih2E3d"><div> ----- FAQ and OpenGL Resources at:<br> <a href="http://www.geocities.com/SiliconValley/Hills/9956/OpenGL" target="_blank">http://www.geocities.com/SiliconValley/Hills/9956/OpenGL</a><br> <br> -- <br></div></div><div class="Ih2E3d"><div> Author: Gernot Ziegler<br> INET: <a href="mailto:[email protected]" target="_blank">[email protected]</a><br> <br></div></div><div class="Ih2E3d"><div> Fat City Hosting, San Diego, California -- <a href="http://www.fatcity.com" target="_blank">http://www.fatcity.com</a><br> ---------------------------------------------------------------------<br> To REMOVE yourself from this mailing list, send an E-Mail message<br> to: <a href="mailto:[email protected]" target="_blank">[email protected]</a> (note EXACT spelling of 'ListGuru') and in<br> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L<br> (or the name of mailing list you want to be removed from). You may<br> also send the HELP command for other information (like subscribing).<br> </div></div></blockquote> </div> <br> </blockquote> </div></div></div> </blockquote></div><br> </div></div></blockquote></div><br> </blockquote></div><br> </blockquote></div><br> ------=_Part_4108_57107.1215640684909-- ----- FAQ and OpenGL Resources at: http://www.geocities.com/SiliconValley/Hills/9956/OpenGL -- Author: Uday Verma INET: [email protected] Fat City Hosting, San Diego, California -- http://www.fatcity.com --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [email protected] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).