Skip to content
  • Hjem
  • Seneste
  • Etiketter
  • Populære
  • Verden
  • Bruger
  • Grupper
Temaer
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Kollaps
FARVEL BIG TECH
  1. Forside
  2. Ikke-kategoriseret
  3. Rust wgpu now has a

Rust wgpu now has a

Planlagt Fastgjort Låst Flyttet Ikke-kategoriseret
316 Indlæg 74 Posters 0 Visninger
  • Ældste til nyeste
  • Nyeste til ældste
  • Most Votes
Svar
  • Svar som emne
Login for at svare
Denne tråd er blevet slettet. Kun brugere med emne behandlings privilegier kan se den.
  • mcc@mastodon.socialM mcc@mastodon.social

    @lispi314 @froge i am writing this on a computer from 2016 and i cannot imagine wanting a better computer than that. i don't know what the point would be. if any computer i purchase after this is from later than 2016 it will be for the sole reason that computers from 2016 are not being made anymore.

    in fact, if i could, i'd probably go further back, to 2014, when S3 sleep still existed, and it was therefore possible to run Linux.

    lispi314@udongein.xyzL This user is from outside of this forum
    lispi314@udongein.xyzL This user is from outside of this forum
    lispi314@udongein.xyz
    wrote sidst redigeret af
    #104

    @mcc@mastodon.social @froge@social.glitched.systems Yeah, I’m also using decade+ old hardware for most things other than the gaming machine.

    It works and does the job so it’s fine. Although on one of them spare part availability at remotely acceptable prices is slowly becoming a problem (amusingly it’s not the 20+ years old one).

    The follow-up model on that one is from 2014~ish (unfortunately that runs into ECC DDR4 prices issues, but hopefully that’ll die down before I have to deal with it).

    when S3 sleep still existed, and it was therefore possible to run Linux.

    I don’t think I ever had hardware on which hardware sleep wasn’t broken.


    Only one machine has crossed the two-decades cap so far, that one does visibly struggle with modern SSH initialization/handshake, has no virtualization support and wireguard is heavier than it should be so it has limited tasks.

    The SSH issue was mitigated by some configuration to improve efficiency, mostly around session persistence and multiplexing. Paying the cost of the heavy handshake once instead of every single Ansible task is a noticeable improvement.

    1 Reply Last reply
    0
    • mcc@mastodon.socialM mcc@mastodon.social

      @erincandescent My desktop is from 2016 and I see zero, literally zero, reason to upgrade it. There is no reason to use a piece of hardware released past 2024 except for the fact that eventually the pre-2024 hardware will wear out. Anyway the remainder of the thread is substantially about RISCV

      lispi314@udongein.xyzL This user is from outside of this forum
      lispi314@udongein.xyzL This user is from outside of this forum
      lispi314@udongein.xyz
      wrote sidst redigeret af
      #105
      @mcc @erincandescent If one doesn't play (new) games (or ones that refuse to support older hardware) or use software with fussy hard requirements on newer features, the need gets much lesser indeed.
      mcc@mastodon.socialM 1 Reply Last reply
      0
      • mcc@mastodon.socialM mcc@mastodon.social

        @MaddieM4 @amarioguy a mental tool i keep using is

        "this standard is too large" +
        "if i make my own standard, no one will use it"
        =>
        "can i find a subset of the too-large standard which is tractable to implement, so i can target the subset, and at least the things i create will be usable by users of the 'large' standard"

        maddiem4@raphus.socialM This user is from outside of this forum
        maddiem4@raphus.socialM This user is from outside of this forum
        maddiem4@raphus.social
        wrote sidst redigeret af
        #106

        @mcc @amarioguy a wise approach, honestly.

        1 Reply Last reply
        0
        • mcc@mastodon.socialM mcc@mastodon.social

          Anyway, I spent the last week writing documentation for Redox. The Redox project seems to be happy for my documentation patches. One thimble full of water, out of the sinking boat.

          xdydx@mastodon.socialX This user is from outside of this forum
          xdydx@mastodon.socialX This user is from outside of this forum
          xdydx@mastodon.social
          wrote sidst redigeret af
          #107

          @mcc

          The words "hardware-accelerated video on" in that first entry are doing a lot of heavy lifting...

          1 Reply Last reply
          0
          • lispi314@udongein.xyzL lispi314@udongein.xyz
            @mcc @erincandescent If one doesn't play (new) games (or ones that refuse to support older hardware) or use software with fussy hard requirements on newer features, the need gets much lesser indeed.
            mcc@mastodon.socialM This user is from outside of this forum
            mcc@mastodon.socialM This user is from outside of this forum
            mcc@mastodon.social
            wrote sidst redigeret af
            #108

            @lispi314 @erincandescent one problem is i want to *create* games and those are by nature new. and that creates nonzero complications

            lispi314@udongein.xyzL 1 Reply Last reply
            0
            • mcc@mastodon.socialM mcc@mastodon.social

              Meanwhile, look at the other staircase I want to climb.

              I *don't* have an open-hardware laptop. I have a Lenovo with an AMD chipset. I want a slopless operating system. Redox the OS is slopless, but much of the GUI running atop it is just ports of Linux software, and much of that is slop. The project I've been thinking about *this* year is hacking Redox to boot direct into Servo (the web browser). As I explore this idea, suddenly my "wgpu direct to hardware" idea becomes relevant again:

              lispi314@udongein.xyzL This user is from outside of this forum
              lispi314@udongein.xyzL This user is from outside of this forum
              lispi314@udongein.xyz
              wrote sidst redigeret af
              #109

              @mcc@mastodon.social Redox depending on implementation-defined Rust where the main tooling is being slopped if not Rust itself does seem like a problem.

              Have or are they considering pinning the Rust dependency to a pre-slop version?

              (Honestly the language needs a hard fork that solidifies on a proper specification and then goes specification-driven. These problems will keep happening while it hasn’t.)

              mcc@mastodon.socialM 1 Reply Last reply
              0
              • mcc@mastodon.socialM mcc@mastodon.social

                @amarioguy @MaddieM4 i am far from the only person to think about this. someone will do it eventually. the question is when we hit one that has riscv levels of Go Juice.

                ireneista@adhd.irenes.spaceI This user is from outside of this forum
                ireneista@adhd.irenes.spaceI This user is from outside of this forum
                ireneista@adhd.irenes.space
                wrote sidst redigeret af
                #110

                @mcc @amarioguy @MaddieM4 there's also a thing where...

                our friends who do CPU stuff don't seem to think riscv is going to be outside of the systems of oppression that cause trouble, and we do for sure see how stuff like core layout and fabrication are bottlenecks that allow hegemony to form...

                by all means a GPU that's as open as riscv is would be awesome, but there's more to aspire to

                amarioguy@social.treehouse.systemsA 1 Reply Last reply
                0
                • mcc@mastodon.socialM mcc@mastodon.social

                  @lispi314 @erincandescent one problem is i want to *create* games and those are by nature new. and that creates nonzero complications

                  lispi314@udongein.xyzL This user is from outside of this forum
                  lispi314@udongein.xyzL This user is from outside of this forum
                  lispi314@udongein.xyz
                  wrote sidst redigeret af
                  #111
                  @mcc @erincandescent It certainly does indeed, though it does also put you in the position to evaluate how hostile the engine or framework you intend to use is to older hardware.

                  (Granted depending on what you want them to do exactly, there are limits to that.)

                  Presumably given your no-slop & older computing habits, you'd be intent on something quite friendly.

                  That does leave you with the problem that the groundwork needed to get started needs to be done. A rather unfortunate setback.
                  1 Reply Last reply
                  0
                  • lispi314@udongein.xyzL lispi314@udongein.xyz

                    @mcc@mastodon.social Redox depending on implementation-defined Rust where the main tooling is being slopped if not Rust itself does seem like a problem.

                    Have or are they considering pinning the Rust dependency to a pre-slop version?

                    (Honestly the language needs a hard fork that solidifies on a proper specification and then goes specification-driven. These problems will keep happening while it hasn’t.)

                    mcc@mastodon.socialM This user is from outside of this forum
                    mcc@mastodon.socialM This user is from outside of this forum
                    mcc@mastodon.social
                    wrote sidst redigeret af
                    #112

                    @lispi314 I don't think they're discussing this. This is I believe a very big problem but not my concern at the current time because (1) you need a programming language; that's not optional (1.5) i no longer acknowledge the existence of C (2) there are already at least four Rust backends and at least two frontends (3) i am much more confident i can create an independent Rust implementation than I am confident that I can do literally *any* of the projects described in the thread above.

                    mcc@mastodon.socialM argv_minus_one@mastodon.sdf.orgA 2 Replies Last reply
                    0
                    • mcc@mastodon.socialM mcc@mastodon.social

                      @lispi314 I don't think they're discussing this. This is I believe a very big problem but not my concern at the current time because (1) you need a programming language; that's not optional (1.5) i no longer acknowledge the existence of C (2) there are already at least four Rust backends and at least two frontends (3) i am much more confident i can create an independent Rust implementation than I am confident that I can do literally *any* of the projects described in the thread above.

                      mcc@mastodon.socialM This user is from outside of this forum
                      mcc@mastodon.socialM This user is from outside of this forum
                      mcc@mastodon.social
                      wrote sidst redigeret af
                      #113

                      @lispi314 I do think something is wrong with our framing of the disussion that people are perpetually concerned about slop in Rust but are not concerned about same in C when GCC and clang are both slopped and, in fact, LLVM is the main slop contributor to the Rust implementation at the current time. "But Rust?" is not really a useful objection unless you plan to write an OS in Zig. And as described above, we don't even have an OS in Rust yet.

                      lispi314@udongein.xyzL 1 Reply Last reply
                      0
                      • mcc@mastodon.socialM mcc@mastodon.social

                        @lispi314 I do think something is wrong with our framing of the disussion that people are perpetually concerned about slop in Rust but are not concerned about same in C when GCC and clang are both slopped and, in fact, LLVM is the main slop contributor to the Rust implementation at the current time. "But Rust?" is not really a useful objection unless you plan to write an OS in Zig. And as described above, we don't even have an OS in Rust yet.

                        lispi314@udongein.xyzL This user is from outside of this forum
                        lispi314@udongein.xyzL This user is from outside of this forum
                        lispi314@udongein.xyz
                        wrote sidst redigeret af
                        #114

                        @mcc@mastodon.social Oh GCC is fucked as well.

                        We (disgruntled GCC users) are talking about alternative C compilers, and for x86_64/i686 the situation is relatively not that bad if one doesn’t use a lot of GCC/CLANG extensions.

                        (Other hardware though? Not good.)

                        The problem has also reached some Common Lisp implementations. But I don’t need to use SBCL, when ECL, ABCL & others exist and will work with any compliant program written with portable libraries (it’s seen quite negatively to write implementation-specific libraries unless they’re explicitly named after and targeting a feature of a specific implementation, which will have people avoid it).

                        Zig is actively looking to move away from LLVM. Zig also being implementation-specified annoys me too. (It does for every language, for me.)

                        mcc@mastodon.socialM 1 Reply Last reply
                        0
                        • lispi314@udongein.xyzL lispi314@udongein.xyz

                          @mcc@mastodon.social Oh GCC is fucked as well.

                          We (disgruntled GCC users) are talking about alternative C compilers, and for x86_64/i686 the situation is relatively not that bad if one doesn’t use a lot of GCC/CLANG extensions.

                          (Other hardware though? Not good.)

                          The problem has also reached some Common Lisp implementations. But I don’t need to use SBCL, when ECL, ABCL & others exist and will work with any compliant program written with portable libraries (it’s seen quite negatively to write implementation-specific libraries unless they’re explicitly named after and targeting a feature of a specific implementation, which will have people avoid it).

                          Zig is actively looking to move away from LLVM. Zig also being implementation-specified annoys me too. (It does for every language, for me.)

                          mcc@mastodon.socialM This user is from outside of this forum
                          mcc@mastodon.socialM This user is from outside of this forum
                          mcc@mastodon.social
                          wrote sidst redigeret af
                          #115

                          @lispi314 well, in the year 2026 i'm willing to write an alternative rust compiler, but i'm not willing to write an alternative c compiler. i think there is no justification for using c in the year 2026

                          mcc@mastodon.socialM lispi314@udongein.xyzL 2 Replies Last reply
                          0
                          • mcc@mastodon.socialM mcc@mastodon.social

                            @lispi314 well, in the year 2026 i'm willing to write an alternative rust compiler, but i'm not willing to write an alternative c compiler. i think there is no justification for using c in the year 2026

                            mcc@mastodon.socialM This user is from outside of this forum
                            mcc@mastodon.socialM This user is from outside of this forum
                            mcc@mastodon.social
                            wrote sidst redigeret af
                            #116

                            @lispi314 C/C++ is a bad thing we accepted for a long time because there were no alternatives. the last ten years means we have alternatives. i count at least three

                            and yes, i know zig is moving away from LLVM, that's why i said they're a reasonable alternative

                            lispi314@udongein.xyzL 1 Reply Last reply
                            0
                            • mcc@mastodon.socialM mcc@mastodon.social

                              @lispi314 well, in the year 2026 i'm willing to write an alternative rust compiler, but i'm not willing to write an alternative c compiler. i think there is no justification for using c in the year 2026

                              lispi314@udongein.xyzL This user is from outside of this forum
                              lispi314@udongein.xyzL This user is from outside of this forum
                              lispi314@udongein.xyz
                              wrote sidst redigeret af
                              #117

                              @mcc@mastodon.social

                              i am much more confident i can create an independent Rust implementation

                              The thing is, without a specification to implement, you’ll have to stay bug-compatible with some probably-slopped reference implementation.

                              That’s the problem I see with it.

                              1 Reply Last reply
                              0
                              • ireneista@adhd.irenes.spaceI ireneista@adhd.irenes.space

                                @mcc @amarioguy @MaddieM4 there's also a thing where...

                                our friends who do CPU stuff don't seem to think riscv is going to be outside of the systems of oppression that cause trouble, and we do for sure see how stuff like core layout and fabrication are bottlenecks that allow hegemony to form...

                                by all means a GPU that's as open as riscv is would be awesome, but there's more to aspire to

                                amarioguy@social.treehouse.systemsA This user is from outside of this forum
                                amarioguy@social.treehouse.systemsA This user is from outside of this forum
                                amarioguy@social.treehouse.systems
                                wrote sidst redigeret af
                                #118

                                @ireneista @mcc @MaddieM4 tbf i suspect a lot of it is that a very large amount of the tooling needed to make remotely modern CPUs and chips and such (PDKs, etc) is under so much NDA'ed lock and key (seriously, the things i've heard about this are on the border of absurd...) that you basically need %BIG_COMPANY% resources to even enter the sphere....so effectively even if the ISA is open, it's big companies who are driving the standard effectively

                                mcc@mastodon.socialM 1 Reply Last reply
                                0
                                • mcc@mastodon.socialM mcc@mastodon.social

                                  @lispi314 C/C++ is a bad thing we accepted for a long time because there were no alternatives. the last ten years means we have alternatives. i count at least three

                                  and yes, i know zig is moving away from LLVM, that's why i said they're a reasonable alternative

                                  lispi314@udongein.xyzL This user is from outside of this forum
                                  lispi314@udongein.xyzL This user is from outside of this forum
                                  lispi314@udongein.xyz
                                  wrote sidst redigeret af
                                  #119

                                  @mcc@mastodon.social

                                  i count at least three

                                  I’m actually interested in this. I’ve been looking for specification/standard-backed ones.

                                  For high-level languages I mostly have Java and Common Lisp. But for low-level work I’m kind of stuck, as Ada not only doesn’t have a viable bootstrap compiler yet (nlnet project ongoing) but even ignoring that issue GNAT is GCC-based (ah, I really hope GNAT itself hasn’t been slopped either).

                                  C has a proper specification but I’d rather not write C if I can avoid it.

                                  For “scripting”, shell is POSIX specified. Otherwise Scheme is an option, but portable libraries haven’t really been a thing in Scheme culture (recent language specification changes further enabling it may change this).

                                  mcc@mastodon.socialM 1 Reply Last reply
                                  0
                                  • amarioguy@social.treehouse.systemsA amarioguy@social.treehouse.systems

                                    @ireneista @mcc @MaddieM4 tbf i suspect a lot of it is that a very large amount of the tooling needed to make remotely modern CPUs and chips and such (PDKs, etc) is under so much NDA'ed lock and key (seriously, the things i've heard about this are on the border of absurd...) that you basically need %BIG_COMPANY% resources to even enter the sphere....so effectively even if the ISA is open, it's big companies who are driving the standard effectively

                                    mcc@mastodon.socialM This user is from outside of this forum
                                    mcc@mastodon.socialM This user is from outside of this forum
                                    mcc@mastodon.social
                                    wrote sidst redigeret af
                                    #120

                                    @amarioguy @ireneista @MaddieM4 RISCV already exists. RISCV is already successful. You're suggesting it's impossible to do something that was already successfully done eight years ago

                                    amarioguy@social.treehouse.systemsA 1 Reply Last reply
                                    0
                                    • lispi314@udongein.xyzL lispi314@udongein.xyz

                                      @mcc@mastodon.social

                                      i count at least three

                                      I’m actually interested in this. I’ve been looking for specification/standard-backed ones.

                                      For high-level languages I mostly have Java and Common Lisp. But for low-level work I’m kind of stuck, as Ada not only doesn’t have a viable bootstrap compiler yet (nlnet project ongoing) but even ignoring that issue GNAT is GCC-based (ah, I really hope GNAT itself hasn’t been slopped either).

                                      C has a proper specification but I’d rather not write C if I can avoid it.

                                      For “scripting”, shell is POSIX specified. Otherwise Scheme is an option, but portable libraries haven’t really been a thing in Scheme culture (recent language specification changes further enabling it may change this).

                                      mcc@mastodon.socialM This user is from outside of this forum
                                      mcc@mastodon.socialM This user is from outside of this forum
                                      mcc@mastodon.social
                                      wrote sidst redigeret af
                                      #121

                                      @lispi314 rust, zig, go. go isn't well suited for an operating system. but i think i could hack it until it was

                                      lispi314@udongein.xyzL 1 Reply Last reply
                                      0
                                      • mcc@mastodon.socialM mcc@mastodon.social

                                        @trurl @sabrina also, I would like to hear more about this "rewriting window maker" project lol

                                        trurl@mastodon.sdf.orgT This user is from outside of this forum
                                        trurl@mastodon.sdf.orgT This user is from outside of this forum
                                        trurl@mastodon.sdf.org
                                        wrote sidst redigeret af
                                        #122

                                        @mcc @sabrina ...I am not proud of how little progress I've made, as it's not been done at all efficiently. (Rewriting WINGs in Rust while mostly maintaining source-level compatibility with the original C library is probably kinda dumb. But I am learning.)

                                        Most recent status update is that I'm un-mothballing it again and making sense of a backlog of local changes so they can all get pushed to a project repo. You're welcome to look:

                                        https://git.sdf.org/vitrine/wmaker
                                        https://git.sdf.org/trurl/wmaker

                                        1 Reply Last reply
                                        0
                                        • mcc@mastodon.socialM mcc@mastodon.social

                                          Okay so now what I'm looking at is Redox. Redox is the OS project I find that's interested in being written by humans instead of people who have decided to replace parts of their brain with a corporation. I can live with this. I've got an update on my Redox thread I haven't posted yet, but for these purposes what's important is Redox doesn't have, and considers a far-future goal, video acceleration. That makes sense. But it means there's a gap in the staircase I wish to climb.

                                          jefverbeeck@mastodon.socialJ This user is from outside of this forum
                                          jefverbeeck@mastodon.socialJ This user is from outside of this forum
                                          jefverbeeck@mastodon.social
                                          wrote sidst redigeret af
                                          #123

                                          @mcc

                                          Thanks for mentioning @redox
                                          Never heard about them before, but when I read their book, they seem to have all their priorities straight.

                                          1 Reply Last reply
                                          0
                                          Svar
                                          • Svar som emne
                                          Login for at svare
                                          • Ældste til nyeste
                                          • Nyeste til ældste
                                          • Most Votes


                                          • Log ind

                                          • Login or register to search.
                                          Powered by NodeBB Contributors
                                          Graciously hosted by data.coop
                                          • First post
                                            Last post
                                          0
                                          • Hjem
                                          • Seneste
                                          • Etiketter
                                          • Populære
                                          • Verden
                                          • Bruger
                                          • Grupper