WWDC2001 Session 408

Transcript

Kind: captions Language: en good morning everyone to present session 408 OpenGL advanced optimizations that Elektra introduced OpenGL manager John Stauffer hi so today we're gonna talk about advanced optimizations in OpenGL so hopefully we'll learn a few things about how OpenGL works and things you can do to try to tune your applications so so what we'll learn is the key components that you need to look at when you're trying to tune your application for higher frame rates the thing that I always like to start talking about is application component and the reason for that is that about 75% of the time is spent in the application in a comedy OpenGL app and so therefore since 75% the time is spent there that's where you have the potential for getting the most benefit so if you don't tune your application obviously you're not going to get a lot out of OpenGL because you'll spend too much time in navigation so we'll spend some time just talking about techniques for tuning your application to drive up in jail better and some hints on and tips on how to do that the second thing is setup so how to properly setup OpenGL how to get some machine information how to properly configure and scale your application such that it will run well on the machine that you're targeting the third thing is state management so state management basically is where a large percent of the time that is spent in the actual OpenGL time frame is spent in state management so state management actually is more important than a lot of people think if you do a lot of thrashing of state in OpenGL you can actually decrease your performance quite a bit texture management texture management is important to keep your application correct correctly scaled for the hardware so that you're not paging a lot you're not spending a lot time running out of video memory and paging on and off vertex operations so vertex operations are important obviously to be able to get a lot of data to the card have an optimal format for sending the data keeping the data flow moving quickly to the card and per-fragment operations so per fragment operations are their operations that the card itself is going to do so it's not CP related but it's car.the it's what the graphics card is going to have to do to generate your final image and there's some trip there's some tips there to offload some of the work the graphics card is going to need to do extensions so a lot of times there's extensions that you can utilize that are either directly geared towards optimizing your application or will help you get the animation effect you're looking for with a simpler path so you won't have to do all you can simplify your CPU work by utilizing an extension multi CPU or multi thread utilization obviously if there's a machine that has two CPUs it's an ideal situation to spawn another thread maybe move your graphics off to that other CPU and lastly what we'll talk about briefly is where to look for more information so starting off here just to get the the image of what OpenGL looks like and how data goes to OpenGL it's important to think about in jail is a data stream so OpenGL fundamentally is a data stream going to the card and how the data is organized in that stream is very important because it will give you hesitations if you have too many operations of one type or if you're flushing and breaking that stream and causing discontinuities so the fundamental type of data that goes to up Jill is vertices which is your 3d data in state so you can fundamentally this is a simplistic view but you can fundamentally break it down and those two types of our data sets that go to the card and how that data again gets organized and sent to the card can make a big difference so application so the thing to remember when you're looking at writing an OpenGL application is first you have to decide obviously what type of performance you're looking for and to do that you need to obviously decide what type of user interaction there's going to be you know whether you need high frame rates because the user needs a fast response time on the graphical feedback which may mean you need 30 50 60 frames a second to get the proper feel quality display so you'll need to decide what kind of quality display in your application you're going to need and obviously those two things can be related so adjusting the right quality with the frame rate is going to give your user the best experience so it's important to keep those in mind your target platform so deciding what your ideal platform is going to be and what you're going to run best on is going to be important so that you can potentially scale your application to run well on those those target platforms and the things to remember about the target platform are video memory size how much system memory you're going to be needing for the application and potentially what graphics cards in the system so that you can have the animation effects that you're looking for so the thing that a lot of applications provide obviously is a mechanism for users to to adjust the quality settings within the application and this is usually important such that an application or user can himself or herself select the trade-off they want between performance and quality such that they can have some influence on their preferences as to how fast the application will run or what the quality will look like so the first thing we do and we do this a lot at Apple's we'll take an application to try to analyze where the time is being spent we'll take the app of the application and we will run it with a null layer of OpenGL we'll try to figure out how fast OpenGL with you if OpenGL was infinitely fast how fast will an application run and this gives us an upper bounds and this helps us understand what the application itself is doing and what the application what profiling may be needed to be further done in the application to tune it so two ways - depending on your programming environment and it just reminder actually all the code that I'll be showing today is Mac OS 10 cocoa based I'm going to since we have limited slide space I'm going to stick to those function calls so to know about the OpenGL layer there's a couple ways you can do it your application very easily for the CGI layer if you're programming straight to the the core OpenGL layer you can simply set your OpenGL context to null and what that does is that actually internal to opengl that will have opens you'll set all the entry points to a no op so they will do nothing and if you're at the applicant layer then you can use an applicator call just to clear the current context and it's equivalent to setting it to null and again that will just set all the entry points and dull to no ops and so what you want to do once you've done that is you want to measure the time that's spent in your application to get a feel for what level of performance your applications had and here we see a little code snippet using get time of day to just quickly calculate time spent in application so once we've done that we can calculate an open loop OpenGL no op frames per second that your application is capable of so obviously if you're once you've gotten to this point you realize that you've no op open G allowed it's a it's infinitely fast and you're not achieving the frame rates that that you would like to be at you can immediately start you know thinking about going into your application and tuning your application what we do is you can do a quick calculation assuming an average application spends about 25% of the time in OpenGL you can take that open loop frame rates per second and just multiply by 0.75 so lower that frame rate down and get an estimate of what you're going to run what your performance is going to be once you enable open Jill and if this estimated frames per second isn't where you want to be again you're gonna have to start looking at either OpenGL or you're gonna have to start looking at at your application so to start tuning your application on OS 10 there's a variety of tools to do this one tool that's very useful is called sampler for anybody that hasn't used sampler it's a a tool that will thread it's a threaded tool that will go out and look where your call stack is at any given time and it will generate a sample and heuristic of where the time is being spent in the application so this tool actually is very useful it works for CFM apps and Mach Oh apps and it's part of the developer install so it's on your disk at developer applications sampler and it's a very useful tool we suggest everybody become familiar with how to use it and it will show you where all the hot spots are and you're in your application code it'll even show you where the hot spots are in the app in the operating system itself but you may want to run this with without OpenGL and just run your application open loop and just stress your application and find out where the hot spots are okay so that's enough talking about the application so setting up Open GL the first thing you need to do obviously is to go out and query for devices and find what's what you're what devices you have how many devices and such so I've got a couple code snippets up here that will show you in core graphics how to get your device at your main device and how to from the main device generate an OpenGL display mask so the first code snippet here is just the main device if you wanted to go through all the devices you could get all the active display devices from core graphics loop through them generate a display mask that represents all of the all the devices on the system and really it's going to depend on whether you're a full screen or window to application as to what you're going what the right thing for you to do is so what we can do with this information is we can find out how much video memories in the system on each graphics card so here we've got a a code snippet that will query the renderer so for video memory and it goes through the loop and it will look at each device querying it for video memory size and this is going to be important because as we start to try to adjust or tune our application we're going to want to make sure that the amount of textures we have the resources we're going to be consuming on the card are gonna fit in video memory so we're going to want to know this usually upfront if we have a texture intensive application okay so when we look at the video memory size there's several things that we may want to adjust again we may want to adjust exercises but we may also want to adjust the screen resolution if we're going to be switching into a full-screen mode let's say we're going to have the opportunity for picking a screen depth in a screen resolution if you have determined your application needs more video memory and it's potentially available in the current display mode then you'll want to switch it down to a 16-bit color potentially or you'll want to switch down the resolution give the application more breathing room on the graphics card and that will help with keeping your application out of a text or paging mode and give the a higher frame rate during the running in the application so the other thing you'll want to do is to find out what CPU you're on one thing that we find very useful is internally the open till obviously is using altivec and altivec can give you substantial performance boosts if you utilize it so finding out if you're on a g3 or a g4 is very useful and tuning to that condition can be very beneficial the other thing to remember about that is that typically the difference between g3 and g4 is that g4 systems are going to faster and you may want to think about adjusting your data set size to accommodate faster systems so quickly talking about state management so state management again is is the process of switching wet mud OpenGL is running in to get your proper configuration for drawing your graphics the thing to remember a state changes you want to minimize those what we have found is that in a lot of applications the amount of time that's actually spending OpenGL a considerable portion of that is actually in doing state management and if you unnecessarily change state you can cause a lot of thrashing down on the card because OpenGL has to go through a lot of setup to properly configure the graphics card for each state change some state changes are obviously more expensive than others and we'll go through a few of those which ones to avoid but in general you want to group your data to minimize state changes and that will have a significant impact on what performance you can ultimately achieve so some general calls you want to avoid geo flush so you want to avoid geo flush because what it actually does is if you again think about OpenGL as a command stream going to the graphics card geo flush tells the graphics card terminate the current command stream send it to the graphics card and start me a new one so you've just chopped that command stream and and sent it on its way and the reason that you don't want to do this necessarily is because there's only so many command buffers that you can have allocated your application in a given time so if you sit there and call Gio flush a lot you will use up the buffers that you have available to your application and your application may be starved for available space to stick you know put data on the stream so unless you have to don't call Gio flush and there's actually very few reasons to ever call it usually you can find some other way to do what you're looking to do if if you want the user to see something immediately usually you just call swap buffers to get the data swap of the screen and swap buffers actually calls is implicitly calls a flush so when you call swap it terminates a stream sends it to the card and so you don't necessarily have to call geo flush yourself another call that's even more expensive is geo finish so geo finish is like a GL flush except for it sends the data to the card and it actually both block they're waiting for the graphics card to finish its drawing so once all the commands have gone to the graphics card finish to come back and return then GL finish will actually return to your application so an important performance thing to keep in mind is that geo finish is it's very expensive it can be a blocking call that can take quite a while to return so you want to avoid reading data back from OpenGL and when it comes to state management typically what you want to do is you want to keep the data in the application that you will need later and not ask OpenGL for back depending on the driver and what you're reading back they can get very expensive reading back data can actually be the same cost of calling a GL finish because if you're reading pixels back for instance the pixels actually had to be represent the current state that you are expecting and that is you've drawn all these command you issued always drawing commands you're expecting the pixels to be in the in the buffer well so opens you'll realizes this and it when you try to read some pixels back it's going to have to call finish wait till all the commands are finished wait till it's drawn everything before it and give you the valid pixels back so so you don't want to read the frame buffer unless you have to you don't want to be reading state some state could be expensive to read and you don't want to read textures unless you have to they all can have varying penalties depending on what mode you're running in so what you also want to think up think about when you're writing up gels avoid complex state settings if you don't know what a state setting does usually it's a bad idea to just arbitrarily throw state changes in there what you want to do is keep the state as simple as possible because this will help the graphics card run in its most optimal mode this will also usually lead to less state thrashing when you are trying to transition from one drawing routine to another you won't have to do as much state setup and teardown so it'll lead to less state transition so keeping it simple it's obviously a simplistic concept but it's something to keep in mind so some basic complex states that you want to avoid are lighting user clipping planes and and full scene well anti-aliasing like anti-alias lines and dailies points polygons and the reason you want to avoid those is because they can be very expensive to do with modern hardware lighting and user clipping planes and even anti aliased lines are pretty fast so again it may depend on the particular graphics card you're running on but in general lighting is very computationally expensive and unless you have a real need for it you'll want to keep that disabled even on the high power graphics cards today if you start an able lighting you will you will cause a graphics card to do more processing and you will ultimately lower the performance now whether you actually see that will depend on how fast you know what kind of demands your applications putting on the graphics card but those are very complex operations for the graphics card to perform so texture management so this is a very important topic because a lot of games nowadays or applications in general using a lot of textures and how to properly manage those can be making a big difference in the applications performance so several things to remember avoid uploading the texture more than once ideally what you want to do is you want to give up until the texture and not keep handing it to OpenGL not don't delete it and then give it to back to it later if at all possible and instead let OpenGL do the management the bookkeeping of whether the texture should be in video memory or not avoid so again avoid keeping a copy and that will save avoiding keeping a copy in the application will save your safe system memory the thing to remember here is that OpenGL will keep a copy and so you're gonna have two copies if you keep one in the application and one in open and one is gonna be kept in OpenGL you're gonna have two times that texture that texture size so it's best if you delete yours if possible so ways to get data textures data into the graphics card or into the driver fast there is an extension called Apple Apple packed pixel so this is the fastest way to get pixel data into OpenGL and it's a very flexible format it'll support all the standard OpenGL pixel types by Apple pixel type so it'll also support a number of rather odd types that may be useful for you you know like five six five or three three two depending on what your quality requirement is or whether you don't need a high R it don't need a deep bit depth per component you can get away with some of the smaller bites bits per pixel components minimize the how often you change your current texture so changing your current texture is actually one of the most expensive operations you can do and what that means is that changing your current texture is a GL bind call and when you when you bind from one touch to another you're you're basically just causing OpenGL to potentially reconfigure all of its texture combiners in the hardware for the new texture because the new texture it's going to require different blending modes and it can be fairly expensive to do that setup so typically what you want to do in the application if you have a lot of data is you want to group your data in groups comp with common texture types so that's the the best way to group the data such that you minimize your texture changes so scale textures to your Hardware size so again earlier we looked at finding the vram size so what you want to do is you can do some basic rudimentary math in your application and just fundamentally try to scale your your application to fit on the graphics card so if you have a lot of textures you'll need to calculate how many you're going to need necessarily on the graphics card anytime it's not it's not terribly important to get it exact but you would like to keep it within a reasonable bounds OpenGL is very efficient that paging so what you'll not want to do is is try to keep OpenGL always out of a paging mode you don't want to try to second-guess the exact size of the video memory available and wearing exactly OpenGL is going to go into paging mode because if you do that you're not gonna let OpenGL grow and utilize some of the mechanisms internally to the driver that will try to optimally page textures on and off so up until uses the internally for paging textures on and off it's called LR um ru algorithm that stands for at least recently used most recently used so depending on how committed you are how many textures are committed per scene whether you're over committed that scene it will actually switch to different mechanisms for paging textures on and off trying to optimally keep the right set on the graphics card and not unduly page off ones that are going to be needed again so that that algorithm actually works pretty well also particular to us 10 is we've built the mechanism that causes almost no CPU work to page a texture so once the texture is in OpenGL and had to get paged off it back in the system memory let's say it costs very little CPU work to get it back into the in the stream and back uploaded on to OpenGL so while it will cost a little bit of memory bandwidth while it's getting read and it's going to cause some AGP traffic the CPU cycles spent or gonna be pretty minimal so we find that letting OpenGL do the paging isn't expensive for the CPU to CPU can keep on going and as long as you're not causing too much bandwidth across the AGP you can get away with a fair amount of paging so depending on what you're doing you're going to also want to split your textures into tiles for and I've got a demo of this in a bit where if you're doing wanting to do smooth animations of some sort trying to amortize the data stream as it goes to the card and trying to keep the drawing moving while large images are moving up the stream so again if you look at the whole process of OpenGL is a big data stream if you have a four megabyte texture that's a big block of data in the middle of your stream so you can envision that under some circumstances it'd be good to interlace that upload with some polygon drawing maybe a frame here and there such you can amortize the texture upload time going across the bus and keep animations flowing so so here's a little diagram for texture management one thing that we recommend on OS 10 is to split your texture loading off to a separate thread if you're going to be spooling through a lot of textures it's a good idea to maybe spawn a thread that will do that work for you and the reason for that is that there's couple reasons one is you can utilize a second CPU and two you can utilize pre-emptive multitasking to to balance out the loading the act of maybe reading a texture from disk the cost of loading it in OpenGL you can you can use the pre-emptive capability as well as tend to spread that cost out so you don't end up with a a single point in your open Junt your rendering stream or your in your CPU cycles that are blocked trying to get this texture uploaded and processed so it's a good idea so if we look at this this is a basic diagram of how to set up a two threaded or what happens when you set up a two threaded application one loading the OpenGL textures and one doing the drawing so what happens is the first thread is loading the textures and those textures will get processed and put into the driver into the kernel driver so the kernel will have them at this point and they will be sitting in the kernel waiting to be uploaded to the card so you'll have done most the work of CPU cycles on the other on the primary thread of getting the data into the kernel and then you could have your second thread come along and issue the drawing commands and as long as you have your thread synchronization correctly organized then your data will be there by the time you need it and everything will just flow much smoother so I've got a demo of this and this demo shows this basic concept that the diagram had there so what this demo tries to show is a couple concepts one is how to balance the requirements of your application with quality and smoothness of frame rate so what we have here on the left is we have a slider that will adjust the quality of these images so for instance down here at the bottom I can get 64 by 64 textures and up on the top I get 1024 by 1024 and everything in between so what's interesting to to look at here is if you're trying to say write a screen saver for instance and you're trying to get these images up to the graphics card while maintaining smooth animation you'll see that we get a hesitation and that hesitation is because one we only have one thread doing the loading and the animation so we get a large hesitation while we spool the texture off disk we decompress that JPEG and we load it into OpenGL and give it to the driver so we can see that that this isn't going to lead to a very nice screensaver so we start looking for techniques to smooth that out and one thing we can do is we can spawn a thread and we can give the that thread the job of spooling the texture off of disk and loading it into a pill so what we see now is we see that it's a lot smoother but it's not perfect so here's where you can start deciding whether frame rate and quality are important one thing you can do is obviously if you're not needing to achieve those kinds of rates of uploading and animating you can slow it down and the hiccups are almost gone another thing you can do obviously is if you want to stay relatively fast animations is you can lower your image quality so we're still going a little bit too fast to get absolutely smooth animation but so you can see what this technique we've basically eliminated the pauses in the animation stream and we're able to get smooth animations while we're spooling through a large quantity of textures this demo actually will spool through 200 megabytes of textures simulating a fairly large scenario and then the third thing we can do after we decided of frame rate quality we can also go to a tiled mode so a tile mode is an attempt to split the texture into many pieces and to amortize the cost of uploading that across the bus I've had a little bit of problem with the tiling mode so we're gonna give it a shot though so the tiling both theoretically now is using the primary thread to load the images and and then the drawing thread is is well there we go so I've got some thread synchronization issues it's an attempt to try to amortize the cost of moving the data across to the card so with the MP case when it Susan went to the multi-threaded case we offloaded the the main thread its job of loading all of the data from disk and then giving it open Jill but what we were not able to do in the multi-threaded cases we're not able to amortize the cost of moving that image across the bus across a GP up to the video memory so so we still see a small hiccup in the MP case so as soon as we go to tile mode what I've done here is I've taken a small piece of the tile a small piece of the texture and I've uploaded one small piece at a time so I'm able to upload one small piece per frame and that way not see a big 4 megabyte chunk of data in the data stream as it goes to the graphics card and done correctly you can make get a lot of data up in the system with very smooth animations so again if you look at the different scenarios looking at the stream case so there it is multi-threaded it's a lot smoother and if we go tiled so that's a little example of how to try to get through a large large amount of texture data and techniques to get it through the system without hesitating your animation okay so now we're going to talk about vertex operations so vertex operations obviously are the process of getting actually getting a 3d data to the graphics card and there's a lots of good information about how to do that correctly and it'll vary depending on how the data is organized for your application and potentially you know what's best for your animation technically or what you're animating so if we look at the standard opengl path which is called the media mode path which uses a Geel begin end the thing to remember with GL begin end always is that you want to pass as much data as possible between the jail begin and end you want to call jail begin end as infrequently as possible and the reason for that is that there's a lot of function call overhead gl begin will try to do some card management some state management and it will induce function calls to the lower-level system so reducing the begin end is the first thing you can do to get better performance and I'll go through an example a little bit of code a little bit after these couple slides here that shows how to do that so use efficient primitives is the next thing to remember triangle strips are obviously the a good primitive to use because you get a lot of triangles pervert text if you're using individual quads or individual Verdean dividual triangles you're gonna get about three times the amount of vertex data going through the system and it will hurt your performance quite a bit if in some scenarios where you are cpu limited use vertex arrays so vertex raises the API for passing a whole strip of data to OpenGL once so it has the benefit of reducing the number of function calls you're making so you you save right there but it also gives OpenGL the opportunity to optimize how the data is moving into the stream and there can be a big win there so the other thing that you can use in conjunction with vertex arrays is compiled vertex array so compile vertex array is probably one of the most optimized paths and OpenGL for getting data through the system currently and it has the benefit of highly optimized assembly code runtime generated assembly code the deficit is is that if you are passing small amounts of data there's a little bit of overhead of logic to get into the routines so you're not going to want to call a compiled vertex array with three vertices because you're better off going to GL begin end because that's lower overhead for a small amount of data so if you have large bolt large arrays of data let's say greater than sixteen sixteen may be pushing the smaller end of it but say greater in 16 vertices per array try using compiled vertex array to probably get you some benefit so looking at a chart here that shows you primitives along the x-axis and number of triangles that you can render per second along the Y you can see that that the type of primitive can make a large impact and the number of triangles that you can send through the system so down at the very bottom is polygons polygons is a most rudimentary way to send data to OpenGL and then near the upper end of the spectrum as triangle strips so triangle strips is the best way to send data through the begin in immediate mode path and then at the very far right is compiled vertex array so you can see that Kapaa vertex array if fed correctly can give you substantial boost in performance now the green bar shows what you can do on a g3 and the blue and the orange bar shows you on a g4 there's not a huge difference but it can make a big difference ultimately in your performance and that's primarily these numbers are actually were on a graphics card that we're not did not have transformer lighting on the graphics card so for a card that does do transformer lighting it'll make less of a difference if you have a g3 or g4 okay so looking at how to potentially optimize OpenGL I've got a number of slides here to just basically walk through the process that every one should look at and when when they're trying to figure out how to simplify their code and how to make it more optimal so we start off with a basic loop that is going through setting up a smooth shaded color mode setting up a color and then going and then drawing a triangle so we're doing this every time through the loop so we're drawing one triangle we're doing a state change per triangle and obviously we're not going to get a lot of data through this because it breaks every rule we have and that is you're giving Steve changes and you're not passing a lot of data per begin end so the first thing we do is remove state changes out of the loop and that will obviously give you the benefit that now we're we're passing a lot of data we're not changing the state and we're not causing global jail to have to do a lot of state management below but we still haven't pulled any you know done in the optimizations with how we're passing vertex data so the next thing we do then is well actually we simplify the state and we simplify by just going to a flat shaded so we notice that we're not passing a color per vertex meaning the colors flat shaded triangles so we're gonna change that to flatten but then we pull the triangles out of the loop and that's an attempt to maximize the amount of data per begin end and by doing this we can increase the performance by quite a bit and in fact after this I have another demonstration to show you the effect of that it can be pretty dramatic just doing that step alone then what we do is we try to simplify the API that we're utilizing instead of passing all the data through registers we pass a vertex a pointer to the data and it allows OpenGL to potentially optimize how it's copying the data you're not doing a lot of register setup to get the data through then we take the step of realizing that what we're actually passing is a triangle strip so we we change the type to triangle strip and we reorganize how we're passing it and so now we've just reduced the amount of data going to open jail by a factor of three again getting a big performance boost out of doing a step like that and then what we do is we realize that we have all the data actually in an array so we start using a vertex array and using draw elements to draw out of that array so now we've eliminated the loop all together and we are simply making five function calls to handle all the drawing whereas if we looked at the beginning of the slides we were probably making hundreds or thousands so we've eliminated all the function call overhead and we have given open GL an opportunity to try to optimize maternally for how it's going to want to get the data into the command stream so now I have another demo showing some of that effect this is actually a pretty neat demo and so what this data what what this demo is is a spherical map mesh that's being animated with a wave motion and where we start this this application right now is in a mode where the application hasn't been tuned and the rendering hasn't been tuned and the way we can tell that is that the red bar represents the the time being spent in the application the green bar spent simulates the time being spent calculating the wave motion and the blue bar is the time being spent in OpenGL so we can see where we're spending quite a bit quite a bit of time at all these for spending most of time in the application so a little experiment that's interesting to run as if I take this application tuning slider and I bump it all the way up so that the application becomes tuned we can see we get about we go from 20 frames per second almost a 40 so we almost double our frame rate by doing that ok so now if I move this slider over here which simulates optimizing OpenGL through the basic steps I just went through the first one is individual triangles the second one here has now Pat is passing moved the begin end outside the loop and it's passing as much data as possible per begin end so we can see that we immediately get some performance out of that we can see the blue bars changing by about a factor 2 but OpenGL performance hasn't changed a whole lot it only went up about 5 frames so by doing that step we didn't get a whole lot now if we go to the top one that's using vertex arrays and again it didn't change a whole lot so the interesting thing to learn about this is that if we take the slider and we move it up for the application now we realize that we have gotten 100% improvement on just optimizing the applications so optimizing one or the other only got us a marginal improvement to 2x improvement but if I optimize both I go from 20 frames a second to 60 so I get a 3x improvement so the combined effect is very important so it's important to to realize that where the x means spin is is can't be the application or OpenGL so the second thing we can do then is like we've been showing here is to spawn a thread now if we spawn a thread and we move the green bar on to the thread we can see that now we are utilizing both see both CPUs in this this machine this machine is a dual 500 so now we're animating at 200 frames a second and we started off at 20 so we got a 10x improvement out of this and so now it's animating silky-smooth whereas before it was barely crawling along at 20 frames a second so this is a good example of example of where you can start from a pretty dismal performance and do some simple things and all of a sudden the whole application comes alive and you're getting you know 1.5 million triangles a second and able to deliver a much better application okay so okay so now we've kind of talked about the application setup basically how to drive OpenGL and all those things are fundamentally CPU oriented operations and that's a process of optimizing how effectively you're utilizing the CPU so we're now we're going to talk about per fragment operations a little bit per-fragment operations are fundamentally what the graphics card is going to have to do to convert your data from a triangle to the image that you see into the frame buffer and what types of blending or texturing operations need to be done and there's a few things just to keep in mind while you're doing this while you're programming one is to utilize multi texture instead of multi pass so basically all the graphics cards on OS 10 that are accelerated on OS 10 today have multi texture multiple texture units so if you want to apply two textures let's say you can do it in one pass you can load two textures one intersection unit-01 detection unit one and you can apply both textures simultaneously and this actually has two benefits one is that again lowers the CPU overhead because your application is not having to loop through the rendering twice and reissue drawing commands to do the second pass but the second one is is that it helps the graphics card optimize its memory traffic because you're not writing to the frame buffer on one pass and then having to come back on a second pass or write the pixel again instead you're allowing the app the the graphics card to read to text tools out of the texture units out of the textures you've defined combined them and write it once out to the frame buffer so it lowers the ultimate band that you're consuming on the graphics card so you can you can get performance a couple ways by going to a multi texture instead of multi pass so avoid when possible obviously anything I'm going to say here is just a suggestion of things to try to work your way around and sometimes you're looking for an effect and you have to do these operations but avoid read-modify-write operations on the frame buffer so read-modify-write operations are anything that will requires the frame buffer value to participate in the value that participated in the color calculation that will result and be finally put back into the frame buffer so things that do that are blending so if you're blending with the final destination of the frame buffer it's gonna have to read the frame buffer it's gonna have to read its textures it's going to combine it all then write it back out so you're gonna get 2x the bandwidth utilized on the graphics card of the frame buffer as opposed to an algorithm that say didn't use a blending mode now again blending is pretty common so obviously if your application requires it you'll have to use it Z buffering is another thing that Italy usually will result in a read modify write and when possible just eliminate enabling Z buffer so that you're not doing a read modify write on that Z buffer okay no thing that's important to to keep in mind is that modern graphics cards have the ability to do high-level coding for you so if you're drawing lots of triangles it can ahead of time : goes out and it's called hierarchical Z and hierarchical Z will very quickly take a primitive that you're drawing and throw it out and it won't result in a read modified right to the frame buffer because it knows that that's occluded through some varying techniques in the graphics card and it will save you memory memory bandwidth on to the graphics card so the way to utilize this is to render front to back and the reason you render front to back is because want to draw things that are near you and then when you draw something that's behind it the graphics card will has techniques for really very early determining if that's behind something already and discard it very early before it has to do a read-modify-write operation on the z-buffer and this is the most effective way to let the graphics card do its job of utilizing these silicon gates that have been dedicated to this and can be quite effective if you do render front to back so so some of this is a review we're gonna talk about opengl extensions and what OpenGL extensions can can help you we already talked about compile vertex array but just review really quickly this is good for large number of vertices it reduces a number of transformations it reduces memory traffic it allows OpenGL to pre compile data into a frame into an AGP buffer ready for transmitting to the card so whenever possible again use kapal vertex array texture compression texture compression is also very good extension to use it allows to you to minimize the system memory bandwidth of moving that texture around it saves you system memory itself it saves the bandwidth of moving that texture up to the graphics card and it also saves can benefit the graphics card itself by lowering the bandwidth it takes to read the texture a text aloud and to render with it and because it will do on-the-fly texture decompression and it will better utilize the on cache memory on the graphics card so texture compression can be effective it's really gonna depend on where your limitations your where your performance bottlenecks are in your application but it's a good one to keep in mind multi texture is the extension for doing multi texturing like we've mentioned utilizing more than one texture unit Apple pack pixel again is the extension for the best way to pass pixel data two of them Jill and allows you to get the the most data the best bandwidth utilization of pixal data to the OpenGL system and the other thing it does actually is it saves system memory so if you're able to store a texture in a more optimal format for your your application let's say one five five five obviously that's going to be half the memory utilization of an eight component eight bits per component texture so that will give you some system memory savings some bandwidth savings and it'll also save video memory on the graphics card so quick summary so again going over some of the priorities so the thing we always tell people as they again need to optimize their application because 75% of the time is typically spent in the application as and 25% in the OpenGL so optimizing your application is going to be important and you won't get good performance until you've gotten back to us an acceptable level scale your application to the target platform try to determine your vram how much video memory is available determine how much system memory is available try to stay within acceptable bounds that won't cause the system memory to go into paging determine maybe the number of texture units on the graphics card so you can do multi texturing instead of multi pass look at your CPU type try to try to utilize a number of OpenGL extensions that will help simplify how the data is being passed OpenGL as well as potentially give you better effects allow the user to adjust the graphics settings such that if the user is experiencing problems on a particular platform from one reason or another allowing the user to vary the quality settings such that they can get the performance that they're looking for obviously is it's gonna be a friendly thing to do for the user it will give the user control over some of the aspects of how the application runs so for more information there's two good books on OpenGL and anybody that's doing OpenGL programming should have these books one is the the OpenGL programming guide and the other one is the reference manual so these books are invaluable they're very well written and if you're just starting to OpenGL or whether you're an expert these books are always sitting right next to me on my desk so for online help there's some good resources you'll want to go to WWF injeel' org this is the official opengl web page and it's got all kinds of neat news announcements resources it has lists of applications that are utilizing opengl documentation it's got all the all the resources you'll need for finding out what's the latest in OpenGL and then there's the lists at Apple comm where you can join the Apple Open GL list and there's lots of Macintosh specific discussions going on in that list where you can participate or learn from some of the discussions that are going on there or send an email of your own and ask a particularly difficult problem that you need answered and lastly we met Sergio at the beginning here so if you have any questions about OpenGL at Apple you can contact Sergio and here's his contact information Sergio is our our product representative Apple and he can direct you to somebody in Apple if he's not the right person or help you with some of your product needs and lastly we have after this session we have advanced OpenGL rendering techniques it's a very interesting presentation that will go into utilizing some OpenGL extensions for doing advanced rendering I highly suggest it for people that are looking for new techniques and some capabilities of graphics cards today it'll show you some interesting demos and some nice effects you