• 1 Post
  • 64 Comments
Joined 1 year ago
cake
Cake day: June 2nd, 2023

help-circle

  • Traditional graphics code works by having the CPU generate a sequence of commands which are packed together and sent to the GPU to run. This extension let’s you write code which runs on the GPU to generate commands, and then execute those same commands on the GPU without involving the CPU at all.

    This is a super powerful feature which makes it possible to do things which simply weren’t feasible in the traditional model. Vulkan improved on OpenGL by allowing people to build command buffers on multiple threads, and also re-use existing command buffers, but GPU pipelines are getting so wide that scenes containing many objects with different render settings are bottlenecked by the rate at which the CPU can prepare commands, not by GPU throughput. Letting the GPU generate its own commands means you can leverage the GPU’s massive parallelism for the entire render process, and can also make render state changes much cheaper.

    (For anyone familiar, this is basically a more fleshed out version of NVIDIA’s proprietary NV_command_list extension for OpenGL, except that it’s in Vulkan and standardized across all GPU drivers)





  • You’ve made me uncertain if I’ve somehow never noticed this before, so I gave it a shot. I’ve been dd-ing /dev/random onto one of those drives for the last 20 minutes and the transfer rate has only dropped by about 4MB/s since I started, which is about the kind of slowdown I would expect as the drive head gets closer to the center of the platter.

    EDIT: I’ve now been doing 1.2GB/s onto an 8 drive RAID0 (8x 600GB 15k SAS Seagates) for over 10 minutes with no noticable slowdown. That comes out to 150MB/s per drive, and these drives are from 2014 or 2015. If you’re only getting 60MB/s on a modern non-SMR HDD, especially something as dense as an 18TB drive, you’ve either configured something wrong or your hardware is broken.


  • This is for very long sustained writes, like 40TiB at a time. I can’t say I’ve ever noticed any slowdown, but I’ll keep a closer eye on it next time I do another huge copy. I’ve also never seen any kind of noticeable slowdown on my 4 8TB SATA WD golds, although they only get to about 150MB/s each.

    EDIT: The effect would be obvious pretty fast at even moderate write speeds, I’ve never seen a drive with more than a GB of cache. My 16TB drives have 256MB, and the 8TB drives only 64MB of cache.





  • Because none of that unused land is set up to allow a machine to easily roll over it and automatically place/replace/clean the panels. Putting panels between the tracks means you get that for free, as the tracks are there anyway, and are already have electrical infrastructure all along their length.

    The point of the experiment is to see if those benefits end up outweighing the presumably higher chance of panels getting damaged. In the worst case it ends up not being worth while and there isn’t a huge loss, in the best case we end up being able to add a bunch of additional solar capacity without having to build much new infrastructure or cover any previously unused land.

    And it would be trivially easy to have a train run over the tracks to clean the panels, there are already trains which use compressed air/sandblasters/lasers to remove leaves and stuff from the rails. Just add a few more compressed air nozzles in between and boom, all your panels are now clean.