[lkml]   [2003]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
    Linus Torvalds wrote:
    > Quite frankly, I'd much rather see a low-level graphics driver that does
    > _two_ things, and those things only:
    > - basic hardware enumeration and setup (and no, "basic setup" does not
    > mean "mode switching": it literally means things like doing the
    > pci_enable_device() stuff.
    > - serialization and arbitrary command queuing from a _trusted_ party (ie
    > it could take command lists from the X server, but not from untrusted
    > clients). This part basically boils down to "DMA and interrupts". This
    > is the part that allows others to wait for command completion, "enough
    > space in the ring buffers" etc. But it does _not_ know or care what the
    > commands are.

    Thank you for saying it. This is what I have been preaching (quietly)
    for years -- command submission and synchronization (and thus, DMA/irq
    handling) needs to be in the kernel. Everything else can be in
    userspace (excluding hardware enable/enumerate, of course).

    Graphics processors are growing more general, too -- moving towards
    generic vector/data processing engines. I bet you'll see an optimal
    model emerge where you have some sort of "JIT" for GPU microcode in
    userspace. Multiple apps pipeline X/GL/hardware commands into the JIT,
    which in turn pipelines data and microcode commands to the GPU kernel


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:58    [W:0.019 / U:109.724 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site