Re: General beginners questions for debian sparc64
> At an X.org conference in Montreal last year I chatted with someone who > was fixing these sorts of problems for IBM. We might get better progress > by looking at the recent fixes in the PPC and ZOS trees (sorry, I have > that name incorrect). These architectures are big endian so the fixes > might be easily ported to SPARC. > > There might still be problems due to bus word alignment, but from memory > SPARC is more 'flexible' than the others on that issue. Actually... My recent experience on that front is the opposite: Memory misalignment is a much more rampant problem on sparc than endianness issues, and the platform is actually *less* flexible than, for example, x86. As a matter of fact, on x86, the compiler can often automatically generate alignment-safe instructions when it is unsure about alignment. And on most recent x86 CPU generations, these alignment-safe instructions don't even incur a performance penalty. On sparc and other more RISC-like architectures, there are less or no such "fallbacks", requiring expensive workarounds. Here is a beautiful overview of what can go wrong (even on x86): https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html On the other hand, compilers have become very "smart" about optimising away seemingly expensive constructs (such as memcopy) when they are sure there is no alignment issue. As an example, see this patch I wrote for the gcr library: https://gitlab.gnome.org/GNOME/gcr/-/issues/34 > I am still hoping to get my SparcBlade 2000 working again! Though with > no time available. Good luck! It would definitely help the sparc64 Debian port a great deal if more people play with these machines.
Re: General beginners questions for debian sparc64
Hi all, All this breakage seems to be due to many programmers ignoring the simple rules for endian compatibility. At an X.org conference in Montreal last year I chatted with someone who was fixing these sorts of problems for IBM. We might get better progress by looking at the recent fixes in the PPC and ZOS trees (sorry, I have that name incorrect). These architectures are big endian so the fixes might be easily ported to SPARC. There might still be problems due to bus word alignment, but from memory SPARC is more 'flexible' than the others on that issue. I am still hoping to get my SparcBlade 2000 working again! Though with no time available. Cheers -- Rick On June 15, 2020 3:46:56 PM EDT, Gregor Riepl wrote: >> I think i should have the PGX64 chipset in this machine, but i am not >> sure if it uses the correct driver. glxinfo tells me everything is >> fine with direct rendering using llvm. > >The Rage XL[1] is a fairly dated and limited GPU, but it has very good >2D driver support on Linux. I think it can even do Xv and most of the >standard 2D acceleration in X.org. > >> When i try to run glxgears, i get a bus error. When i try to run >> extremetuxracer, i don't get into the game, the errors point to >> unhandled calls in some asound library. > >In theory, the GPU should have OpenGL 1.0 support (and thus be able to >run glxgears), but this may not actually help much in practice. >Practically nobody cares about OpenGL 1.0 any more these days. I don't >know why it crashes, perhaps some OpenGL libraries are missing. It's >also possible that hardware support was dropped at some point, or never >implemented properly. > >> Also i can't run any web browser. Midori and Epiphany crash or don't >> open a website and the current Firefox or Firefox-esr are not >> installable due to missing dependencies. > >That is to be expected. The old Firefox version that is still on the >Debian Ports repo does not work with current libraries, and there are >still various build and runtime issues with recent versions. But I >think >we are slowly getting there. > >> Is any of this current normal behavior or is my configuration >> incorrect at some point and some of these thing are supposed to >> work, albeit slow on these old machines? > >Yes, this is (unfortunately) expected behaviour. The sparc64 still >needs >a lot of TLC before it is ready for regular use. > >Still, I wouldn't want to go back to Solaris. You will not be able to >run much modern (desktop) software on Solaris 8, and this is very >unlikely to change. -- Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: General beginners questions for debian sparc64
> I think i should have the PGX64 chipset in this machine, but i am not > sure if it uses the correct driver. glxinfo tells me everything is > fine with direct rendering using llvm. The Rage XL[1] is a fairly dated and limited GPU, but it has very good 2D driver support on Linux. I think it can even do Xv and most of the standard 2D acceleration in X.org. > When i try to run glxgears, i get a bus error. When i try to run > extremetuxracer, i don't get into the game, the errors point to > unhandled calls in some asound library. In theory, the GPU should have OpenGL 1.0 support (and thus be able to run glxgears), but this may not actually help much in practice. Practically nobody cares about OpenGL 1.0 any more these days. I don't know why it crashes, perhaps some OpenGL libraries are missing. It's also possible that hardware support was dropped at some point, or never implemented properly. > Also i can't run any web browser. Midori and Epiphany crash or don't > open a website and the current Firefox or Firefox-esr are not > installable due to missing dependencies. That is to be expected. The old Firefox version that is still on the Debian Ports repo does not work with current libraries, and there are still various build and runtime issues with recent versions. But I think we are slowly getting there. > Is any of this current normal behavior or is my configuration > incorrect at some point and some of these thing are supposed to > work, albeit slow on these old machines? Yes, this is (unfortunately) expected behaviour. The sparc64 still needs a lot of TLC before it is ready for regular use. Still, I wouldn't want to go back to Solaris. You will not be able to run much modern (desktop) software on Solaris 8, and this is very unlikely to change.
