Henri Beauchamp

The v470 branch is a legacy one to be used for ”old” NVIDIA cards (Kepler GPUs), but will work fine as well with some newer cards (Pascal GPUs, for example). It was not affected by the bug, so you are safe. The list of current NVIDIA Linux drivers can be found here.

What bug are you speaking about ?... For Linux, v515.57 had the deferred rendering breakage (that appeared in v515.48.07) fixed already, and I see no difference with v515.65... I always install NVIDIA's official drivers, never the ones from the distros which come late and often broken...

Parcel media (and media on a prim alike) is intended for streaming media, that is an infinite stream of sound, not for playing a finite sound file in a loop... You just cannot use streaming media for that purpose. You should use a script, instead, and play your sound via llLoopSound() (for short sounds lasting 30s or less) or via an infinite loop of llPlaySound() calls that play a longer sound uploaded as several short 30s sounds.

@Jenna Huntsman See my EDIT above (you posted as I was editing my reply 😛 )...

Then you should be able to reproduce the same problem with LL's performance viewer (to confirm, you may run it under Wine if you only have Linux installed on this PC)... Since other TPVs did not yet backport the new renderer code, the issue won't show in them. EDIT : the problem seems to be related to the new mesh faces sorting algorithm in the performances viewer: LL implemented several of those (and the Cool VL Viewer is using the latest, EDIT2: which is ahead of LL's current release viewer (*)), to try and reproduce the result seen in the older renderer in both ALM and direct rendering mode, but apparently never got it 100% right. The problem being that some mesh designers relied on the draw order depending on prims numbering in the link set (or something in that vein: I did not investigate deeply on this myself), and this is not how it works any more with the new renderer. I can reproduce your issue, but only with some brow size/shape combinations (for every brow shape you may find a brow size or two that will show up just fine, while other sizes will not show)... Here is what I get (brow shape 4: brow size 2 KO first, then size 3 OK): My suggestion is to reproduce the issue with LL's viewer, then open a JIRA issue for it so that LL can fix it... (*) EDIT2: (*) Since the Cool VL Viewer implements an algorithm which pertains to a viewer branch (DRTVWR-548-maint-N, commit: SL-17532 Potential fix for some rigged mesh draw order issues), that is newer than the current LL official viewer release, the issue does not show up (just yet) in the latter... The new algorithm is probably fixing another similar issue but is partly breaking this particular mesh... As I wrote above, LL never got it 100% right. I'd rather wait for LL to fix the issue in their viewer, then backport it... Oh, and the About floater shows that your system is badly configured: the core used by the main thread is running only at 1.2GHz while it should be in turbo mode (i.e above the base 3.7GHz frequency) !... Of course, under these conditions, the frame rates will suck rock. This is likely an issue with how your governor is configured (change it for the ”performance” mode and do check the idle timer driver does have support for Intel compiled in).

Thanks. You spared me another fruitless repro... 😛

You will have to be more specific, because I did not find anything wrong... See by yourself:

*sighs* again, as I wrote above... post your viewer logs: the answer is likely there !!!

Your PI 4 would run faster and better under Linux, which would even allow you to run a TPV 😛

I suppose it depends on the type of the ”massage”... 🤣

The bug is server side: if relogging fixes it, it's not the same bug we are speaking about... The only ”fix” for the server-side bug is to restart the sim.

I'm a bit confused, here... This page is about UUIDs, not passwords... May I suggest you add the passwords length limit to this other Wiki page (under ”Misc”, perhaps): https://wiki.secondlife.com/wiki/Limits ?

Well, I am not a fanboy (at all): I just buy and use the best computer parts for the money. I base my choices on verified facts, not on personal feelings. AMD's cards are good cards, but their OpenGL driver under Windows always sucked rock in the past; Linux users could enjoy much faster Open Source drivers (Mesa), but even then, with an equivalent NVIDIA card, the OpenGL performances always have been much better than AMD's (like +50% and over) in compatibility profile and massively better (with yet another +30% to +100% boost depending on the scene to render) in core GL profile (a mode the ”performance viewer” improvements made possible to use). So, with the (very welcomed) recent optimizations (or de-suckification) of AMD drivers under Windows, you basically see performances on par with Linux drivers for AMD, but that's about it. @Kathrine Jansma also confirmed to me yesterday that with her AMD card and the new drivers under Windows, the core GL profile was still slower than the compatibility profile, so...

Yes, you never know... Just in case I would be a liar ! 🙄 Again, read (the SL change password page example is given there).

In SL, passwords are (now) limited, server-side, to 16 characters. That's why the viewer presents you with an alert (in the form of a blue tool tip dialog) when you try to log in with a larger password in SL, but the viewer itself accepts longer passwords for OpenSim, when other viewers will likely just silently truncate them (in fact, most viewers limit the password length via the password input box limit itself, and anything you type beyond the 16th character is simply ignored; you don't notice it because the password characters are replaced with stars, but count the number of stars when typing your password, and you will see there are 16 max). To log in in SL with your ”too long” password, simply discard all the characters after the 16th... Also, I see nothing ”unwise” in using phpbb... Certainly wiser than using the security-holes-riddled WordPress blog software or other such software... 😝 Finally, even if you do not want to register the support forum, a simple search on it for ”password length” would have presented you with the solution.

