• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-12540
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Runitai Linden
Reporter: Luricos Alderton
Votes: 10
Watchers: 9
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

RenderDeferred / obsolete OpenGL libs in RC / FPS drops down to 2fps

Created: 22/Mar/09 11:10 AM   Updated: 17/Sep/09 10:58 AM
Component/s: Graphics, Source Code
Affects Version/s: 1.22
Fix Version/s: None

File Attachments: 1. Text File fixables-sl_1.22.11-r113976.txt (6 kB)
2. Zip Archive OpenGL_headers.zip (72 kB)
3. Text File SecondLife-after_patch.log (56 kB)
4. Text File SecondLife-before_patch.log (41 kB)
5. Zip Archive sl_1.22.11-r113967_usedFiles-boost-libs-p1.zip (8.54 MB)
6. Zip Archive sl_1.22.11-r113967_usedFiles-boost-libs-p2.zip (2.11 MB)
7. File slviewer-0-v122110-OpenGLFixed.patch.bz2 (19 kB)
8. Text File VWR-12540_render-patch.patch (7 kB)
9. Zip Archive sl_1.22.11-r113967_usedFiles-with-boost-libs_placeholders.zip (959 kB)

Image Attachments:

1. Snapshot_Help-Island.png
(694 kB)
Environment:
Compiled Version: sl_1.22.11-r113976 RC

OS: Windows Vista 64-bit
Processor: AMD X2 6400+
Video: ATI HD 3870 SCS-3 512 MB RAM
System RAM: 4 GB DDR2

Compiler: Visual Studio 2008 Express (VC++2008Express)
Issue Links:
Parent/Child
 
Relates
 

Last Triaged: 17/Sep/09 09:33 AM
Linden Lab Issue ID: DEV-29507
Patch attached: Patch attached

Sub-Tasks  All   Open   
 Sub-Task Progress: 

 Description  « Hide
Hi,

i had many performance issues while using the current RC of SL Viewer like fps drops to 2fps while moving or changing my position. Everythime a new Object was build (thats normal when you move arround xD) my fps drops to 2fps like a dia show. Not useable.

First i started with debugging my log files. Intresting Lines where found as listed:

2009-03-16T23:59:40Z INFO: LLViewerJointMesh::updateVectorize: Vectorization : DISABLED
2009-03-16T23:59:40Z INFO: LLViewerJointMesh::updateVectorize: Vector Processor : COMPILER DEFAULT
2009-03-16T23:59:40Z INFO: LLViewerJointMesh::updateVectorize: Vectorized Skinning : DISABLED
2009-03-16T23:59:40Z WARNING: LLFeatureList::isFeatureAvailable: Feature RenderCubeMap not on feature list!
2009-03-16T23:59:40Z INFO: LLAppViewerWin32::initHardwareTest: Detected VRAM: 0

2009-03-16T23:59:40Z WARNING: LLGLManager::initWGL: No ARB WGL render texture extensions

2009-03-16T23:59:40Z INFO: LLGLManager::initExtensions: Couldn't initialize GL_ARB_point_parameters
2009-03-16T23:59:40Z INFO: LLGLManager::initExtensions: Disabling mip-map generation for ATI GPUs (performance opt)

2009-03-16T23:59:40Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 65 MB
2009-03-16T23:59:40Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 49 MB

I couldn't imagine why my VRAM / Total Video Memory was not detected correctly or why my card dont have GL_ARB_point_parameters. I have a brand new card that has OGL 2.0 inside. All those features used by SL Viewer should match OGL 1.2/1.4 Specs.

Well i testet those Extensions with a program called "GPU Caps Viewer". Everything was fine. So i reckon that the detection routine is faulty.

