Announcement

Collapse
No announcement yet.

Raspberry Pi Display Driver Patches Updated For [email protected] Support

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

  • #21
    Originally posted by AHOY View Post
    ...after they've added MS spyware by default.
    They... added a vendor repo that you can install software from. That's not spyware, that's a convenience. I guarantee they aren't getting much from an occasional 'wget' to a list of packages.

    Comment


    • #22
      Originally posted by arQon View Post

      I find it very unlikely that your daughter is doing anything that the Pi doesn't actually have enough *compute* for.
      The *display stack* sucks, which can easily lead to it "feeling slow", but that's not the same thing...
      I disagree. The Pi 4 is great for what it is, but it's not powerful enough for casual computing. Even web browsing on it is brutally slow. Just going to 'phoronix.com' taxes six seconds to render the page enough to read, and another seven to finish rendering; on Ethernet. I'm not going to spend eleven seconds waiting on every 'turn of the page' on the web. That's not video hardware either, the CPU is pegged.

      The CPU speed scores closely to a circa-2008 very low-end Core2 Duo, and about 1/10th the speed of a modern Core i3.

      I love mine, I run four of them, including one that hosts a Minecraft server and another that drives a dashboard display, and I'm keen to see the graphics stack fully developed, but I can promise you that the graphics software isn't what's holding it back.

      What I'd love is for the nthe RPI Foundation to bifurcate the product line so I could get a beefy 'Pi Premium' ARM-based board for $120 or so, and the profit would subsidize the cheaper models.

      Comment


      • #23
        Originally posted by mangeek View Post
        I disagree. The Pi 4 is great for what it is, but it's not powerful enough for casual computing. Even web browsing on it is brutally slow. Just going to 'phoronix.com' taxes six seconds to render the page enough to read, and another seven to finish rendering; on Ethernet.
        That sounded very unlikely to me, so I just tried it: less than a second to fully complete, on a mediocre wifi connection. So IDK what your problem is there, but it's not inherent to the Pi.

        > The CPU speed scores closely to a circa-2008 very low-end Core2 Duo

        Could well be. Other than games though, how much software has meaningfully changed (or emerged) since that was a top-end machine? Typical apps? Exactly the same. Office crap? Exactly the same. Pretty much anything else? Exactly the same.

        Video players have learnt 2 or 3 new codecs, none of which are remotely suitable to being handled on any consumer CPU.
        Browsers have learnt HTML5, but that's about it. (Aside from the usual 7000 pointless trivial extensions to CSS, and various other gimmicks that aren't CPU-intensive).

        You do get a lot less grunt per cycle out of an ARM core than you get with x86, but the Pi is still 6.0 "Total GHz" even with no overclocking. Those "very low-end" C2D parts - which I'll take to mean the E4x00 series rather than the E6x00 parts - were, for example, a dual-core E4300 at 1.8GHz, or 3.6 "Total GHz", in an era where almost nothing was multithreaded (and a quad-core C2D cost *$1000*!).

        So, yeah, I don't see a problem here.

        > I can promise you that the graphics software isn't what's holding it back.

        I'm sure you truly mean that, but your promise means little to me, and even less to OP: it clearly *is* the display stack that's holding the Pi back in the overwhelming majority of cases of *user perception*, because a CPU that's on par with a PC of even more than a decade ago is still more than enough for most people's tasks, and even if CPU-bound loads were e.g. 10% slower, it wouldn't really make any difference. "A little bit longer to complete a non-interactive task" hardly ever actually matters, because the task still completes. OTOH, when the display stack is borked, a video doesn't play "at 90% speed", it just *doesn't play* for any useful definition of the word.

        > What I'd love is for the nthe RPI Foundation to bifurcate the product line so I could get a beefy 'Pi Premium' ARM-based board for $120 or so, and the profit would subsidize the cheaper models.

        It's a nice idea, but I think it's not just impractical but more likely to be actively harmful. Unless someone just happened to be manufacturing *exactly* the right parts already - which they wouldn't be because they'd have no need for the second one - and/or was doing full bring-up on both of them, you'd just be spreading RPF's very limited resources even thinner. All you'd have is two outright disappointing products instead of one iffy one. Then there's the additional cost of a much smaller run on the "premium" part, and so on. Like I say, a nice idea - but not a viable one.

        Comment


        • #24
          Originally posted by arQon View Post
          Of course, the whole "64 bits!!1!" thing is about 95% placebo anyway, but who knows - maybe you'll be the 5%).
          the 64-bitness isn't nearly as important as the new instructions and huge increase in the number of registers that aarch64 brings.

          Comment


          • #25
            Originally posted by hotaru View Post
            the 64-bitness isn't nearly as important as the new instructions and huge increase in the number of registers that aarch64 brings.
            The extra registers are nice, but unless one of those new instructions is a full display stack, it's still not going to help. :P

            In reality, using arm64 on the Pi - which is the topic here, not ARM chips in general - removes access to the mmal video accel layer, so it's a massive step DOWN in performaance, unfortunately.

            Comment


            • #26
              Originally posted by arQon View Post

              That sounded very unlikely to me, so I just tried it: less than a second to fully complete, on a mediocre wifi connection. So IDK what your problem is there, but it's not inherent to the Pi.
              Just following up on this, and it turns out that the Pi I was using was suffering from a nasty bug re: DMA that was basically making it run at turtle-like speeds in Ubuntu and Fedora, when I put Raspbian on it, the kernel has workarounds that make browsing bearable for day-to-day use.

              Comment

              Working...
              X