Announcement

Collapse
No announcement yet.

Is It Worth Releasing X.Org Server Updates For Old Branches To Help Vintage Hardware?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by RussianNeuroMancer View Post
    I would vote for old Intel GPUs
    Well, we have a lot of them:
    - i810/i815 GPU (1999-2000): extremely crapware, based od i740 (1998)
    - Extreme Graphics I/II (2001-2003): still poor, no hardware shaders, nor full Direct3D 9.0 support
    - Intel GMA 1st gen (2004-2010): the first Intel GPU that is worth something, although the first generation (GMA 900-GMA 3150) was still a kind of crap (no vertex shaders), especially GMA 900 (no WDDM nor Aero support)
    - Intel GMA >= X3000 (2006-2008), especially >= X3500 (2007-2008): the first really good Intel GPU - finally has hardware support for both vertex and pixel shaders
    - HD Graphics (2010-): definitely worth the support

    Originally posted by RussianNeuroMancer View Post
    Radeon HD 2xxx-4xxx, GeForce 6xxx-7xxx, but I have nothing to say about older GPUs.
    So we have here:
    - Radeon HD 2000 series (2007): TeraScale 1, All models support Direct3D 10.0/11 (FL 10_0) and OpenGL 3.3 (Shader Model 4.0), as well as Avivo/UVD and Close to Metal
    - Radeon HD 3000 series (2007): TeraScale 1, All models support Direct3D 10.1/11 (FL 10_1) and OpenGL 3.3 (Shader Model 4.1), as well as UVD+ and Close to Metal
    - Radeon HD 4000 series (2008): TeraScale 1, Same as above, plus UVD 2 and OpenCL 1.1
    - GeForce 6 (6xxx) series (2004-2006): All models support Direct3D 9.0c and OpenGL 2.1 (Shader Model 3.0)
    - GeForce 7 (7xxx) series (2005-2007): Same as above

    Now let's compare it to the still supported S3G/VIA/Zhaoxin Chrome GPU:
    - Chrome9 HD (C-9 HD) in the VX900/VX900M/VX900H chipset (Mar 2010): DirectX 9.0, Shader Model 2.0, Chromotion Video Engine 2.0, hardware MPEG-2/VC-1/WMV-H/DH.264 decoding, X.Org 7.6, ACPI suspend to RAM and suspend to disk, HW Video overlay by X extension XV, UXA 2D HW acceleration, XAA 2D HW acceleration, EXA 2D HW acceleration, AGP path, XRandR 1.2/1.3
    - Chrome 640 (C-640) & Chrome 645 (C-645) in the VX11/VX11H/VX11PH chipset (Aug 2012 for VIA CPU, Q1 2014 for Zhaoxin CPU): DirectX 11, Unified Shader Model/Shader Model 5.0, OpenGL 3.2, OpenGL ES 2.0, OpenCL 1.1, Chromotion Video Engine 5.0, hardware MPEG-2/WMV9/VC-1/H.264 decoding, LVDS/VGA/DVI/HDMI/DisplayPort output, X.Org X11R7.x with H/W 2D acceleration through S3G customized RXA architecture, SAMM / MAMM / Xinerama with multiple display, DVI dual-link up to 2560x1600 resolution, 90/180/270 degree display rotation, H/W accelerated direct-rendering OpenGL 3.2 API, H/W accelerated indirect-rendering OpenGL 3.2 API, Composite Desktop with Compiz, full featured RandR 1.2 function, Kernel Mode Setting with standalone module, full H.264, VC-1, WMV9 and MPEG-2 VLD bitstream H/W decoding through VDPAU or VA API driver
    - Chrome 320 (C-320) in the ZX-100S chipset for the ZX-C and ZX-C+ "ZhangJiang" CPU (Q2 2016/Aug 2016): Generally the same as above (DirectX 11 and OpenGL 3.2) - "256 stream processors iGPU powered by S3 Graphics IP technology and ready for VR"
    - Chrome 860 (C-860) in the ZX-D/KX-5000/KH-20000 "WuDaoKou" SoC (Dec 2017): More or less the same as above (DirectX 11.1 and OpenGL 3.2), plus enhanced decoding capability (H.264/MPEG-4 AVC and H.265/HEVC) as well as HDMI 1.4b support
    - Chrome 960 (C-960) in the ZX-E/KX-6000/KH-30000 "LuJiaZui" SoC (2018/2019): More or less the same as above (DirectX 11.1 and OpenGL 3.2), plus enhanced 4K decoding capability (H.264/MPEG-4 AVC and H.265/HEVC) as well as HDMI 2.0 and DP 1.2a support

    See also:
    https://www.forum-3dcenter.org/vbull...8#post11828218
    https://www.forum-3dcenter.org/vbull...4#post11876014

    Comment


    • #12
      Originally posted by Vistaus View Post

      Linux still runs well on older hardware. You just have to use a lightweight distro.
      Current Linux is much heavier than 2.2, 2.4 or early 2.6 Linux though... *much* back then a kernel with alot of stuff built in even fit on a floppy good luck with that now. Honestly not sure all that much of use has been added either at least not enough to warrant the ammount of size increases.

      Comment


      • #13
        Originally posted by mattst88 View Post
        SLI doesn't work in Linux, does it?
        Voodoo2 SLI does work on Linux! The SLI stuff is all done in hardware. When the two cards are connected via that little ribbon cable, the one card knows to send every-other frame to the second card. And the GLide abstraction layer makes it transparent to the applications.

        I got the first Voodoo2 in 1999, and then added the second card in 2003 I think. When I added the second card, I had trouble with it at first. The solution was to completely remove GLide, and then re-install it. Something during the installation must be detecting 1 card or 2 cards, and installing different libraries or something? Dunno, but GLide re-install got it going.

        Comment


        • #14
          If someone wants to put forth this effort I say let them do it and "More power to them!"

          As for the security issues buried elsewhere in the code, yes that should be a concern, but not a roadblock to the effort because people running that old X code are already exposed to those security issues.

          Now, would it be good to fix the security issues in the old X code if it is still being used? Yes, but a decision has to be made concerning the person-hours & code impact(s?) required versus the time & expense to do so.
          Last edited by NotMine999; 03 January 2019, 04:54 PM.

          Comment


          • #15
            As usual, articles with a question in the title can be summarily answered with "no" and move on.

            Keeping alive old crap matters as long as it actually has any real use (which usually it does not). Nostalgia does not count unless you can cough up the money or man-hours yourself.

            Comment


            • #16
              Depends on what is meant by "old". I figure in the long term it's probably better to bring those old drivers up with the new infrastructure, which seems a lot more structured and simpler to maintain (but of course, this is work too).

              IMHO if it is built by default in an x86 Linux kernel, and it has a corresponding X driver, it should be maintained as long as that is feasible, but of course, whether or not it is feasible is a fairly serious question unto itself.

              Comment


              • #17
                It's something I would find useful too. I'm very largely in to the retro scene and although that mainly consists of my Amiga's I have a few old PC's and hardware I use. Some of the graphics hardware I use include S3 Virge, Matrox Millemium, ATI 128, Nvidia TNT and GeForce 2/4 among others, including some older ISA slot cards. It certainly wouldn't harm anything to receive any updates, even minor ones!

                Comment


                • #18
                  Originally posted by ptyerman View Post
                  It's something I would find useful too. I'm very largely in to the retro scene and although that mainly consists of my Amiga's I have a few old PC's and hardware I use. Some of the graphics hardware I use include S3 Virge, Matrox Millemium, ATI 128, Nvidia TNT and GeForce 2/4 among others, including some older ISA slot cards. It certainly wouldn't harm anything to receive any updates, even minor ones!
                  The problem is the old drivers are what is called "User Mode Setting"(UMS I will use here) .
                  Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

                  With ASpeed that is more modern and also worse in features than every one of the cards mentioned works with "Kernel Mode Setting"(KMS I will use here). So all old cards should be able to have drivers made that are KMS will be a lot work.

                  Now lets get back into the details why UMS is such a problem. As more different security flaws are turning up you are needing more isolation between hardware, kernelmode and usermode.

                  UMS requires you to have access paths from usermode to hardware this requires running X11 server as root user for now to use those paths. https://www.phoronix.com/scan.php?pa...Strict-Dev-Mem
                  At the start of 2018 we started seeing /dev/mem accessibility to be restricted. This did break some UMS graphics drivers at the time.

                  Patching up the UMS drivers is a short term fix. If you are needing this hardware long term someone need to make a KMS driver before the UMS driver no longer can work at all due to kernel security.

                  Comment


                  • #19
                    No need to overthink it and start harping on about things that don't matter. These are old hobbyist machines, not something to be used by inland revenue! An old version 2 of Puppy Linux is running fine on one of them at this moment.

                    Comment


                    • #20
                      Originally posted by ptyerman View Post
                      No need to overthink it and start harping on about things that don't matter. These are old hobbyist machines, not something to be used by inland revenue! An old version 2 of Puppy Linux is running fine on one of them at this moment.
                      I have found government departments using 30 year old computers in places. So that hardware is possible still in critical usage somewhere.

                      Comment

                      Working...
                      X