After building up an Compiler Environment (http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds) and following instructions how to build the RC with Visual C++ 2008 Express which is needed cause 2005 is not compatible with Vista, and fixing those boost problems (http://wiki.secondlife.com/wiki/User:Jodiah_Jensen#STEP_1_-_Downloading_the_boost_source_code) i started compiling the source and later .... debugging.

After i've updated glext.h, glxext.h, wglext.h downloaded from (http://www.opengl.org/registry/) and replacing glh_genext.h with an generated one produced by "extgen" parser (listed inside attached text file) to ensure detection of gl extensions and updated ogl code and changing some lines inside the code described in atteched file "fixables-sl_1.22.11-r113976.txt" and applied my patches my fps raised up to ~14 ~18 fps measured at Help Island.

Now i can move a bit better than before but viewport changing that trigger loading of new objects and textures is still a bit laggy so i started debugging again focusing if i can enable RenderDeferred in 1.22 RC.

Sadly i ended up with "cant fix it" cause this is beyond my area of expertise. But i've found out that the territory textures will be shown if "Basic Shaders" is disabled regardless wich detail level is chosen. It is not possible to change the detail level in-game cause if i switch from low to medium basic shaders will be activated and textures will hide as seen in attached file named "screenshot" while RenderDeferred set to TRUE.

As i figured out it still exists a jira entry about the RenderDeferred issue in 1.22 so i guess deferred rendering is not fully implemented in 1.22 RC. But i think it will be in 1.23 as an jira entry allocates (VWR-12314)

Note: Textures were only rendered after restart with RenderDeffered enabled so i tried to find out whats the difference between startup rendering and changing options inside the the viewer after startup but i ended an "main loop" process that tests if the main window has a focus or is minimized ..... so i stopped right now with debugging. Maybe this feature is fully functional in 1.23?

Would be nice to see that the 1.23 branch has then updated oGL libs and another glh_genext.h file to support WGL_ARB and other extensions With the generated one and updated ogl libs i dont had those warnings during startup =.=

Please take a look at the glgui project inside the attached text file. Maybe this will be usefull for you in further releases?

Last-mentioned i've changed the detection routine of SSE / SSE2 .. i dunno if SSE / SSE 2 is then activated ingame. Furthermore some dev note inside the code noticed "i have to use the sse and sse2 optimized libs". Another Part that is beyond my area of expertise. I didn't crawl through the entire code (for me it feels like i did xD) just focused it to some GL detection stuff.

Summary:

Regards,

Luricos



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Luricos Alderton added a comment - 22/Mar/09 11:31 AM
combine those "sl_1.22.11-r113967" zip files into one folder to form the patch directory. File size was too big for uploading one file =.=

lindenrobot added a comment - 24/Mar/09 09:33 AM
Automated note to patch contributor: if you haven't done so already, please make sure you have a contribution agreement on file and that your patch includes an edit to doc/contributions.txt properly crediting yourself for this patch. See https://wiki.secondlife.com/wiki/Submitting_code for more details.

Boy Lane added a comment - 25/Mar/09 02:00 AM
I've just uploaded a test build (otherwise identical with Cool Viewer 1.22.11.0 R3) that incorporates the fixes here. Please give it a try, perhaps it works for you. I can not test it myself as I returned my 4870 for a GTX260 due to the problems with SL.

http://my.opera.com/boylane


Luricos Alderton added a comment - 26/Mar/09 11:01 AM
Added new Patch file. Only removed the if (FALSE == 0) quick and dirty thingy in llappviewerwin32.cpp @line 403

Luricos Alderton added a comment - 26/Mar/09 11:07 AM
@Boy Lane: Thanks for your contribution! It's really nice to see that you integrated this patch into your viewer =) Nice work xD

Luricos Alderton added a comment - 26/Mar/09 11:20 AM
@lindenrobot: will send the contribution agreement tomorrow.

Boy Lane added a comment - 27/Mar/09 08:00 AM
@Luricos and Linden's

A lot of people helped testing and there were quite mixed results. In general the OpenGL patch seems to work for ATI users, however different settings resulted in other and separate issues that do not occur with Nvidia cards and drivers. Please have a look at the following blog posting and comments, perhaps it helps to gather further helpful information: http://my.opera.com/boylane/blog/cool-viewer-1-22-11-0-r3a-test-build-with-opengl-fixes-ati-users-please-try

Boy


Boy Lane added a comment - 29/Mar/09 12:33 AM - edited
Updated *nix compatible patch (slviewer-0-v122110-OpenGLFixed.patch.bz2) including llwindow/GL/glh_genext.h changes and standalone OpenGL headers (OpenGL_headers.zip). That's all needed to compile it under VS2005.

Luricos Alderton added a comment - 29/Mar/09 05:41 PM
Thanks Boy Lane for adding another patch =)

May I ask you in short whats different from my patch file except that it seems so, that your file includes a diff from the header files?

Did you change something inside the glh_genext.h or the standalone headers? Why am askin is .. those header files are allready included in file "sl_1.22.11-r113967_usedFiles-with-boost-libs_placeholders.zip" which is the 9th attachment. Its an recommended download before applying my VWR Patch. Maybe i didn't figured that thing out more in detail

