Jump to content

Henri Beauchamp

  • Posts

  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. Can infirm: the Cool VL Viewer will keep both renderers (WL and EE, and switchable on the fly with the same viewer binary, i.e. no need for two different viewer versions) ”forever”, or at least until LL changes for a Vulkan renderer.
  2. Installing a dual boot (Linux/Windows) is also quite easy to do...
  3. The GTX 1650 will be fine (anything equal or above a GTX 960 will do, even with full shadows). Just avoid AMD graphics cards: the OpenGL drivers for them suck rocks and will ruin your FPS; Linux Open Source OpenGL AMD drivers are much better than Windows', but at equivalent hardware, NVIDIA (with their proprietary driver) invariably beats AMD hands down in OpenGL graphics. With a good enough graphics card, the bottleneck in SL clients (viewers) is the CPU, because the renderer is mono-threaded: you need a CPU that got the best possible mono-core performance (for your budget). A Coffee Lake (or better) or Zen3 CPU will give you the best results. Also do not neglect RAM: 16GB would be today's standard for a comfortable SLing experience, and 8GB would be a strict minimum. EDIT: oh, and in case you are not allergic to Linux, do use it for SL: you'll get quite a significant FPS bonus with it compared to Windows...
  4. Sorry, double post (apparently, the SL forums are just as unreliable as groups: had to reload and it double-posted as a result) :-P
  5. Instead of baring everyone but moderators to receive the list of the group IMs participant, what about updating that list as a slow trickle (group server load permitting), serving first people who do post in the group session (so that at least they receive the full list every few minutes or so) ? Also, I believe that at least the moderators list should be transmitted to everyone (it is important to know who are the online moderators if you get grieved, for example). Finally, the Cool VL Viewer has, for years, been adding automatically posting group members to the ”speakers” panel list when they are missing: such a feature could be added to other viewers as well, so that at least all people who posted in the group are (locally) listed for everyone.
  6. This should put an end to fake news about viewers performances, and demonstrate the potential of the multi-threaded image decoder: ViewersTest.mkv Testing protocol: Since the choice in available (release) Linux viewers is slim, I tested Firestorm and Kokua (the very latest EE releases) against the Cool VL Viewer. All viewers running on the same PC under Linux v5.11.8 (vanilla, self-compiled kernel, with all mitigations off): CPU: 9700K @ 5.0GHz locked on all cores (i.e. only C0 & C1 states are allowed). No thermal throttling (well cooled CPU). GPU: GTX1070Ti @ 1980MHz for the GPU & 9200MT/s (=4600MHz) for the VRAM. NVIDIA current proprietary drivers (v460.56) Exact same graphics settings, so that all viewers use the same, common settings: e.g. no Classic Clouds enabled, 1.00 Mesh LOD multiplier in Cool VL Viewer since they don't exist in others; Objects LOD limited to 3.0 and Terrain LOD to 2.0 in all viewers (FS can do more), etc... EE rendering mode for everyone (Cool VL Viewer can do both EE and WL). Midday default setting. All the viewers' caches and log files are held on a RAM-disk. No other software running than the viewer and the screen capture, which does disadvantage the Cool VL Viewer since the capture software loads one or two of the cores (appear in dark green in MATE's load monitor) that would otherwise be used by an image decoder thread or two. Of course the ”background yield time” setting was set to 0 for all viewers. A scene with ”relatively heavy” outdoor setting was chosen, pretty much at random, just after looking at the map for one such sim without any avatar around (in draw distance), with a bit of everything: sky, water body, land, trees with alpha textures, buildings, meshes, etc. Only one avatar on screen (alas imposed for 100% reproducibility reasons) wearing a BoM body, mesh hair, prim attachments, flexy cape (i.e. a bit of everything). The viewers cache are primed with a first dry run (not shown), so that all textures get cached in the RAM disk for the perf measurement run. ”Texture time” HUD info and texture console shown. The scene is considered fully rezzed when less than half a dozen of fetches are active (some moving mobiles in DD may cause new fetches after the initial rezzing, and since they are random we won't count them). The rezzing time is taken with ALM off, so that less time is used by the render pipeline and the viewers rez faster (the texture fetcher getting more CPU time in the main thread for itself), especially FS and Kokua which do not have a multi-threaded image decoder; those also have KDU, which is much faster than the Cool VL Viewer OpenJPEG... At the end of each rezzing, I switched the ALM mode and full shadows on (SSAO and DOF off), so that you can appreciate the FPS rate differences as well (and so that I won't hear again some total non-sense about my viewer performances)... The Cool VL Viewer especially shines with ALM off, since I optimized most of the C++ code, but not the shaders (they are almost exactly the same for all these viewers), and very little the render pipeline (llpipeline.cpp) itself (so the CPU-hungry shadows code makes the speed gain less obvious, i.e. not 80% gain and over, but closer to 50%). Also remark the memory consumption...
  7. Nothing amiss in the pipeline: just your CPU slowing down when it should not, which causes the ”drop” in the GPU load, since it's not fed as much work. It *is* accurate (at least as much as /proc/cpuinfo is) in the case of the Cool VL Viewer: my code detects which core it is running on (this is even reported in the log file) at the very moment it gets the frequency for that core. At this point, the said core should already be in turbo mode !!! It certainly is on all systems (5 different PCs) I tested it on ! Since, again, you seem to be the one and only person who tested my viewer and found it ”slower”, I will not even bother and loose my time replying to the rest (neither to any other posts of yours): I simply urge everyone reading you, to never take your words for granted, and make their own tests instead !
  8. @KjartanEno Again ?... For a start, you are diverting this thread from its original topic which is not about the GPU load, but about multi-threading. The improvement brought to the latest Cool VL Viewer version won't change a thing to how high is the GPU load (or to the frame rates) in static scenes, but how fast textures are rezzing on login, after a far TP, or while moving around (the latter even more obviously when the new ”Boost textures fetches with speed” feature is enabled, in Advanced -> Rendering -> Textures). Second, look at the About boxes, and see how the CPU frequency jumps up and down for the same viewer or between viewers. Obviously, there is something amiss with your system(s) since as soon as any viewer is logged in and rendering any scene, the CPU freq should go to turbo for the core running the main thread and not budge from it ! Simply LOCK your CPU to its maximum frequency on all its cores to achieve the maximum performances. One thing is certain: on my various systems, the GPU load is constant (but so is my CPU frequency) and yet well below 100% (more like around 40-70% for a GTX1070Ti, depending on the scene being rendered), even with ALM+shadows+everything on: with anything equal or better to a GTX960, the SL viewers are 100% CPU-limited; it also means that if the frequency of the CPU core running the render pipeline (i.e. the main viewer thread) goes up and down, the GPU load will follow it.
  9. It was in 2011 and 2012, in IMs, in SL... I keep all the logs, since I won't accept anyone to doubt of my word, anytime, and I can always prove by A+B what I am asserting. Total (and yes, sometimes quite blunt/unforgiving/harsh) honesty and reliability are among my intangible principles. I say what I do, I do what I say, always. Period. I am an old fart (and not proud of it: just a fact of life, sadly), with 40+ years of programming experience behind me. It means that I am/keep using tools that I have been using for decades ('Nedit', 'grep', 'patch', 'diff', 'find', 'cut', 'sed', bash scripts, Perl scripts, Tcl/Tk scripts...)... I know, it looks ancient (antediluvian ?), but they empower me with a productivity that many (most ?), ”modern” (”young” ?) programmers would envy. I am sorry, but at my age, I won't ”adapt” (read: loose productivity and efficiency) to tools such as cvs, svn, hg, git (or whatever other fancy ”repository” software you can cite): I find it incredibly faster to read (yes, even with my old eyes) a ”raw” patch file (and recode it in my own way, with bug fixes and optimizations) than browsing those (or, horror: merging them and fixing merge errors), and the rhythm at which I can publish new releases (weekly, with only very sparse, part time usage of my free time), compared to the time needed by entire teams of developers to publish a release of their own viewer, should incite you to start and wonder if you are using the most efficient tools... 😜 In other words: yes, you can freely reuse my code, but no, I won't provide you with a patch (or commit) that applies cleanly to your own code... Shocking, I know ! 🤣 PS: oh, and please everyone, get it right ! The name of my viewer is ”Cool VL Viewer” (yes, ”Viewer” is part of the name !), not ”Cool VL”... Like in ”Eiffel Tower”, you know... or ”Freedom Tower”.
  10. Nope ! No other viewer got it (so far); they have mono-threaded image decoding (i.e. the decoder runs in one thread, along the main program loop), but not a multi-threaded one like it is now the case for the Cool VL Viewer. Did I ever refuse the re-licensing of my code ?... Like I wrote recently in an email to one of FS' developers: And you perfectly know this yourself (or do you want me to exhume the IM conversation logs we had in the past ?)... As always, the condition for reusing Open Source code from another developer is giving credits to them. As for Kathrine's multi-threaded LLImageDecodeThread code, you will have to ask her about the permission to reuse her code in your viewer.
  11. There is no ”variable” when you can render the same avatars for all benchmarks. As for clubs and venues, I never seen my viewer dropping to single digit frame rates, even for venues with 40+ avatars and ”impostoring” turned off ! Mind you, the avatar rendering is especially carefully optimized in my viewer (e.g. with joints caches indexed by integer keys instead of recursive searches down the joint hierarchy by string keys, cached attachments, cached rigged skinning matrix, etc) ! Amusing, for someone who wrote in a PM to me on my forum (dated 2020-10-06 17:46:30): But you missed entirely the point: since you cannot zoom in the exact same way between different benchmarking sessions, you are destroying the reproducibility of the benchmarking (one viewer could get advantaged during one session, and another viewer for the next try, depending on how many objects entered the objects list during the zooming). Beside, keeping more objects in object cache may be detrimental to the ”fixed view” benchmarking, but will favour the frame rate while moving and turning around. And yes, I use a different algorithm (and different parameters) for LLVOCache than other viewers. No, it's not a church (and I'm an atheist, so...). But obviously, you are NOT a programmer. I do put art in my coding, and take pride from it, because yes, it is chiseled sculpture, with handcrafted optimizations (I'm not just ”pissing code” and hoping the optimizing compiler will turn the resulting crap into a fast running binary). If you want to see the results of this optimization work (that I pursed during the past 13 years for the Cool VL Viewer), you may try and measure the ”main loop” overhead (which determines how much time it takes for the C++ code to execute at each frame, rendering (mostly) taken apart): rez a platform at 3000+ meters (where no object/avatar will be around, reduce DD to 128m if necessary). Stand with your avatar on that platform and remove everything it is wearing (i.e. keep only shape, skin, eyes and legacy hair). Log off, then for each viewer, turn off ALM (to remove most of the GPU/shaders overhead) before logging back in, wait one minute or so for the frame rate to stabilize and compare. I get: Cool VL Viewer v1.28.2.4 WL rendering mode: around 1320 fps. Cool VL Viewer v1.28.2.4 EE rendering mode: around 1100 fps (yep, EE overhead is far from negligible, and I need to work more on that !). Firestorm v6.3.9 (WL): around 700fps Firestorm v6.4.12 (EE): around 720fps Singularity v1.8.9 (WL): around 1080fps (taken from the log to avoid opening the stats floater which would slow things down). I can't sadly give you a figure for other viewers (which do not have a Linux version), but last time I tried with LL's viewer (when they still had a Linux release) it was by far the slowest with below 600fps.... This gives you a little idea of how much C++ optimizations I did put in my viewer (and make no mistake, other viewers, LL's taken apart, are also carefully optimized by competent programmers). So, when you tell me it is slower than all others while, Singularity and Black Dragon excepted, all viewers use the same set of shaders (with only very minor cosmetic/rendering differences that won't affect the FPS rate), it is simply an impossibility ! And all my tests always showed it. End of the topic, as far as I am concerned !
  12. And you are being dishonest and obviously trying to badmouth my viewer reputation... You did not even address the valid criticisms I pointed out (zooming around before benchmark instead of benchmarking at login position, no avatar rendered). I urge everyone reading this forum to use their own benchmarks instead of relying on your flawed numbers !
  13. You know, this is getting tiring... I made my way to the sim you took the screenshot from and guess what ? At the position on your screen shot (228,182,25), I cannot see this scene: I must zoom around with the camera to see it, meaning I collect a variable amount of objects in cache doing so (it's called the ”interest list”), which ruins any reproducible benchmarking ! Also, I told you already: you just cannot benchmark viewers using a different renderer. If you want to compare my viewer (which can do both WL and EE) with others, at least use the same renderer ! As it is, this scene (which contains a lot of alpha textures) renders faster in EE than in WL (EE can batch those textures, which WL cannot do). And where is your avatar ?... Are you using SL without any avatar rendered ?... Mind you, avatar rendering is costly (especially CPU side) and is an important element to benchmark as well. So, here are my results with my viewer and Firestorm (I do not have a Linux version of Alchemy, but if someone passes me one, I'll test it too), configured in the exact same way: same graphics, with EE on in my viewer, ALM+SSAO, all water reflections, no shadow, same LODs in both viewers (3 for objects, 2 for terrain, max for all others, mesh LOD multiplier set to 1 in my viewer since Firestorm does not have this), low altitude clouds (AKA classic clouds) OFF in my viewer (Firestorm does not have them and they eat quite a few FPS). The major differences with your settings are: draw distance = 256m and a 1920x1200 screen (viewer window maximized in it), one avatar on screen, with a rigged mesh body, attachments (basic prims, scuplties and meshes, plus costly flexiprims). The results, on a 9700K @ 5GHz locked on all cores and a GTX1070Ti locked @ 1974MHz (GPU) / 9216MHz (VRAM) are as follow: Cool VL Viewer v1.28.2.4 = 55-59fps, Firestorm v6.4.12 = 31-34fps. Proofs below (the frame rate is displayed in the bottom right corner for my viewer and upper right corner for Firestorm).
  14. This week's release notes link is wrong, in the data returned by the ”ServerReleaseNotes” capability (meaning viewers cannot display the notes): 2021-01-19T15:58:55Z DEBUG: LLFloaterAbout::handleServerReleaseNotes: HTTP headers: <llsd> <map> <key>cache-control</key> <string>max-age=2592000</string> <key>connection</key> <string>keep-alive</string> <key>content-length</key> <string>243</string> <key>content-type</key> <string>application/xml</string> <key>date</key> <string>Tue, 19 Jan 2021 15:58:55 GMT</string> <key>expires</key> <string>Thu, 18 Feb 2021 15:58:55 GMT</string> <key>location</key> <string>https://releasenotes.secondlife.com/simulator/2021-01-08.554811.html</string> </map> </llsd> While the actual page URL is: https://releasenotes.secondlife.com/simulator/2021.01.08.554811.html (i.e. dashes are to be replaced with dots in the HTML file name transmitted by the capability, or the file name should be changed to use dashes to separate the date fields, as it used to do until now).
  15. If you could stop making your personal (and quite unique) experience a generality ! I do not know what is your hidden agenda (and to me it furiously looks like you have a nasty one !), but you are the only person so far who dares to pretend that my viewer is the slowest (whatever the hardware) ! I tested it on multiple computers (Intel//AMD & NVIDIA/AMD alike), and it always came first or second (Singularity is sometimes faster, but Singularity got some breakages, such as water reflection and displacement maps, as well as missing features). To be valid a benchmarking protocol must be strict; all tested viewers must render the exact same scene(s) with the exact same settings (and there are settings specific to some viewers, that do need to be adjusted to be on par with others), and you need to be able to reproduce the results several times for each viewer (if you can't reproduce the same results in three sessions in a raw, then your protocol is flawed). Also, default settings (as well as some algorithms) may be different in other viewers than mine (e.g. regarding the objects caching, or the data fetching routines, which impact how well the viewer renders and rezzes the world while moving around, i.e. not just in a static scene), but once everything is set equal, my viewer is definitely one of the fastest if not the fastest; I have been optimizing it (and especially the C++ code) for the past 13 years, so it's no surprise, really. Finally, you cannot compare the Windlight and Extended Environment render pipeline and shaders unless you compare them over a range of different scenes (e.g. WL is usually (much) faster, but in scenes where there are a lot of alphas, EE will be faster than WL, thanks to its alpha batching feature).
  16. Logins are currently disabled. See the status blog notice LL posted minutes ago.
  17. The Cool VL Viewer v1.28.2.0 released today now allows to move or delete ”protected” folder types when they are not named as they should (e.g. ”Current Look” is not the proper name for a COF type, which should be named ”Current Outfit”) or are not located at the root of the inventory. This allows fixing this issue (and any other similar issues) while securing the genuine protected folders (i.e. you do not risk deleting or moving them by mistake).
  18. You mean 100% text chat (I won't understand anything on voice and have no time to loose with voice meetings in English) ?...
  19. This does not bode well for the future, then... If LL is unaware of the cause (meaning it would be on AWS' side and they did not communicate about it with LL), it will likely reproduce. 🙄 One of the drawbacks of the whole ”uplift” thing...
  20. Good news ! The SL-AWS slow/failing servers replies seem to have been solved during the night (i.e. yesterday's afternoon, SLT) ! Everything is back to normal for me, with fast logins, snappy rezzing and (non-failing) TPs, reliable inventory operations, baking, etc... I'm still curious about the origin of that issue... So, if a Linden could elaborate about it... Sadly, the JIRA is (and by far) not the best place for TPV developers to be heard (and even less listened to) by LL... Your issue gets lost in an ocean of other issues, with much less relevant/pertinent info given in the latter, and the JIRA triagers won't even know who the said TPV devels are or how valuable are their reports. I have much better luck with comments in the commits to LL's viewer code (as a mean of preventing future SL bugs, by pin-pointing them in pre-release viewer code), with messages posted to the opensource-dev list, or on this forum. My posts in the latter two media are pretty rare occurrences, and usually denote a catastrophic degradation that require urgent attention from LL. As for the viewer bugs, the JIRA is of little to no use as well for me, as a TPV developer: I do not even have (even a read-only) access to most JIRA issues (not even those referenced in LL's viewer commits !), and anyway, when I find a bug or got one reported to me, I fix it myself for my viewer (since it's Open Source, anyone could benefit from my fixes as well, should they care to have a look at the weekly diff and change log I publish for each new release). <rant>There are the TPV devel group meetings, but sadly they are held on voice, meaning non-english speakers like me cannot attend them (well, they can, but won't understand half of what is said)...</rant> <nostalgia>In the distant past (before Oz' era), these meetings were held exclusively in text chat, letting everyone a chance to understand and express themselves (via translators if needed), whatever their nationality</nostalgia>
  21. As I see it (from a long time (13+ years) SL viewer developer), the problem is that the ”Current Look” folders you have in your inventory bear the same type code as the genuine ”Current Outfit” (COF) folder: there is normally only ONE such folder at the root of your inventory, and when dealing with the COF, the viewer (and probably the sever alike) simply scans the root folder of your inventory for the first (and normally only) folder with the COF type code: and uses it for all baking operations. Depending on the order in which the folders appear in your inventory (this is not the sort order but the order in the inventory tree), any of the three folders you got could be found by the viewer and/or the server, and there is not even any guarantee that both the viewer and the server will find the same folder when rebaking, meaning the viewer will update one folder with what you are wearing and the server might look in another for what you are wearing ! It means that, by pure luck , you could happen to have both the server and the viewer updating and using the same COF-type folder for one session, and not for the next ! Add to this, the folder version issue (that I explained in my former post) and in fact you can only see your avatar baking when the genuine COF is found first by both the viewer and the server: good luck with that ! The method I described in my previous post (patching a viewer, compiling it, and using it to get rid of the ”Current Look” folders) should solve your issue. Else, you'll have to wait until LL writes a script, tests it, and runs it on your inventory database...
  22. I have a 1Gbps (downlink)/700Mbps (uplink) FTTH connection to Internet, without any issue on it, and provided by a major ISP in France (Free/Illiad). I have no issue whatsoever connecting to Amazon web services, outside of SL (all Amazon websites load super fast and without a glitch). I also had no issue in SL before USA's Thanks Giving. There are other affected people (see this thread, for example), that I assume do not use the same ISP and are most likely not living in the same region or even the same country. Obviously, LL broke something just before the Holidays and no one cares ever since (they even went as far as shutting down entirely their support service that very week-end !). As for the JIRA, I gave up on it a long time ago: posting an issue on it is like ”pisser dans un violon” like we say in France. I have detailed logs (Wireshark pcap and viewer) available to any Linden who will care contacting me.
  23. And when are you going to fix the issue with super-slow or failing connections (login, seed replies, capabilities fetches, simulator features, AIS3 inventory, bakes) ?... After November the 26th everything got ruined for me in SL because of them: when the AWS servers take 30 seconds or more (!) to perform the cited connections, everything fails in SL !!! And not even a word about this MAJOR issue on the grid status page !
  24. If you got a Linux PC, I'd recommend building the viewer under it, since it's just a matter of typing a single command in a terminal pointed at the viewer sources ! Windows and macOS require installing IDEs (VS2017, XCode11), which is a more complex task than building the viewer itself once they are installed...
  25. If you can compile a viewer yourself, a patched version would allow you to delete the offending folders. You may want to try the Cool VL Viewer which is easy to build and which code already contains an exception for OpenSim grids and the COF (allowing you to delete the latter in OS grids, since it is not mandatory there). The line to change to allow deleting the ”Current Look” folders is in linden/indra/llinventory/llfoldertype.cpp, line 142. Change that line to read: if (folder_type == FT_CURRENT_OUTFIT) (i.e. remove ” && sCanDeleteCOF” from it). Recompile the viewer, log in, delete the two offending folders. BEWARE however: DO NOT, under ANY PRETEXT, delete the ”Current Outfit” folder in SL (and if there are several folders named ”Current Outfit”, do NOT delete any of them, but let LL support deal with them): deleting the COF would cause bake failures, even after recreating it (I know first hand, because I deleted mine by mistake once during a viewer testing session): the reason is that its version (i.e. the number of times it got updated) is somehow kept in SL's servers and as long as its version is lesser than the one used for the last successful bake, you cannot rebake with it. I reported that bug (that I worked around for my account by rebaking for hours via scripted RLV @attach/@dettach actions until the new COF version got greater than the old deleted COF version), years ago, but I doubt LL fixed it...
  • Create New...