This is a known bug, dating back from several months already. Whenever a simulator runs for 3 or 4 days straight (i.e. without any restart during this period), your friends list shows everyone as offline whenever you log in in it. Logging in in another simulator (that was restarted recently enough) will show that this is indeed not an issue on your end, since your online friends will then appear as they should. The only solution, for now, is to ask support to restart the region (mine gets restarted twice a week, every week for this reason)... LL is aware of this bug and ”working on it”...

The specs are OK (but the cooling is still a possible issue that would have to be checked under load). If it is that close to your home and the seller is OK, you could install the SL viewer on it and test it, to see if it runs fine with it... Also, being a second hand PC, do check the SSD health (for example, with gsmartcontrol, smartmontools, CrystalDiskInfo or any other software able to read the SMART info from the SSD): verify there is no reallocated sector or read error (there should be zero for such a recent SSD) and run a short SMART test (it lasts 2 minutes only and will ensure no obvious defect exists)...

Any laptop with: A discrete NVIDIA GPU (forget about Intel iGPUs or AMD APUs, for they are too weak, and forget as well about AMD GPUs, for their OpenGL driver sucks rocks and is way too slooooooow). A fast CPU; the better the mono-core performances the better frame rates: once the GPU taken out of the equation (i.e. with any modern NVIDIA GPU in the system), the fps rates in SL scale almost proportionally with the CPU mono-core performances). Intel or AMD, it does not matter. Lot's of RAM: I'd recommend 16GB as the minimum, preferably 32GB. A reliable storage solution (no eMMC and the like: it would get worn out very fast due to the SL cache writes). Go for either a HD+SSD or a good SSD (and in the latter case, 32GB of RAM is best since it will let you the option to use a RAM disk for the SL cache, thus preventing consuming precious write cycles on your SSD). A good cooling: if your GPU or CPU overheat, they will scale down their frequency and SL fps rates will drop.

Look at the viewer log (note: the ”SecondLife” sub-folder in the path given in the Wiki might be different for TPVs, but you will still find that sub-folder somewhere in the ”Roaming” folder): this message/dialog you get is just the sign that it did not recognize your card, and the log will likely tell us why ! Beside, my recommendation to install NVIDIA's official driver still stands...

You know, posting the viewer(s) log would help diagnose your issue (there will likely be warnings about the missing features that lead to the abortion, and as well information about what GPU it recognized or not). Also, did you try and install NVIDIA's official drivers instead of Dell's one ?... I never use third party vendors drivers, but only the official drivers from the GPU maker.

