Jump to content

Henri Beauchamp

Resident
  • Posts

    1,180
  • Joined

Posts posted by Henri Beauchamp

  1. On 11/9/2023 at 12:44 AM, Henri Beauchamp said:

    However, I am not sure how LL specified their build target on github for Windows: if they did not specify a WINVER=0x0601 option, then their viewer binary won't run on anything older than Win10...

    I verified and LL's viewers can still be ran under Windows 7, with the exception of the CEF plugin (it simply won't start) and the version checker (but deleting SLVersionChecker.exe from the installation directory allows to start and run the viewer just fine).

    I also started a poll for my own viewer...

    • Thanks 1
  2. 2 hours ago, Flea Yatsenko said:

    The official client in WINE loves to crash on me though.

    Wine got bugs (at least two of which do impact viewers), making it a very bad option to run a viewer under Linux. I got workarounds for those bugs in the Cool VL Viewer, but even so, the stability is at best fragile, and the frame rates and smoothness very bad...

    Just run native Linux builds.

  3. 3 hours ago, Ardy Lay said:

    Do publishers of viewers for Second Life provide lists of Linux distributions and versions on which their viewers run reliably?

    I give the prerequisite on the Cool VL Viewer web site:

    Quote

    The provided Linux viewer binary for the stable branch should run on any Linux x86_64 (2018-ish or newer) system with glibc v2.27, libstdc++ v6.0.25 and glib v2.58.3 or newer. You may as well easily build the viewer yourself (with just one command !) on any x86_64 Linux system.

     

    • Thanks 2
  4. For the version checker (and Python) issue, you can simply remove the SLVersionChecker.exe binary from the viewer installation directory (the viewer will complain it cannot start it, but will run without it nevertheless).

    However, I am not sure how LL specified their build target on github for Windows: if they did not specify a WINVER=0x0601 option, then their viewer binary won't run on anything older than Win10...

    The Cool VL Viewer still can run under Windows 7 (and 8.x), but for a couple releases it has already been using LL's CEF v118 github's build to replace the (vulnerable) CEF v91 old build, meaning you won't have a working web plugin any more under Win 7/8.x... I might add an option to build it against CEF v91 again, but you'd need a Win10+ system (or VM) to build it anyway (since VS2022 won't run either under Win7, even if it can build Win7-compatible binaries)...

    It becomes harder to support Win7/8.x, and updates to those, while still possible using tricks and hacks (making them POSReady-like systems), will also soon cease to be distributed by M$...

    Time to upgrade... Or switch to Linux ! 😜

    • Like 2
  5. 18 hours ago, Fionalein said:

    @Henri Beauchamp did anyone ever try CoolVL-ARM on TERMUX?

    The Cool VL Viewer (not ”CoolVL”, please...) requires a proper OpenGL driver to work (it does not have a text-only/headless mode), so it won't work on this terminal emulator...

  6. 5 hours ago, Fionalein said:

    I got the ARM64 build of CoolVL running natively on a Pi4 on Bookworm. But it runs at 1 fps

    There must be something very wrong in your system configuration, then... Tanuki, who built and used the viewer on their RockPro64 reported 10-25fps... Of course, it was not with ALM+shadows...

    This said, the level of OpenGL support for your card is of course the determining factor... If your Mesa version does not support your iGPU, it will fallback to CPU-side rendering, which will prove too slow to be at all usable.

     

    9 hours ago, Tastic2 said:

    A Vulkan-based translation layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine.

    The viewer is NOT using Direct3D, but for the graphics driver version and VRAM amount detections. For rendering, it uses OpenGL, and only OpenGL, so the Vulkan code will never be used.

    The fact the viewer can run fine under Wine emulation for you (meaning you got a valid native OpenGL driver for your SBC, which Wine is using too), simply proves that you could run a native ARM64 build even faster (since then there will be no need for x86_64 to ARM64 CPU emulation/translation).

    • Like 1
    • Thanks 3
  7. You should instead try and compile a genuine Linux viewer on your Pi: it has been a while the necessary libraries have not been updated, but the Cool VL Viewer used to compile and work (natively) on such SBCs.

    I am still keeping an eye myself on the Rockchip RK3588- based SBCs (such as the Orange Pi5, or the Radaxa Rock 5B), since they will be way more capable for running a full-fledged viewer. If I could find one such board at an affordable price (and with proper Linux support, especially for their iGPU), I would buy one and start providing ARM64 builds of my viewer...

    • Like 1
    • Thanks 1
  8. 1 hour ago, Navy1 Coba said:

    Is there some issue what is going on with Firestorm and SL Viewer and group notices? (I checked with a guy that has 2 bots using Radegast, the text viewer, and he got them on both bots)

    This would be the sign that the (relatively) new ”ReadOfflineMsgs” capability is bugging (again): Radegast is old and does not use it (it uses the legacy ”RetrieveInstantMessages” UDP message). You could do this too with the Cool VL Viewer (In the ”Advanced” -> ”Network” menu, un-check ”Use offline IMs fetch capability”), and FS might have an equivalent setting (at least, it did have one in the past); ask to their support group.

    It might also be worth filing a JIRA issue for this bug, so that LL works on the broken capability (be it server or viewer side).

  9. 5 hours ago, Freda Fredriksson said:

    MacOS 1.13.6

    I suppose you mean ”10.13.6” (macOS Sierra) ?... This is the minimum requirement as of last Summer. So, it should work... If it does not, open a JIRA issue for it, providing all the info you can (a stack trace is most helpful), and in the mean time, you could use one of the TPVs' macOS builds, instead...

     

  10. 30 minutes ago, Flea Yatsenko said:

    The only Adobe software that runs natively on Windows ARM is Photoshop and Lightroom. x86 isn't just about all this old software you're talking about, there's lots of modern proprietary software that doesn't run on ARM at all. A lot of modern content creation software does not work on ARM.

    They would run just fine under x86 emulation over ARM, just like what Apple did with Rosetta (and no, I do not like Apple, at all, due to their closed source, closed hardware, and Open Source-hostile policies, not to mention their tax evading policy, but when they do something ”right”, they deserve my recognition for it)...

    • Like 3
  11. 58 minutes ago, Love Zhaoying said:

    Sounds like the OP wanted a ”Windows vs. Linux” argument..?

    Well, currently, Linux (and its forks, such as Android) and BSD (and its forks, such as macOS) are immensely more common than Windows for ARM hardware. So... 😛

    As for ARM vs x86, here is my stance:

    As a Linux user, should we get ARM-based desktop PCs with the same performances as existing high end desktop x86 PCs, it won't bother the least to switch to the ARM solution, much to the contrary !

    x86 is an antediluvian, poorly designed ISA (*), which is today impaired by all the compatibility modes it must keep to run old software, causing bloated CPUs full of (mostly) useless parts needed to run those legacy 16 and 32 bits modes, support segmented memory (eeek !) and whatnot... ARM would at least allow to get rid of all this old cruft, once and for all (and yes, at the cost of using emulators for the old software, but those won't suffer from the emulation since they were designed to work on waaaaay slower hardware).

     

    (*) If only IBM had chosen Motorola and its gorgeous m68k ISA (32 bits registers, flat memory model, I/O in memory address space), instead of Intel and the 8088 (8 bits, segmented memory, separate I/O ports), we would have gained 10 years of advance in OS design for PCs, instead of waiting before Windows 95 (1995) and Linux (1992) could finally offer true multitasking 32 bits OS for the x86; back in the 80s, we already had genuine 32 bits OSes on the Macs, the Sinclair QL, the Amigas, the ATARIs, and genuine preemptive multitasking on the QL and Amigas...

    • Like 2
  12. 2 hours ago, elleevelyn said:

    Then Microsoft Windows 11 Update said I can't update my now apparently potato computer from Windows 10.

    In fact, you perfectly can... Micro$oft hid them, but the options to install (or upgrade) to Windows 11 do exist, even on super-old hardware; I installed it on my 4th PC (the ”main PC” I was using back in 2008-2012), which is based on an old Core Quad Q6600 with 8GB RAM and a GTX 460, without EFI (thus without a TPM neither ”secure boot”), and therefore on a MBR disk.

    The simplest way to do it is probably via the use of Rufus to setup a bootable USB stick installation drive.

    Another option is to install Linux (as a dual boot if you really want to keep Windoze after having tasted to the speed, stability, safety and freedom brought by the Penguin's OS 😜 ); it would juice out the best possible performances from your aging PC.

    • Like 1
  13. 20 hours ago, Ardy Lay said:

    Ah, so now it's the opposite of what I remember from running Second Life Viewer on the ICE I had access to.  It was functionally equivalent to an Intel W3550 and was reporting around 40% cache misses when running Second Life Viewer on Windows XP and around 44% cache misses when running Second Life Viewer on Linux.  Looking that CPU up I see it had 8MB of ”Intel Smart Cache”.  I currently run on an i9-13900k which apparently has 36MB of ”Intel Smart Cache”.  I see 32MB of L2 cache listed too.  Very different environment.  Foolish of me to assume the contemporary CPU cache is still too small.  I no longer live in a design lab and don't know how to get CPU cache hit/miss statistics on my home computer.  I may try to look that up.

    The cache misses will happen, especially on data, but on instructions, it is likely that all critical parts of the viewer code (the parts that run at every frame) will be kept in the CPU caches: they will of course migrate between the L1, L2 and L3 caches (especially during context switching by the OS scheduler), but today's L3 caches are so large, that the probability to see this critical code evicted from it is very slim...

    Also, be careful: L1 and L2 caches are per CPU (full, i.e. non-virtual) core (so the total quoted amount is to be divided by the number of cores, and by two again for the L1 instruction/data caches actual size per core), while L3 is shared (though maybe split in two, e.g. for AMD's Zen4 CCDs with 2x32MB for non-3D parts and 32MB/96MB for 3D ones); Intel recently made it even more confusing, with their ”smart cache”, which may allow cores to use some L2 cache from other inactive cores...

    It would be interesting to do some benchmarking on a Zen4 with 3D-V cache (and two CCDs) and see wether assigning the viewer main thread to a (full = 2 SMT virtual cores) core on the 3D CCD gives better results or not than when assigned to a core on the other CCD (with the smaller L3 cache)... This can easily be done with the Cool VL Viewer, using the ”MainThreadCPUAffinity” setting.

  14. On 10/24/2023 at 8:51 PM, Sammy Huntsman said:

    Okay, well if someone does that. They are responsible for the personal info they put out. That being said, if you are stupid enough to put all that in a public group. Then that is a you problem. I only share that personal info, with people I am really close to in SL and they have earned my respect and trust.

    There is nothing ”stupid” in sharing info with persons you trust in ”public” places (not so public, for SL chat, just like for a RL pub; their audience is however limited and known from the chatters at the moment they are chatting).

    Beside, you cannot use others' ”stupidity” as an excuse to violate a TOS (here, SL TOS).

    On 10/24/2023 at 8:51 PM, Sammy Huntsman said:

    That all being said, if you don't like a group doing that. Here is a simple way to deal with it. Leave the group.

    I never said otherwise, but what I say is that if a place uses such a relaying tool, there must be an unmissable warning about it for everyone visiting that place that their chat will be relayed and recorded (one of the aspects of Discord I personally dislike) outside of SL.

    Not saying no one should use such tools, but just saying they must be used in accordance with SL TOS... And I do not see how anyone could disagree with this !

    'nuff said !

    • Like 1
  15. The 3D-V cache would not bring any benefit to SL viewers. The latter are already small enough to fit all the critical parts of their code into the L3 cache on non-3D counterparts, and the latter boost higher in frequency (the SL viewer is very sensitive to mono-core CPU performances).

    I myself bought a Ryzen 7900X for my new main PC, which replaced one with a 9700K. I'm not interested in a 7900X-3D; the 7900X performs beautifully in SL, and is a beast to compile large programs. E.g. the Cool VL Viewer compiles in less than 3 minutes on it, which is a huge time savior, when compared to the 10 minutes it took on the 9700K. Even CEF (the embedded browser library used for the viewer web plugin) builds (from scratch, with downloads, git ”deltas” etc, which take about 35 minutes to complete) in less than 1H35 (against 2H10 for the 9700K)...

    • Like 2
  16. 7 hours ago, Sammy Huntsman said:

    Chat does not contain personal info, unless you are stupid enough to put your personal info in the chat.

    It may contains private matters, especially during adult role-plays, e.g. about your kinks, which in turn can hint about your sexual preferences, RL gender, etc... It may also contain hints about your RL location (where you live), your political opinions, or other things you would share with persons you chat with in SL (and not necessarily during a RP, but about RL matters instead) when ”face to face” with their avatar, after you came to ”know them” better, or even, more private things you would chat with a group of SL friends, and that you would never share ”in the open” on Internet.

    You cannot make any assumption about what a chat post will contain, and whether or not it could lead to private info disclosure (even if indirectly). You cannot therefore relay the chat for everyone to an external service (especially one that exposes that chat publicly) without first ensuring the chatting persons are aware about it.

    Here is a RL analogy: you go get a drink in a pub with a group of buddies, and you chat in that pub about stuff (politics, private relations, your health, etc): you do so in a ”public” place (and other clients could overhear your conversation), yet you would sue the owner of that pub should they record your conversation and publish it on Internet... Same thing for SL !

    • Thanks 1
  17. 11 hours ago, Ember Ember said:

    Telling me to reread your message when you appear to have not read any of mine where I stated most of these factors already is extremely rude.

    Whatever you wrote earlier is not the issue I reacted about (and yes, I did read your former messages, and even visited the sites you linked to).

    What I reacted about is your dangerous shortcut in the very message I reacted to (what you wrote before this message did not shock me), and more precisely, the part in this sentence of yours I cited in my last post:

    17 hours ago, Ember Ember said:

    because it’s all public information the user already consented to sharing by agreeing to Linden Lab’s TOS.

    This shortcut you did means ”LL TOS approval = Discord TOS approval”, and is all wrong. This is exactly what I reacted about. Period.

    And there is strictly nothing ”rude” in my post, so please do not be ”rude” in your turn...

    • Thanks 3
    • Haha 1
  18. 4 hours ago, Ember Ember said:

    No personal data about the user is transmitted without the user’s knowledge because it’s all public information the user already consented to sharing by agreeing to Linden Lab’s TOS.

    Re-read my message above . The SL TOS is not the Discord TOS !... A SL Resident obviously agreed to the SL TOS, but who tells you they also agreed to Discord's one (I certainly did not, and thus why I am not using Discord) ?

    As as per the SL TOS and Community Standards, you are not allowed to retransmit out of SL in any way the chat you get with someone in SL, unless all the chatting persons have explicitly and beforehand agreed to this.

    Now, if you are using your chat relaying tools for specific purposes, in a place (e.g. a shop, a private sim, etc) where any entering residents would be forewarned that you are retransmitting their chat, this is acceptable (if they are not happy about it, they can move on to another place)... Same thing for a group for which you would relay the IMs, on the condition this is clearly specified in the charter of the said group (if they joined the group, they agreed to its charter).

  19. 34 minutes ago, filz Camino said:

    If you happen to have a dual boot Windows/Linux machine, I'd be interested in seeing some actual numbers for frame rates on both platforms compared.

    I do, and I get at the very minimum +10% fps rates under Linux when compared with Windows 11, both optimized to the extreme, with same clocks on CPU and GPU, and for the bloated Windoze 11, every useless/superfluous ”service” turned off (or right out uninstalled/removed/destroyed), including Search, Defender, etc. The difference in fps rates can go up to +25% in favour of Linux, depending on the scene being rendered.

    But what is the most impressive, is the difference in smoothness: under Windows, the same viewer (whatever the viewer, provided it got both native Linux and Windows builds) will experience way more ”hiccups” and unstable frame rates than under Linux. The difference there is massive. Not to mention stability, especially with some Windows drivers (I am in particular thinking about AMD's OpenGL drivers here)...

    Have a look at this post for some OpenGL performances comparisons.

    • Like 2
  20. Do not even think about trying Linux, or it will make you cry, so much faster, smoother and stabler it is compared with the other (lesser) OSes... 🤣

    macOS always had a very lame/ancient/partial/bogus OpenGL implementation, so it is no surprise at all it is so much slower with SL viewers.

    If you want good performances in SL out of Macintosh hardware, then install Linux on it !

    • Like 1
  21. 1 hour ago, PixelBerry said:

    If anything they should create a official secondlife discord group.

    There is one. Not using it myself (I hate Discord), but exhuming a chat log taken during Open Source meeting, here is the info about it:

    Channel: https://discord.gg/gP7H7XVAP3

    Invite request form: https://docs.google.com/forms/d/1I0jtI2N_od9MxkECctnjpFa-W8Vc5Qke41gJcf0v5Yg/

    It was setup to discuss contents creation and stuff, but there are likely other ”rooms” (or whatever they call it in Discord) for other stuff...

  22. Today, I made an immense effort (no, I'm not even kidding here), and filed up a JIRA, which took me a lot of precious time (that I could have much better spent developing my viewer instead) and made my old-fart-self grumble and pester against this poorly designed piece (to stay polite) of web site, with my password forgotten by the JIRA (again, and as pretty much every time I use it), small text boxes to fill up the form when I need a wall of text, no ”draft” saving for that form, so that you can gather any missing data from another OS (with reboot needed) and come back to the form editing when you got that data, etc, etc... 😞

    So, here you go Linden Lab: https://jira.secondlife.com/browse/BUG-234564

    It will not be said that I do not do every effort to help improving SL...

    • Like 1
    • Thanks 3
×
×
  • Create New...