|
|
|
[
Permlink
| « Hide
]
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 =.=
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
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.
Added new Patch file. Only removed the if (FALSE == 0) quick and dirty thingy in llappviewerwin32.cpp @line 403
@Boy Lane: Thanks for your contribution! It's really nice to see that you integrated this patch into your viewer =) Nice work xD
@lindenrobot: will send the contribution agreement tomorrow.
@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 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) (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. @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. 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 Hardware used (same for each test set): 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: Nvidia (GTX260, 1680x1050): I'm going to use that fix in all coming Cool Viewer releases. Hopefully someone from LL gets assigned to this ticket here too 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 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. 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. @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. @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? @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 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. 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? 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. Politics around your custom viewer are beyond the scope of this jira. Let's just focus on the task at hand:
Known:
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. "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. 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 With patch 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. 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. 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:
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? 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.
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.
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 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 ^^ |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||