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 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
                        • mcc@mastodon.socialM mcc@mastodon.social

                          Rust wgpu now has a .agents/skills, a .claude/skills, an AGENTS.md, and a CLAUDE.md.

                          Increasingly wondering if my goal of living in a way that I never benefit from the actions of generative AI users and generative AI users never benefit from the actions of me is going to inherently mean never using hardware-accelerated video on a computer again.

                          discatte@digipres.clubD This user is from outside of this forum
                          discatte@digipres.clubD This user is from outside of this forum
                          discatte@digipres.club
                          wrote sidst redigeret af
                          #124

                          @mcc I ended up down the 'cpu bound' route, see you in 100 hours. https://digipres.club/@discatte/117318307216404824

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

                            @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 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
                            #125

                            @mcc @ireneista @MaddieM4 right, but an open ISA is not the same thing as being able to create silicon with said ISA, for a truly open chip, we do need people who can fabricate said silicon, is more my point

                            also RISC-V is evolving, usually according to how big companies want it, it's not like RISC-V stood still and just froze, there's a lot of funky stuff being added to it (M-mode being my usual example, it reeks of "intel SMM" levels of mistakes personally)

                            ireneista@adhd.irenes.spaceI mcc@mastodon.socialM 2 Replies Last reply
                            0
                            • mcc@mastodon.socialM mcc@mastodon.social

                              @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 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
                              #126

                              @mcc@mastodon.social Of those, Golang does have a specification target, too.

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

                                This thread is probably meandering and maybe solipsistic. My point is this: My weird background means I can look at this staircase full of missing stairs, identify one step, and go, "I can fix that". But I don't know if there's enough of me to fix multiple steps. I haven't decided what to do from here. Pick a step and fix it anyway? Pick a "fun" project, like the GPU [which face it, even if I finished it chances are not high more than 3 people would ever use it]? Give up and learn electric bass?

                                eniko@mastodon.gamedev.placeE This user is from outside of this forum
                                eniko@mastodon.gamedev.placeE This user is from outside of this forum
                                eniko@mastodon.gamedev.place
                                wrote sidst redigeret af
                                #127

                                @mcc i have this intermediate representation layer that's kind of webassembly-ish called bismuth, which i can then create high level languages for that target that IR. and i want to make it so that its easy for people to run their own implementation of a bismuth interpreter

                                then i want to make an OS with it. i think i can do all of this, but i can't make drivers for hardware, so even if slop is barred from the bismuth ecosystem it'll still have to rely on a probably-slop host operating system

                                eniko@mastodon.gamedev.placeE 1 Reply Last reply
                                0
                                • eniko@mastodon.gamedev.placeE eniko@mastodon.gamedev.place

                                  @mcc i have this intermediate representation layer that's kind of webassembly-ish called bismuth, which i can then create high level languages for that target that IR. and i want to make it so that its easy for people to run their own implementation of a bismuth interpreter

                                  then i want to make an OS with it. i think i can do all of this, but i can't make drivers for hardware, so even if slop is barred from the bismuth ecosystem it'll still have to rely on a probably-slop host operating system

                                  eniko@mastodon.gamedev.placeE This user is from outside of this forum
                                  eniko@mastodon.gamedev.placeE This user is from outside of this forum
                                  eniko@mastodon.gamedev.place
                                  wrote sidst redigeret af
                                  #128

                                  @mcc although freedos is, i think, recently going towards a slop-free AI policy? and freedos can run on bare metal with sound on at least some systems. so maybe that's a possibility

                                  not sure if it's helpful to relate all this to you. i figure you might be glad to know you're not alone trying to construct part of a slop free ecosystem while also trying to balance the limitations of being only one person

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

                                    @mcc @ireneista @MaddieM4 right, but an open ISA is not the same thing as being able to create silicon with said ISA, for a truly open chip, we do need people who can fabricate said silicon, is more my point

                                    also RISC-V is evolving, usually according to how big companies want it, it's not like RISC-V stood still and just froze, there's a lot of funky stuff being added to it (M-mode being my usual example, it reeks of "intel SMM" levels of mistakes personally)

                                    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
                                    #129

                                    @amarioguy @mcc @MaddieM4 one hopeful note

                                    in our experience when a company is very big on having NDAs around its tooling, it's because there's nothing hard to replicate about the tooling itself, once you know the basic idea of it

                                    we suspect people who do chip design can already basically say, yeah you need these specific types of simulator to eliminate whatever specific classes of problem

                                    that seems like a thing the community could take on, in principle

                                    amarioguy@social.treehouse.systemsA r@glauca.spaceR 2 Replies Last reply
                                    0
                                    • eniko@mastodon.gamedev.placeE eniko@mastodon.gamedev.place

                                      @mcc although freedos is, i think, recently going towards a slop-free AI policy? and freedos can run on bare metal with sound on at least some systems. so maybe that's a possibility

                                      not sure if it's helpful to relate all this to you. i figure you might be glad to know you're not alone trying to construct part of a slop free ecosystem while also trying to balance the limitations of being only one person

                                      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
                                      #130

                                      RE: https://mastodon.social/@mcc/117338324202161763

                                      @eniko thanks.

                                      and yeah, we need a kernel. one person can't write a kernel. it's not a matter of scope. it's a matter of you have to test more hardware configurations than one person can get in a private residence. we need that kernel handled by an *institution*.

                                      the problem with freedos is if we want to make *games* then probably at some point we want access to sound and video. and if you want your game to render by any method other than CPU-on-framebuffer sound and video become Very Hard.

                                      mcc@mastodon.socialM fabiosantoscode@mastodon.socialF thankfulmachine@oldbytes.spaceT 3 Replies Last reply
                                      0
                                      • mcc@mastodon.socialM mcc@mastodon.social

                                        RE: https://mastodon.social/@mcc/117338324202161763

                                        @eniko thanks.

                                        and yeah, we need a kernel. one person can't write a kernel. it's not a matter of scope. it's a matter of you have to test more hardware configurations than one person can get in a private residence. we need that kernel handled by an *institution*.

                                        the problem with freedos is if we want to make *games* then probably at some point we want access to sound and video. and if you want your game to render by any method other than CPU-on-framebuffer sound and video become Very Hard.

                                        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
                                        #131

                                        @eniko redox is currently capable of handling one channel of mono sound output and i think no support for sound input whatsoever

                                        eniko@mastodon.gamedev.placeE tammeow@cute-spellcasting-ideas.euT soller@floss.socialS 3 Replies Last reply
                                        0
                                        • ireneista@adhd.irenes.spaceI ireneista@adhd.irenes.space

                                          @amarioguy @mcc @MaddieM4 one hopeful note

                                          in our experience when a company is very big on having NDAs around its tooling, it's because there's nothing hard to replicate about the tooling itself, once you know the basic idea of it

                                          we suspect people who do chip design can already basically say, yeah you need these specific types of simulator to eliminate whatever specific classes of problem

                                          that seems like a thing the community could take on, in principle

                                          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
                                          #132

                                          @ireneista @mcc @MaddieM4 agreed, i personally feel there is some hope here, just that i think more eyes need to be on these less often discussed parts of the stack

                                          ireneista@adhd.irenes.spaceI 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