Everyone who wants to use the patch needs to download both sl_1.22.11-r113967 zip files. and join them into one directory. The Second File which contains the boost libs for VS2008 compiling is only needed if you plan to compile the sources with VS2008. If not you only need the zip contained placeholders. Those have the boost libs as Zero bytes in it cause i couldn't upload more than 10MB once (Upload Limit).

Step 1) Extract both (or one)
Step 2) Copy the previously extracted linden folder to your source directory and override existing files.
Step 3) Apply the patch with "patch -p0 < patchfile" in source root which means "you can see the linden folder inside your current working directory"

(These ZIP files have the correct source structure)

It doesn't matter if those placeholder boost libs are in place ... those will not even eat up much space cause these are "Zero-Byte-Files"

Hope that helps

Luricos

PS: if nothing changed those files can be removed cause these are then not needed.


Boy Lane added a comment - 29/Mar/09 07:54 PM
@Luricos

The one I inculded here is a cleaned up patch that can be directly applied to *nix or Windows sources. It patches the full source including the glh_genext.h that is part ot the official source distribution. The patch you posted was incomplete in this regard and is working for WIndows only (DOS style format).

The other gl headers and boost libs are part of the library package / automatic lib download. Thats worth to note as one has to provide identical sources with a published binary but not 3rd party libraries. This is what the new patch is doing.


Boy Lane added a comment - 06/Apr/09 03:05 AM
Finally did some dynamic testing after people reported all from no effect up to a 100% higher FPS.

Tested was moving around a scenery on an object traveling on a pre-defined path and measuring dynamic graphics performance. Used here a 60s train ride in Koh Kut sim (which is very nice BTW for railroad fans). During the ride samples were taken using Fraps as benchmarking tool (http://www.fraps.com). Compared were 3 Cool Viewer builds, a standard one, an OpenGL patched one compiled using SSE and an OpenGL fixed one compiled with SSE2.

Hardware used (same for each test set):
AMD Athlon X2 4800+, 2GB RAM, ATi HD4830 512MB, WinXP SP3 (thanks Trashe Vyper)
AMD Phenom II 720BE, 8GB RAM, Nvidia GTX260 216 896MB, WinXP SP3

And the results are more than encouraging. An average increase of overall performance of about 25% whereas the effect for ATi users is much more visible as their cards underperform compared to Nvidia. However about the same improvement could be measured with the Nvidia card. Reported results in crowded places are even higher but that's impossible to reproduce with always changing traffic.

Here are the details:
R3: Standard Cool Viewer; R3c OpenGL fix, SSE2; R3e OpenGL fix, SSE)
ATi (HD4830, 1400x900)
R3) 1785 Frames, 19 min, 44 max, 29.750 Avg
R3c) 2178 Frames, 25 min, 46 max, 36.300 Avg
R3e) 2224 Frames, 21 min, 54 max, 37.067 Avg

Nvidia (GTX260, 1680x1050):
3) 3924 Frames, 42 min, 86 max, 65.400 Avg
3c) 4617 Frames, 64 min, 91 max, 76.950 Avg
3e) 4463 Frames, 63 min, 89 max, 74.383 Avg

I'm going to use that fix in all coming Cool Viewer releases. Hopefully someone from LL gets assigned to this ticket here too .


Luricos Alderton added a comment - 06/Apr/09 01:40 PM
Hi Lane =)

thanks for your comments and your and your testers work. Nice to see that this patch is working on other machines =) Thank you for all the fish ^^

@Linden: You got mail xD


Boy Lane added a comment - 07/Apr/09 11:44 PM - edited
I checked this with a Linux viewer and discussed it with Henri. There are no such problems under Linux. However the error "Couldn't initialize GL_ARB_point_parameters" also appears in MacOS.

Other drawback of this patch, in it's current form the patched source tree doesn't compile under Linux or Mac. Haven't checked in detail but it seems that's caused by the new glh_genext.h. So there needs to be some OS differentiation added.


Runitai Linden added a comment - 08/Apr/09 12:13 AM
From the patch, it looks like any and all changes that would affect performance are limited to the handling of "mIsATI". Updating glext.h et al won't help performance, because the constants we reference don't change from one version to the next, and loading of extensions is just late linking, so no matter how you slice it, they're just function pointers. The only time we update glext.h is when we want to take advantage of a new extension.

