Jump to content

Henri Beauchamp

Resident
  • Posts

    181
  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. It does smell... I spotted this bug back in the time when I backported the Marketplace code to the Cool VL Viewer. Here is the culprit code and my comment about it. #if 0 // This is a bogus thing to do here (because updateCategory() would // change the modify masks and that change would have all risks to be // ignored, simply triggering the warning above), and should not be // needed any more now that I fixed the observer code for the // marketplace (by moving changes to the inventory structure out of // the observer event code and into an idle callback). HB if (LLMarketplace::contains(referent)) { LLMarketplace::updateCategory(referent, false); } #endif Note that since my backport is actually a partial re-implementation of LL's code, you'll need to do more than just commenting out the corresponding line in LL's viewer sources (see my comment about moving inv structure changes out of the observer code). The corresponding line in LL's viewer code for the recursive notifyObservers() call you observe is: update_marketplace_category(referent, false); Around line 1697 of newview/llinventorymodel.cpp.
  2. Apparently, we do not share the same experience on these topics... I got HDDs that are over 10 years old and still spinning just fine (granted, they were not cheap HDDs either), even if others did die over time (I've had especially bad experience with the IBM ”Deathstar” in the distant past, and with a triplet of Seagate 7200.11 in a RAID5 more recently). I can't speak about my experience with cheap SSDs since I never bought any, but seeing how much data has been written already on my older (MLC) SSDs, the cheap ones would have long hit their max write cycles and exhausted their NAND provision, and faster than even the lame 7200.11s have died for me. As for second hand RAM modules, I bought quite a few over years, to upgrade old computers... From old SDRAM to DDR3 modules. Never got any issue with them. As long as they pass the memtest I always submit them to on arrival, there is no reason for them to suddenly die (and if they don't pass it, just return the module as faulty to the seller)...
  3. I won't use a cheap SSD for caching purposes (and truth to be told and as far as I am concerned, for no purpose at all): they are especially fragile with a low endurance (low max write cycle counts), while a cache disk needs high endurance to writes. They are also slow (you will find QLC or non-V-NAND TLC drives in this ”cheap” category, and their write speed is abyssal). I'd rather use a RAM-disk, and if RAM is scarce on my system (less than 16GB), I'd rather consider adding more RAM (you can find 8GB DDR4 modules around 30-50 bucks, and you can even buy second-hand modules for RAM, while buying second-hand SSDs is quite unwise) so to be able to create a RAM-disk; the added RAM will also benefit all applications more than your cheap SSD would, the SL viewer included.
  4. It has been several consecutive releases (i.e. quite a few weeks) that the server release notes are unavailable, always leading to an ”access denied” XML page. This week, yet again, I get for Second Life Server 2021-10-01.564394: <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>K3YPNABE6YFTXY2H</RequestId> <HostId>hOSazNPaJ6eugcIdrcmr5Z24c/3CypGM2VLq+ds9nhkHtAqL/YK4FUd2wooCYW/QoTQetF81oMo=</HostId> </Error> Could you please, LL, get it right once and for all ? All it takes is to verify the release notes URL does work whenever you update your servers... What about adding this step on the check-list for server updates ?...
  5. I've been called ”Spock”, in my (far, far) high school days, but never Scott... I'm flattered nonetheless, even if I'm not as fat as he is on this picture... 😄
  6. Not just my job... I simply made sure that my viewer (and its dependencies) was (super) easy to build under any Linux system. The arm64 porting itself was done and contributed by bjbdragon. I have been actually very surprised it has been possible at all (also thanks to sse2neon).
  7. Not a surprise... As I explained in my above message, all CEF versions between 77 and 89 are affected by those random crashes. The current CEF releases (90 and newer) got it fixed.
  8. This sounds way too long to me... A few seconds should suffice to backup 4 GB or data to your SSD...And yes, a 2GB cache would be plenty enough to store the data for at least 4 of your preferred/most visited places: increasing the size is hardly bringing any benefit (if you travel a lot in main land, the cached files will get evicted from the cache at some point anyway, whatever its size). I do not know what RAM-disk software (or script) you are using, but it looks like (by the time it takes) it uses compression: just disable the latter and store the data uncompressed, and if possible, as a single file (as a 'tar' file under Linux or an equivalent for other OSes: zip can do it with the ”do not compress” '-0' option, for example). Things such as the inventory list cache takes time to load, even with a fast Internet link, and without a loaded inventory, your avatar will stay a cloud: you might want to at least save and restore the inventory cache files...
  9. Under Linux for an ext4 file system, you use the ”noatime” option (at the minimum; I use personally lazytime,noatime,nobarrier,delalloc,discard) to prevent ”last accessed” time stamp update, when using a SSD. So the cache defeats that mechanism... Not to mention this is not even the ”last access time” data which is updated on reads in the ”simple cache”, but the ”last write time” (because you need to make sure this time stamp is indeed the result of a cache code access, and not of some random read from the file explorer, wsearch daemon or whatnot). Even with the old VFS-based cache (a single large cache file holding a virtual file system), that ”last used” info had to be stored as bytes inside the VFS file... There are several separate caches in use by the viewer: The textures cache. The assets cache (animations are among them, but meshes are by far the largest stored assets in it) or VFS. The objects cache (per-sim files). The inventory list cache. Some other minor cache files (names cache, mute list, decoded sound files, etc). You could eventually separate the textures, assets and objects caches from the rest, but I do not really see any benefit in doing it...
  10. Even for reads, the cached files need to have their last access time updated, so that the cache code knows what files to evict first when it needs to make room for new files (it of course first evicts the files that have not been accessed in the longest time). On HDs, this is not an issue, but on SSDs, where writes are done at a block granularity (i.e. you cannot just write a couple of bytes in the Flash memory: you must erase and rewrite an entire block with the few updated bytes), it can cause an excessive wear. While MLC and multi-layer TLC Flash is usually endurant enough, I won't use any single-layer TLC or multi-layer QLC for a cache (not to mention TLC and QLC writes are slow and/or cause an excessive ”write amplification”, due to the fact that each block is first written in an area used as a pseudo SLC flash, for speed, and rewritten later in the TLC/QLC ”standard” area) ! It is just simpler (and faster, at least under Linux and macOS; Windows is another story, especially just after a reboot, when the OS does not yet have a cached directory tree in RAM). It however does not solve SSD wearing (even though it attempts to mitigate it by not writing the access time at every read if the last read timestamp is recent enough). A proper RAM-disk saves its contents on disk on OS shut down and restores it on reboot... Not at all. Here (under Linux), it takes just a couple of seconds to save a 2GB RAM-disk and even less to restore it: I do not even bother compressing the RAM-disk data (which would take more time): I just 'tar' it to the SSD and voilà.
  11. If you have a sufficient amount of RAM (16GB and preferably more), your best bet is to use a RAM-disk for the viewer cache: it is the fastest, by several orders of magnitude, and will prevent to wear out SSDs and HDs. A 2GB RAM-disk is enough, at least for one viewer (be aware that different viewers normally use different cache directories, so their cache size would add up in your RAM-disk).
  12. The release notes page for the RC server is missing: This XML file does not appear to have any style information associated with it. The document tree is shown below. <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>V3536Y6VV3TTPEP1</RequestId> <HostId>ZMSq1zpADnS9k59CP12ByneuInAk8B/mFGFYbM9IokBFgR/x6H9OVm4l9sMrnFvUcAWmY27uMiQ=</HostId> </Error>
  13. The CPU is indeed only part of the problem, and neglecting the GPU might give you entirely false render cost figures on systems where the GPU is the actual bottleneck (*)... It would be great to get figures with CPU + GPU render time for each avatar. Not sure it is at all feasible however (perhaps by rendering only a given avatar and nothing else for a few frames in order to get its render cost). (*) Typically, systems using iGPUs, since those are especially weak; with a discrete GPU, even as old as a GTX 660, the CPU becomes the bottleneck in SL.
  14. There is no risk to ”fry your computer”. At worst, your CPU or GPU would throttle down their frequency to avoid overshooting their max rated operating temperature (itself a few Celcius degrees below the absolute max temperature). Typically, a CPU that would fry above 105°C will throttle down its frequency to maintain 95°C or below, and should it reach 105°C regardless (e.g. because you'd remove the cooler), it would perform a safety shutdown to avoid burning... There have been examples of ”frying laptops” in the past, but they all were due to battery failures (and only because of a bad design of the latter).
  15. Wrong again... The Cool VL Viewer can render EE settings in WL rendering mode or WL settings in EE rendering mode (the settings are translated automatically). This includes altitude-based environment settings. Of course, some EE-only parameters (e.g. non-standard Moon orbits, or Sun and Moon non-standard textures) cannot be rendered in WL mode, but it won't totally break your personal experience, and won't affect at all the ”shared experience” as seen by other users around your avatar. You still did not get what the rule about not ”altering the shared experience of the virtual world” means: it does not imply that you should have the exact same rendering of a scene in all viewers in a given place, but just that by its mere usage, one viewer won't break the experience as seen by other users around (as it has been the case in the past with non-standard attachment points, which in turn prompted the implementation of that rule).
  16. Wrong ! Once more, the ”shared experience” rule (chapter 2k of the TPVP (*)) is only here to avoid breaking things (how they render or work) in others' viewers than in the one breaking that rule. This has been the case, in a distant past, when a TPV implemented secondary attachment points (back in that time there were much less such points and each point could only have one object attached to it) that caused those supplementary attachments to appear floating around the avatar (or attached in their butt, which could look rather funny) in other viewers not supporting that non-standard feature. This is the very and only reason why this rule got implemented. On the other hand, LL cannot care less about what you render in your own viewer (as long as you do not come back to them to complain about a ”bug” when this is just an unusual feature their official viewer does not implement). If you wish to render with DoF or without, with shadows or without, with ALM or without, with a fixed, custom or a parcel environment, with an EE or WL renderer, you can do it without any issue whatsoever. About EE and WL, the Cool VL Viewer offers you the choice between both sets of shaders (and their matching renderer), and this does not break the ”shared experience” of other avatars around yours, since this is exclusively a viewer-side feature that does not have any impact outside your own screen. And if you want an example of such a viewer-side, non-”rule-2k-breaking” feature with Firestorm, there's the parcel Windlight settings based on a string in the parcel description (which LL elaborated as the Extended Environment); this feature was not supported by LL's viewer, and yet LL never invoked rule 2k.. (*) ”2k. You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.” (emphasis mine).
  17. Problems would have to be solved first for the ”capturing and logging the traffic required for rendering” step: you must understand that the viewer does not grab (neither get sent) everything around your avatar, but only what it needs to render the scene; it depends on your avatar position, the configured draw distance and the camera angle and focus point; it means that your wish to allow camera movements on replay is not really feasible ”as is” (though, one could imagine rotating continuously the camera around in capture mode to trigger ”interest list” updates covering all surrounding objects, obtaining a 360° field of view). You would also need to store permanently (as part of the captured data) all the textures, meshes, animations data, but also particle systems parameters, environment data changes, etc. I'm not sure how this would be considered, on a legal point of view, but it might be perceived as a form of contents ripping/copy-botting (and could certainly be abused in such a way)... I'm skeptical on the feasibility of such a project (and not so much on the strictly technical aspect than on the legal one). As for the benefits in ”lag” terms on replay, you might get disappointed in the end, for the replay viewer would still need to decode textures, meshes and objects data at the proper LOD, run animations, etc, meaning the main loop won't be any faster than what happens after you got everything downloaded and in caches with a normal viewer (at which point, the exact same amount of time would be spent in your replay viewer and in a normal viewer, to render the scene)...
  18. It depends on the viewer... Normally somewhere in the Advanced menu (”Advanced” -> ”Consoles” -> ”Texture console” for the Cool VL Viewer). The keyboard shortcut for the toggle is usually CTRL SHIFT 3. Which would indeed advocate for a lower LOD selection, maybe because of the discard BIAS. Reloading the texture or editing the face causes the best LOD to be forced, regardless of the bias... As soon as the Edit floater is closed or the importance to the camera reevaluated (as a result of a camera zoom change, for example), another LOD may get selected... You may also use the ”LOD info” debug feature (”Advanced” -> ”Rendering” -> ”Info displays” -> ”LOD info” for my viewer) to see what is the LOD the textures are rendered at; beware, it's ”spammy”, and you'll likely have to remove all attachments you are wearing but the one you want to test to see the proper hover text without zooming (zooming would affect the LOD, see below). A possible explanation would be that you changed your default camera settings (the farther zoomed on your avatar, the lower the selected texture LOD)...
  19. You got me curious... Vulkan renderer ?... I'd love to try and adapt it to my viewer, which you would likely classify as ”hyper aggressive”, since I regularly see it suck up assets (meshes and textures, mostly) at over 250Mbps (true TCP/IP observed bandwidth) on a 1Gbps (ATM bandwidth) FTTH link after TPs in un-cached region...
  20. It is possible that your viewer is badly configured, or that it got too little memory to rez textures at the proper level of detail. Watch the ”discard bias” number in the texture console. Ideally (when properly configured and with enough available memory), it should be 0. A higher BIAS means lower texture LODs (i.e. blurry textures) on rezzed objects. This said, have a try with the Cool VL Viewer, and see how it fares...
  21. The Cool VL Viewer is (and has always been) primarily a Linux viewer, since 2007. It can do everything the official SL Windows viewer can do (and more, such as Lua viewer-side scripting), with the exception of the ”path finding capsule” visualization (because there is no Open Source alternative for the closed source Havok code it uses), including uploading meshes with Physics decompositions (based on HACD, which replaces Havok for this task).
  22. If you are using the Cool VL Viewer, you do not need to worry at all about cache locations and file names when logging in in different grids... File names that do risk to collide (such as for the regions objects cache, the inventory caches, etc) have a grid suffix appended for non-SL grids (also, the Cool VL Viewer uses a different cache location or cache file names than any other viewer, where appropriate, so you may use it along other TPVs without any risk). Assets and textures caches are shared, but the collision risk (i.e. encountering two different assets or textures with the same UUID on two different grids) is totally negligible (just as probable as getting a duplicate UUID generated for a new asset/texture uploaded in SL). The only exception is fo UI sounds (which have a fixed UUID but different actual sounds in SL and OpenSim), but even for those, the Cool VL Viewer offers a way to cache UI sounds and make them ”static”, to avoid mix-up when you log in both SL and OpenSim grids...
  23. Well known issue, usually caused by a badly designed product causing a low texture LOD to be used. To work around it, I implemented (years ago) a ”Boost attachment textures LOD” in the Cool VL Viewer... While it works for all rezzed avatars, it of course only works (on their screen) for people using this viewer.
  24. I find it rather funny (and quite silly) that LL did not even properly change the code of their own viewer to prevent UDP fetching of textures after they shut down the service... Got a ”mCanUseNET = !gIsInSecondLife && mUrl.empty();” line in my viewer to implement this trivial limitation (which would translate to ”mCanUseNET = false;” for LL's viewer, since it won't log in OpenSim grids)...
×
×
  • Create New...