10 ms·

You might wonder why TempleOS is barely doing 640x480 at 30fps. The GPU is 2000 times faster than the CPU.

i336_ 11y ago
Do you have any current or distant ideas on implementing basic GPU support in TempleOS? Virtualization has gotten to the point where GPU passthrough is beginning to be feasible/viable. PS. I think this is an amazing project. I'm grateful you accepted the challenge in writing it. :D
- garrettgrimsley 11y ago
  "GPU is banned." http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance.html#l1 http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance....
  - i336_ 11y ago
    Ah, right. I wonder what the rationale behind this point is, then - especially considering the GPU is quite a bit more parallel than the CPU.
    - garrettgrimsley 11y ago
      Because God said so. That and the aim of the system is to create something akin to the Commodore 64 in which the entire system is open to the user. http://www.templeos.org/Wb/Doc/Charter.html#l1 http://www.templeos.org/Wb/Doc/Charter.html#l1
      - chippy 11y ago
        "Graphics operations should be transparent, not hidden in a GPU." Is GPU programming opaque, I've not done any low level stuff? I imagine it's a whole bunch of different API calls, but based on triangles, rather than points and lines? Could one write a simple GPU in code, for example, I wonder?
        fit2rule 11y ago
        You'd be surprised just how many layers of abstraction there are between getting something done 'outside' the context of the GPU, and across the CPU/GPU bridge, and getting it done on the GPU in a modern 3D stack these days .. You can do things any one of a number of different ways - pass off a blob of data for rendering, or write shader programs that get compiled for the GPU when the app requires it .. those compilers are not open (shader compilers are an arcane and highly contentious realm of IP-rights-holders in a very competitive and volatile industry) and often-times, the hard work of a 3D developer is spent in moving existing assets (code/resources) from one 3D-pipeline-fashion-runway de-jeur to the next .. It is pretty arcane. That said, of course you can write a software renderer and simulate a fair amount of the work that the GPU will usually offload from the CPU - and in many cases this has been successfully applied - e.g. the Emulation world - to the task of maintaining legacy binary assets in lieu of having source code to port. The emu guys have amazing stats in that regard.
        dogma1138 11y ago
        Well with how modern GPU's, their driver and API's work you write code to do something then the driver "decides" on the "best" way of doing it. Display drivers can replace entire shaders and modify pretty much any instruction and they often do so if nothing than for the code to actually work because game developer not only have shifted allot of the "performance" optimization burden to the GPU vendors but also quite often ship completely non complaint (and nonfunctional) graphics code, there have been plenty of gem posts on gamedev.net including multiple AAA studio's that botched their code so poorly on multiple titles that if it there wasn't a generic fix in the driver already it would not display anything at by not calling D3D::Create, D3D::EndFrame/Begin frame properly or at all in many cases. Overall the majority of the driver codebase today is abstraction and fixes, only about a 3rd of it is actual API implementation.
        choosername 11y ago
        How much performance would a pure and thus leaner driver gain, I wonder. Also a fair bit of backwards compatibility will be involved, like with x86 cpus. And even then, the same fixup is required to run opengl on directX cards, I believe.
      - deleted 11y ago
        [deleted]
  - chungy 11y ago
    "We want algorithms in the open and available for study." -> "A plugin is needed to display this content." Why depend on Flash? Looking at the source, it's just a YouTube video trying to display. That doesn't need Flash, only a simple HTML5 video embed...

i336_ 11y ago

Do you have any current or distant ideas on implementing basic GPU support in TempleOS? Virtualization has gotten to the point where GPU passthrough is beginning to be feasible/viable. PS. I think this is an amazing project. I'm grateful you accepted the challenge in writing it. :D

garrettgrimsley 11y ago
"GPU is banned." http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance.html#l1 http://www.templeos.org/Wb/Home/Web/TAD/GraphicsPerformance....
- i336_ 11y ago
  Ah, right. I wonder what the rationale behind this point is, then - especially considering the GPU is quite a bit more parallel than the CPU.
  - garrettgrimsley 11y ago
    Because God said so. That and the aim of the system is to create something akin to the Commodore 64 in which the entire system is open to the user. http://www.templeos.org/Wb/Doc/Charter.html#l1 http://www.templeos.org/Wb/Doc/Charter.html#l1
    - chippy 11y ago
      "Graphics operations should be transparent, not hidden in a GPU." Is GPU programming opaque, I've not done any low level stuff? I imagine it's a whole bunch of different API calls, but based on triangles, rather than points and lines? Could one write a simple GPU in code, for example, I wonder?
      - fit2rule 11y ago
        You'd be surprised just how many layers of abstraction there are between getting something done 'outside' the context of the GPU, and across the CPU/GPU bridge, and getting it done on the GPU in a modern 3D stack these days .. You can do things any one of a number of different ways - pass off a blob of data for rendering, or write shader programs that get compiled for the GPU when the app requires it .. those compilers are not open (shader compilers are an arcane and highly contentious realm of IP-rights-holders in a very competitive and volatile industry) and often-times, the hard work of a 3D developer is spent in moving existing assets (code/resources) from one 3D-pipeline-fashion-runway de-jeur to the next .. It is pretty arcane. That said, of course you can write a software renderer and simulate a fair amount of the work that the GPU will usually offload from the CPU - and in many cases this has been successfully applied - e.g. the Emulation world - to the task of maintaining legacy binary assets in lieu of having source code to port. The emu guys have amazing stats in that regard.
      - dogma1138 11y ago
        Well with how modern GPU's, their driver and API's work you write code to do something then the driver "decides" on the "best" way of doing it. Display drivers can replace entire shaders and modify pretty much any instruction and they often do so if nothing than for the code to actually work because game developer not only have shifted allot of the "performance" optimization burden to the GPU vendors but also quite often ship completely non complaint (and nonfunctional) graphics code, there have been plenty of gem posts on gamedev.net including multiple AAA studio's that botched their code so poorly on multiple titles that if it there wasn't a generic fix in the driver already it would not display anything at by not calling D3D::Create, D3D::EndFrame/Begin frame properly or at all in many cases. Overall the majority of the driver codebase today is abstraction and fixes, only about a 3rd of it is actual API implementation.
        choosername 11y ago
        How much performance would a pure and thus leaner driver gain, I wonder. Also a fair bit of backwards compatibility will be involved, like with x86 cpus. And even then, the same fixup is required to run opengl on directX cards, I believe.
    - deleted 11y ago
      [deleted]
- chungy 11y ago
  "We want algorithms in the open and available for study." -> "A plugin is needed to display this content." Why depend on Flash? Looking at the source, it's just a YouTube video trying to display. That doesn't need Flash, only a simple HTML5 video embed...