AFAIK, sVectorizePerfTest only matters if hardware skinning is disabled, which should only be true for Intel GMA chips barring some driver bug or bizarre user preference for slow animation updates.

The existing handling of "mIsATI" is there due to old ATI driver bugs, so it's probably no longer relevant. I'm sure you'd see a speedup from enabling hardware mipmap generation with almost any graphics card.


Boy Lane added a comment - 08/Apr/09 02:42 AM
@Runitai

From what I have seen this patch enables the ARB WGL render texture extension that fails to be detected in the official viewer. This most likely is the reason for the experienced performance gain in Windows.

In Linux builds the detection seems to work, so there is no benefit from this patch and it also may explain that a Linux viewer runs faster than it's Windows counterpart.

I can not comment on the ATI issue as I don't have an ATI card, but as ATI is plagued by performance problems of still unclear origin (I know that ATI confirmed some bug with compressed/uncompressed textures) the effect of this patch for ATI / Windows users is more visible than for Nvidia users. But what we have measured confirms that there is a substantial improvement in FPS for all graphic adapters...well, haven't checked for Intel .

Seems we need to drill down to the root as several issues here are addressed the same time.


Runitai Linden added a comment - 08/Apr/09 09:24 AM
@Boy

I sincerely doubt proper detection of WGL_ARB_render_texture matters since we don't use the extension anywhere. The NVIDIA results posted so far show no improvement beyond the usual noise in our framerate. You might be suffering from confirmation bias.

A clarification - R3: Standard Cool Viewer; R3c OpenGL fix, SSE2; R3e OpenGL fix, SSE)

In that line, does SSE2/SSE refer to the code change around "VectorizeEnable" or does it refer to a compiler setting?


Boy Lane added a comment - 08/Apr/09 09:44 AM
@Runitai

The SSE/SSE2 refers to the compiler settings only. R3 is compiled with SSE too.

I'm a bit puzzled. I can really measure a difference, that is by applying the whole patch set here. But I'm not sure what part does that exactly. Under noise I would consider something in the range of 5% but > 25% is certainly not noise . And that's not only what I can feedback to you as many others reported the same results.

The WGL_ARB_render_deferred extension detection is the only one that differs between Windows and Linux. When I have time I will try it with a standard source tree to eliminate other factors.


Boy Lane added a comment - 10/Apr/09 08:28 PM
Repeated tests with a new CV R4 and comparison to CV R3 and official SL 1.22 confim the measured speed gain. That is for Nvidia, ATI should see at least the same improvement.

Runitai Linden added a comment - 11/Apr/09 12:49 AM
It makes sense that compiling with SSE optimizations on would show a performance boost. I honestly don't know what compiler options release builds use.

As for "within noise" - Sadly, 10% noise over three sessions is fairly typical when the average is 30fps. Over 60fps, 25% is typical. Now, averaging over many sessions can cut down on the noise, but I've even seen RC's show significant performance improvements for hundreds of sessions, only to break even as an official viewer.

I took another look at the patch and nothing jumps out at me. Can you reproduce the performance gain with SSE disabled? What about without the changes to extension loading?


Boy Lane added a comment - 11/Apr/09 10:51 AM
I was half way through some tests, I've spent a lot of time with it. But after what happend just now in your censoring crazy associate xstreetsl.com forum I kick the ball back in your court.

https://www.xstreetsl.com/modules.php?name=Forums&file=viewtopic&t=101161

A nice way to silence people that offer help and ask for help: "Sorry, but only administrators can reply to posts in this forum."

Not your fault Runitai, but I'm not going invest any more time in this.


Runitai Linden added a comment - 11/Apr/09 01:18 PM
Politics around your custom viewer are beyond the scope of this jira. Let's just focus on the task at hand:

Known:

  • Reported FPS Gains
  • Extension loading rewritten in a non-crossplatform friendly way
  • Handling of SSE changed (both run-time detection and compiler settings)
  • Handling of hardware mipmap generation changed for ATI
  • VRAM detection changed

If it was anyone else on my team, I'd ask them to do the same thing: try to narrow down which of those changes actually resulted in the FPS gain, and verify that there actually is a gain. I'll be integrating the mipmap generation change for sure, and I'll refer the SSE and VRAM detection to other devs here.

Thanks for your time.