Check the micro-benchmark ratio in the viewer log, and you will see... Not sure for Windows... Linux had bogus 515 drivers, but they got fixed now... The bugs appeared at the end of May. EDIT: this is not a NVIDIA driver bug, but a Windows 11 bug that got apparently introduced in the last (July 2022) patch Tuesday update (KB5015814, perhaps ?). I just updated my third PC's Windows 11 partition and suddenly saw that bug happening; since that PC uses an old GTX 460 card which driver did not get updated in many months (it went out of support for Win11), it cannot be the fault of that driver (that worked beautifully). After installing the latest preview update (KB5015882), the bug seems to have been cured (your other option being to revert the July updates).

There is an issue with the driver (recent NVIDIA drivers have various issues), as shows the bogus red color of the UI (chat input line for example)... Try and downgrade to a driver that does not show such an issue. Make also sure you did set up your driver to use multi-threading (some TPVs use the NVAPI under Windows to force this on for themselves with NVIDIA cards, but my viewer does not, meaning you must properly configure your driver for it). Also, your CPU is old (4790K @ 4GHz) and, once the GPU powerful enough (which is your case), the SL viewers frame rates scale almost proportionally to the CPU mono-core performances... In comparison, I got a 9700K @ 5GHz; look at the viewer log, at the very start, and you will see a micro-benchmark result I added (”CPU single-core performance factor relative to a 9700K @ 5GHz”), that will give your your CPU mono-core performance ratio compared to mine. Finally, you are running the viewer under Windows, and running it under Linux would give you a 15-20% speed boost...

The renderer needs a rewrite to use Vulkan instead of OpenGL, yes... But threading is a piece of cake to do in C++, especially with Nat Linden's excellent work in the ”performance viewer” and the addition of new threaded work queues. Once the renderer converted to Vulkan, threading it will be also waaaaay easier. As for Rust vs C++, I'm afraid you will not convince me... but I guess that's just because I'm a C programmer at heart. 😛

Like I wrote in my first reply, I used roughly equivalent settings to those of Animats' viewer. In particular, his viewer does not render water reflections, neither transparent water, it does not render avatars, it does not render particles, all of which are extremely taxing on the frame rates... Also, I had to adjust the draw distance, to keep the camera FOV at the limit of the sim border (since his viewer renders just one sim, while normal viewers render whatever is in the draw distance and camera FOV, including in neighbouring sims). Finally, 220fps was the highest I got, not the average, which was closer to 60fps, with dropouts to 30fps or so, during textures decoding/rezzing. If you still do not believe me, here is a capture I just did. Note the settings, the FOV in the mini-map (that's the hardest thing to reproduce to allow a proper comparison, thus my suggestion to do a test in an island instead), and how the textures rezzing slows down the frame rate (I tried to demonstrate this at the end of the video, especially since my viewer got a boost feature for textures rezzing that is great to rez them super fast, but does impact the frame rate while they rez).

Very nice, but nothing extraordinary as far as the frame rate is concerned... With the Cool VL Viewer, I get 30 to 220 fps in roughly (*) the same conditions, but with a weaker GPU (GTX 1070 Ti ”only”) and with a 1920x1200 screen, and with the handicap of the JPEG2000 image decoding. While I do admire your work, I'm sad that you chose to rewrite your viewer from scratch, and in Rust, instead of contributing a Vulkan renderer and/or a better image fetcher/decoder to the existing C++ code base... (*) The viewer cannot rez just a single sim like yours do, so the draw distance must be kept lower (between 128m and 192m while following your track in Port Babbage) than I normally keep it (256m for sims with neighbouring sims) to avoid rezzing too many things from the neighbouring sims, which of course slows down the frame rate. It would be simpler to compare if you could choose an island to make your tests: then I'd push the DD to 512m (as I always do in islands) and we would have a way better ground for performances comparisons.