lkml.org 
[lkml]   [2009]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Vramfs: filesystem driver to utilize extra RAM on VGA devices
Well my expectation of vramfs is that it's not meant to be used for the 
heavy-duty 3D gaming-style rendering that GEM is built to handle. It's
meant for lighter tasks, like simple 2D/3D compositing or GPU work where
you know what your resources need, you don't need to take that much, and
you need direct mmap() access because some of it involves video that you
will handle later. Situations like this can work perfectly fine without
the use of a swapping system.

My other concern is that GEM with a filesystem might be the best option
for 3D gaming, but that it wouldn't work if the driver doesn't know the
card. The DRI drivers, as far as I know, are tied to the GPU and chipset
of the device (because they have to manage it, after all!). How exactly
would GEM work for cards that it doesn't recognize, like one machine of
mine with a weird ATI chipset nobody knows how to talk to? If GEM
doesn't recognize it, it won't provide VRAM resources to use it, right?

This is where vramfs has it's advantage: it's not the absolute best
solution for 3D graphics, but it's simple, it can serve as a starting
point for GPU experiments from userspace, or if nothing else allows the
use of the onboard video RAM on an otherwise unused and unrecognized
video device. It's device-agnostic by design.
> The way you want do that is using OpenGL to put your data in textures
> and framebuffer objects, and render them. With KMS, we'll be able to
> support EGL even on the console so you can do the work without having an
> X environment set up.
>
> The problem with vramfs as a basis for GPU offload is that most GPU
> tasks end up at some point exceeding the size of available
> aperture/VRAM. So you need code that manages loading buffer objects in
> and out on demand, managing the execution pipeline and GPU and CPU
> caches as required. We have that with GEM already.
>
> Remember, writing data to an aperture isn't the hard part of offloading
> to the GPU, programming the GPU is. That's why you use OpenGL or
> another abstraction to do it.
>
>



\
 
 \ /
  Last update: 2009-01-28 07:39    [W:0.070 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site