Ciaran Laval added a comment - 11/Apr/09 02:03 PM
"Politics around your custom viewer are beyond the scope of this jira. Let's just focus on the task at hand: "

That really wasn't helpful, you've got someone offering help to improve your viewer, keep them onboard. Please do not turn away people who can enhance our experience.


Boy Lane added a comment - 11/Apr/09 10:47 PM - edited
To finish this off with the tests I promised. I've taken a standard source tree out of the SVN, without any modifications, and once compiled it as it is and once with the OpenGL patch. That is without SSE or any other optimizations.

There seem to be an improvement but I can not say it is conclusive. Too much variation I would blame the scenery for with moving objects that make it difficult to really reproduce exact the same conditions. I however have done a number of samples, taken out the highest and lowest and some average results I think are:

Without patch
Frames, Time (ms), Min, Max, Avg
4044, 60000, 45, 93, 67.400
4126, 60000, 48, 89, 68.767
4210, 60000, 48, 87, 70.167

With patch
Frames, Time (ms), Min, Max, Avg
4777, 60000, 44, 102, 79.617
4887, 60000, 52, 108, 81.450
4901, 60000, 45, 106, 81.683

But as written, it's inconclusive. To do better testing an empty sim with a defined scenario and an object moving on a fixed path through that scenario would be a much better environment.

SSE and other compiler optimizations certainly help a great deal to get better performance and looking at the default compiler settings I assume the official viewer releases do not come very optimized (release flags in 00-Common.cmake: /O2 /Zi /MT).

What would really be interesting to see is the effect of the patched plain vanilla viewer on ATI cards/drivers but I don't have ATI graphics.


PattehPh0x Katsu added a comment - 02/May/09 01:12 PM
This patch causes the viewer to be unusable by X1950 series cards due to driver incompatibilities.

I experienced this issue on XP Pro SP3, Vista Ultimate SP1 and Windows 7 build 7300.

CoolSL viewer crashes as soon as the world initializes.

I tested this both on my viewer which is based on 1.22.11, I also checked out a fresh copy of the 1.22.11 source and the issue continued to exist, again, on all three versions of windows.


Boy Lane added a comment - 03/May/09 12:40 AM
I've just tested the whole thing again with an older Radeon 8500 and it runs just fine. This was with Catalyst 6.11 which are the last drivers AFAIK that support that card. Also it runs perfectly fine with NVidia cards.

The cause of your crashes are newer ATI drivers. Everything from Catalyst 7.12 to the latest 9.4 are affected. And Xxxxx Ati cards seem to be the worst of. But they are also prone to frequent crashes with a normal viewer.

Please have a look at http://jira.secondlife.com/browse/VWR-12080

Workarounds that reportedly worked:

  • don't use 9.4 drivers (3rd party DNA drivers 8.12 seems to be better and backport to OpenGL from 7.11)
  • disable Catalyst A.I. in your windows graphics controls
  • disable VBO in SL graphic preferences

Darv Linden added a comment - 09/Jul/09 11:49 AM
It's really hard to decide on something here because this reads like a package of changes, and we need to evaluate each change on its own. For example, there seems to be a possible win just from upgrading OpenGL headers (if I'm reading Boy's post correctly?), another one from using SSE, another for memory detection, and so on. These really should get consideration, discussion, and separate patches of their own. I'm going to make a few subtasks of this issue with what I could figure out of what's been said so far. I may have missed something still, so add more where needed.

As important, 1.23 has come out in the meantime - is there any of this that has been done or superseded already?


Darv Linden added a comment - 09/Jul/09 12:22 PM
I'm leaving out the mipmap bits as a subtask because it sounds like Runitai got those already; if they aren't in 1.23 though, please add it.

Darv Linden added a comment - 16/Jul/09 10:58 AM
Looks like the original contributors aren't very active on this; if anyone wants to try to investigate and reboot a subtask(s), it might be low-hanging fruit.

Luricos Alderton added a comment - 16/Jul/09 03:07 PM - edited
Hi Darv,

sry that I left this Post alone for a long time. Actually im very busy right now so i'll look at the subtasks on Monday. I thought everything is clear as we offered a patch and described the progress in detail Cu then

best regards, Luricos

EDIT: so ive done answering your subtask questions ... so its Linden's turn to implement and TEST this Stuff to see what we have done instead of asking questions why this will improve the main Viewer ^^