Date
1 - 5 of 5
OT: GPUs in render farms?
Jeremy Selan <jeremy...@...>
Can you provide any additional details on the type of code you're considering porting?
At SPI we still do the vast majority of our 'farm' rendering on the CPU. But the artist desktops are fully GPU'd, so for special-case pipelines (where the artist runs some process locally interactive), GPU is great.
If you dont hear back any other answers on this listserv, perhaps try posting to osl-dev? It's offtopic, but I know a lot of rendering guys lurk on that site, so you may get some better insight...
https://groups.google.com/forum/?fromgroups#!forum/osl-dev
-- Jeremy
toggle quoted message
Show quoted text
At SPI we still do the vast majority of our 'farm' rendering on the CPU. But the artist desktops are fully GPU'd, so for special-case pipelines (where the artist runs some process locally interactive), GPU is great.
If you dont hear back any other answers on this listserv, perhaps try posting to osl-dev? It's offtopic, but I know a lot of rendering guys lurk on that site, so you may get some better insight...
https://groups.google.com/forum/?fromgroups#!forum/osl-dev
-- Jeremy
On Mon, Apr 30, 2012 at 12:36 PM, Paul Miller <pa...@...> wrote:
I'm wondering if companies are starting to put GPUs in their render farm machines. I have some GPU-accelerated code and looking at what it might take to convert it to pure CPU - and if that is even necessary.
Any comments?
Paul Miller <pa...@...>
On 5/1/2012 6:37 PM, Jeremy Selan wrote:
It's an effect we've developed that has a very natural OpenGL-based implementation. To get it to run entirely on the CPU we'd basically need a CPU implementation of OGL - or a subset of it at least. It's the kind of thing that an artist probably wouldn't want to wait for though, and since everything else we have renders nicely CPU-only, I guess that is a big point in favor of doing a software path for it.
Can you provide any additional details on the type of code you'reThanks for the pointer.
considering porting?
At SPI we still do the vast majority of our 'farm' rendering on the CPU.
But the artist desktops are fully GPU'd, so for special-case pipelines
(where the artist runs some process locally interactive), GPU is great.
If you dont hear back any other answers on this listserv, perhaps try
posting to osl-dev? It's offtopic, but I know a lot of rendering guys
lurk on that site, so you may get some better insight...
It's an effect we've developed that has a very natural OpenGL-based implementation. To get it to run entirely on the CPU we'd basically need a CPU implementation of OGL - or a subset of it at least. It's the kind of thing that an artist probably wouldn't want to wait for though, and since everything else we have renders nicely CPU-only, I guess that is a big point in favor of doing a software path for it.
Jeremy Selan <jeremy...@...>
Have you considered MESA GPU emulation for the CPU code path?
I believe there are' unnamed' graphics packages out there that use a pure GPU codepath locally, and provide minimal CPU rendering support with a mesa gpu layer.
http://www.fxguide.com/featured/Burn_baby_burn_Discreet_ships_Burn/
-- Jeremy
toggle quoted message
Show quoted text
I believe there are' unnamed' graphics packages out there that use a pure GPU codepath locally, and provide minimal CPU rendering support with a mesa gpu layer.
http://www.fxguide.com/featured/Burn_baby_burn_Discreet_ships_Burn/
-- Jeremy
On Tue, May 1, 2012 at 5:32 PM, Paul Miller <pa...@...> wrote:
On 5/1/2012 6:37 PM, Jeremy Selan wrote:Thanks for the pointer.
Can you provide any additional details on the type of code you're
considering porting?
At SPI we still do the vast majority of our 'farm' rendering on the CPU.
But the artist desktops are fully GPU'd, so for special-case pipelines
(where the artist runs some process locally interactive), GPU is great.
If you dont hear back any other answers on this listserv, perhaps try
posting to osl-dev? It's offtopic, but I know a lot of rendering guys
lurk on that site, so you may get some better insight...
It's an effect we've developed that has a very natural OpenGL-based implementation. To get it to run entirely on the CPU we'd basically need a CPU implementation of OGL - or a subset of it at least. It's the kind of thing that an artist probably wouldn't want to wait for though, and since everything else we have renders nicely CPU-only, I guess that is a big point in favor of doing a software path for it.
Paul Miller <pa...@...>
On 5/1/2012 7:42 PM, Jeremy Selan wrote:
Have you considered MESA GPU emulation for the CPU code path?Yes indeed! But the Windows build process is less than ideal, so I thought I'd do a gut-check first! :-)
I believe there are' unnamed' graphics packages out there that use a
pure GPU codepath locally, and provide minimal CPU rendering support
with a mesa gpu layer.