Wow. that's pretty awesome. Need something like that for Linux.
I don't understand even a half of that, but particularly interesting are any stalls (it's unlikely that Stellarium would send enough stuff to overwhelm the GPU). Is there any documentation on the web describing the counters? Anyway, from what I can understand: (Please make measurements from previous code as well; can't see what's causing the slowdown without reference) Most likely to be a problem: contextGLSwitchCount finishGLWaitTime GPU Core Utilization (underutilized, i.e. stalling too much?) hardwareSubmitWaitTime hardwareWaitTime commandGLBytesPerSample Less likely to be a problem, but maybe: clientGLWaitTime (although if this measures client waiting for GPU, unlikely) GPU Memory Utilization (unlikely to be a problem, though) textureWaitTime texturePageInWaitTime texturePageOutWaitTime surfaceReadLockIdleWaitTime (screen texture/viewport effect?) swapCompleteGLWaitTime freeContextBufferGLWaitTime freeCommandBufferGLWaitTime Also, are these measured for all GL usage in the system? (there is contextGLCount - seems like it might include all contexts?) If so, it'd be better to measure with compositing turned off. I assume measuring too much at once would mess up the profile? If so, concentrate on the "most likely" ones. Also, 04.50 AM. Need sleep. On 8/31/12, Timothy Reaves <[email protected]> wrote: > My Mac's OpenGL profiler can collect the following statistics (which mean > very little to me). If any of them mean anything, let me know, and I'll > record. > > Yes, the Mac's now use the switchable graphics cards, but it is not under > user control. > > bufferFlipCount > bufferSwapCount > clientGLWaitTime > command2DBytesPerSample > commandBytesPerSample > commandDVDBytesPerSample > commandGLBytesPerSample > context2DCount > context2DSwitchCount > contextClCount > contextCLSwitchCount > contextDVDCount > contextDVDSwitchCount > contextGLCount > contextGLSwitchCount > dataBufferCount > dataBytesPerSample > dvdTextureCount > finish2DWaitTime > finishAll2DWaitTime > finishCLWaitTime > finishDVDWaitTime > finishGLWaitTime > freeCommandBuffer2DWaitTime > freeCommandBufferCLWaitTime > freeCommandBufferDVDWaitTime > freeCommandBufferGLWaitTime > freeContextBuffer2DWaitTime > freeContextBufferCLWaitTime > freeContextBufferDVDWaitTime > freeContextBufferGLWaitTime > freeDataBufferWaitTime > freeSurfaceSwapBufferWaitTime > gartCacheBytes > gartFreeBytes > gartMapInBytesPerSample > gartMapOutBytesPerSample > gartSizeBytes > gartUsedBytes > GPU Core Utilization > GPU Memory Allocation > hardwareSubmitWaitTime > hardwareWaitTime > heapBlockWaitTime > idctDataBufferCount > IOSurfacePageInBytesPerSample > IOSurfacePageOutBytesPerSample > lastReadStamp > removeFromGARTWaitTime > submitStamp > surfaceCopyInWaitTime > surfaceCopyOutWaitTime > surfaceCount > surfacePageInBytesPerSample > surfacePageOutBytesPerSample > surfaceReadLockIdleWaitTime > surfaceSetShapeIdleWaitTime > surfaceWrtieLockIdleWaitTime > swapBytesPerSample > swapComplete2DWaitTime > swapCompleteDVDWaitTime > swapCompleteGLWaitTime > systemUsedBytes > textureCount > texturePageInBytesPerSample > texturePageInWaitTime > texturePageOutBytesPerSample > texturePageOutWaitTime > textureWaitTime > volatileSurfaceCount > vramFeeBytes > vramLargestFreeBytes > vramUsedBytes > GKD_IGGL_BLIT_SIZE_KB_eBlitRing > GKD_IGGL_BLIT_SIZE_KB_eMainRing > GKD_IGGL_RING_SUBMIT_eBlitRing > GKD_IGGL_RING_SUBMIT_eMainRing > GKD_IGGL_RING_SUBMIT_eMediaRing > GKD_IGGL_TIMESTAMP_HAS_WAIT_eBlitRing > GKD_IGGL_TIMESTAMP_HAS_WAIT_eMainRing > linearBytes > linearCount > linearPages > > > > On Aug 30, 2012, at 9:34 PM, Ferdinand Majerech <[email protected]> > wrote: > >> It would be useful to get profiles for varying configs (especially >> Windows/Mac >> with various GPUs, and Linux with NVidia binary drivers) >> >> I expect about 20-40% slowdown in GL2, ~10% up/down in GL1 compared to >> previous code. GL1 is enabled by --safe-mode or if GL2 fails to >> initialize >> (e.g. on drivers without GL2 support). >> >> My profiles on AMD catalyst and open source, Nouveau and Intel (all >> Linux) are consistent >> >> If you make any measurements, please specify CPU/GPU, resolution of >> Stellarium window, drivers, FPS of previous and current code. Also >> what is on the screen >> (e.g. plugins enabled? just opened Stellarium?, etc.) >> >> Especially important are any cases where FPS drops unpredictably low - >> this happened with Pulsars before, but was fixed since. >> >> >> Ferdinand Majerech >> >> On 8/31/12, Timothy Reaves <[email protected]> wrote: >>> This is complete. For those who may have not received the other >>> comments, >>> I'll repeat them here. I'm worried about the performance of this code. >>> On >>> my machine: >>> - SSD (No HDD) >>> - 16 GB memory >>> - NVidia GeForece GT 650M with 1G memory >>> - Quad core 2.6 GHz Intel Core i7 >>> >>> the code is about 20% of the performance of the old code. So from just >>> over >>> 75FPS to around 20FPS. Even in safe-mode, which is still OpenGL 1.0, it >>> is >>> only 30% (about 24FPS). This is hugely degraded FPS performance, and >>> yes, >>> it is very noticeable at an interaction level. >>> >>> Ferdinand has not experienced this dramatic of a performance hit on his >>> development machine. Fabien has seen this code, and approved it. >>> >>> Please have a look, and report your findings. >>> >>> Thanks. >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions >>> will include endpoint security, mobile security and the latest in >>> malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Stellarium-pubdevel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> >> will include endpoint security, mobile security and the latest in malware >> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Stellarium-pubdevel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
