* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
@ 2003-10-25 18:37 ` Linus Torvalds
0 siblings, 0 replies; 67+ messages in thread
From: Linus Torvalds @ 2003-10-25 18:37 UTC (permalink / raw)
To: Egbert Eich
Cc: Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik
On Sat, 25 Oct 2003, Egbert Eich wrote:
>
> Speaking of XFree86: when I developed the PCI resource stuff in
> XFree86 I was trying to get support from kernel folks to get the
> appropriate user space interfaces into the kernel. When I got
> nowhere I decided to do everything myself.
There won't be any "user space interfaces". There are perfectly good
in-kernel interfaces, and anybody who needs them needs to be in kernel
space. Ie the kernel interfaces are for kernel modules, not for user space
accesses.
The kernel module can be a simple interface layer like DRI, but the thing
is, it needs to be specific to some kind of hardware. I refuse to have
some kind of crap "user space driver" interface - drivers in user space
are a mistake.
> Is there any API that allows one to do this from user space?
No. And I don't really see any huge reason for it.
> There are plenty of XFree86 drivers around that don't have a
> DRM kernel module and it should be possible to run those which
> do without DRI support, therefore it would be a good if the
> XFree86 driver could do this registration itself.
If you do this, do it _right_. Look at what X really needs, and make a
driver for it. A _real_ driver. Not just a half-hearted "we want to do
things in user space, but we can't".
Face it, a good graphics driver needs more than just "set up the ROM". It
needs DMA access, and the ability to use interrupts. It needs a real
driver.
It basically needs something like what the DRI modules tend to do.
I'd be really happy to have real graphics drivers in the kernel, but quite
frankly, so far the abstractions I've seen have sucked dead donkeys
through a straw. "fbcon" does way too much (it's not a driver, it's more a
text delivery system and a mode switcher). And DRI is too complex and
fluid to be a good low-level driver.
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.
Then, fbcon and DRI and X could all three use these basics - and they'd be
_so_ basic that the hardware layer could be really stable (unlike the DRI
code that tends to have to upgrade for each new type of command that DRI
adds - since it has to take care of untrusted clients. So DRI would
basically use the low-level driver as a separate module, the way it
already uses AGP).
But I'm _not_ interested in some interfaces to let user mode just bypass
the kernel. Because they will not solve any of the other problems that
clearly _do_ need solving, and if the X server continues to believe that
it can just access the hardware directly, it will never play well together
with projects like fbcon/dri.
Linus
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
@ 2003-10-25 19:17 ` Jeff Garzik
-1 siblings, 0 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-25 19:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel
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
driver.
Jeff
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-25 19:17 ` Jeff Garzik
0 siblings, 0 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-25 19:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel
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
driver.
Jeff
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-25 19:17 ` [Dri-devel] " Jeff Garzik
(?)
@ 2003-10-27 14:37 ` Ingo Oeser
-1 siblings, 0 replies; 67+ messages in thread
From: Ingo Oeser @ 2003-10-27 14:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Linus Torvalds
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> 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
> driver.
These "JIT" is needed also for another reason:
There are contraints for GPU commands and the pipelines need to
be modelled, like CPU piplines are modelled in a compiler. But
more like the pipelines of some early long instruction word
processors, where issuing to a used pipeline will cause random
behavior and crashes. So the JIT doesn't should also emit
synchronization points.
With this JIT in place, there need to be just some hardware description
files (backends) and some API (GL, DirectX, X) description files
(frontends).
Now we just need some funding for that and the datasheets. Then it's
doable.
I see just one showstopper: Cheating in benchmarks isn't possible anymore.
PS: That's basically the GGI approach taken further.
Regards
Ingo Oeser
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 19:17 ` [Dri-devel] " Jeff Garzik
(?)
(?)
@ 2003-10-27 14:37 ` Ingo Oeser
2003-10-27 15:43 ` [Dri-devel] " Jeff Garzik
-1 siblings, 1 reply; 67+ messages in thread
From: Ingo Oeser @ 2003-10-27 14:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Linus Torvalds
On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> 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
> driver.
These "JIT" is needed also for another reason:
There are contraints for GPU commands and the pipelines need to
be modelled, like CPU piplines are modelled in a compiler. But
more like the pipelines of some early long instruction word
processors, where issuing to a used pipeline will cause random
behavior and crashes. So the JIT doesn't should also emit
synchronization points.
With this JIT in place, there need to be just some hardware description
files (backends) and some API (GL, DirectX, X) description files
(frontends).
Now we just need some funding for that and the datasheets. Then it's
doable.
I see just one showstopper: Cheating in benchmarks isn't possible anymore.
PS: That's basically the GGI approach taken further.
Regards
Ingo Oeser
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-27 14:37 ` [Dri-devel] Re: [Linux-fbdev-devel] " Ingo Oeser
@ 2003-10-27 15:43 ` Jeff Garzik
0 siblings, 0 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-27 15:43 UTC (permalink / raw)
To: Ingo Oeser
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Linus Torvalds
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > 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
> > driver.
>
> These "JIT" is needed also for another reason:
>
> There are contraints for GPU commands and the pipelines need to
> be modelled, like CPU piplines are modelled in a compiler. But
> more like the pipelines of some early long instruction word
> processors, where issuing to a used pipeline will cause random
> behavior and crashes. So the JIT doesn't should also emit
> synchronization points.
>
> With this JIT in place, there need to be just some hardware description
> files (backends) and some API (GL, DirectX, X) description files
> (frontends).
I agree 60% ;-) This JIT emits GPU-specific microcode, so it should
lean towards being hardware-dependent. Speed and efficiency IMO demand
that.
Looking at existing, open-source CPU JITs, there are certainly general
pieces and CPU-specific pieces. But for GPUs, I think the best method
is to start at the more-GPU-specific end of the spectrum, and _evolve_
towards a more general solution, as hardware needs dictate.
In other terms, let the hardware drive the JIT design and evolution, and
don't over-design for a future that may never come. That was part of
GGI's problem, IMO.
> Now we just need some funding for that and the datasheets. Then it's
> doable.
Yep ;-)
> I see just one showstopper: Cheating in benchmarks isn't possible anymore.
>
> PS: That's basically the GGI approach taken further.
I followed GGI for a while. Trying to be all things to all people was
their principle mistake. As Pat Morita said in Karate Kid,
"Focus, Daniel-san!" Be specific before general.
Jeff
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-27 15:43 ` Jeff Garzik
0 siblings, 0 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-27 15:43 UTC (permalink / raw)
To: Ingo Oeser
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Linus Torvalds
On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > 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
> > driver.
>
> These "JIT" is needed also for another reason:
>
> There are contraints for GPU commands and the pipelines need to
> be modelled, like CPU piplines are modelled in a compiler. But
> more like the pipelines of some early long instruction word
> processors, where issuing to a used pipeline will cause random
> behavior and crashes. So the JIT doesn't should also emit
> synchronization points.
>
> With this JIT in place, there need to be just some hardware description
> files (backends) and some API (GL, DirectX, X) description files
> (frontends).
I agree 60% ;-) This JIT emits GPU-specific microcode, so it should
lean towards being hardware-dependent. Speed and efficiency IMO demand
that.
Looking at existing, open-source CPU JITs, there are certainly general
pieces and CPU-specific pieces. But for GPUs, I think the best method
is to start at the more-GPU-specific end of the spectrum, and _evolve_
towards a more general solution, as hardware needs dictate.
In other terms, let the hardware drive the JIT design and evolution, and
don't over-design for a future that may never come. That was part of
GGI's problem, IMO.
> Now we just need some funding for that and the datasheets. Then it's
> doable.
Yep ;-)
> I see just one showstopper: Cheating in benchmarks isn't possible anymore.
>
> PS: That's basically the GGI approach taken further.
I followed GGI for a while. Trying to be all things to all people was
their principle mistake. As Pat Morita said in Karate Kid,
"Focus, Daniel-san!" Be specific before general.
Jeff
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-27 15:43 ` [Dri-devel] " Jeff Garzik
(?)
@ 2003-10-28 10:53 ` Ingo Oeser
-1 siblings, 0 replies; 67+ messages in thread
From: Ingo Oeser @ 2003-10-28 10:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Linus Torvalds
On Monday 27 October 2003 16:43, Jeff Garzik wrote:
> On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote:
> > On Saturday 25 October 2003 21:17, Jeff Garzik wrote:
> > > 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
> > > driver.
> >
> > These "JIT" is needed also for another reason:
> >
> > There are contraints for GPU commands and the pipelines need to
> > be modelled, like CPU piplines are modelled in a compiler. But
> > more like the pipelines of some early long instruction word
> > processors, where issuing to a used pipeline will cause random
> > behavior and crashes. So the JIT doesn't should also emit
> > synchronization points.
> >
> > With this JIT in place, there need to be just some hardware description
> > files (backends) and some API (GL, DirectX, X) description files
> > (frontends).
>
> I agree 60% ;-) This JIT emits GPU-specific microcode, so it should
> lean towards being hardware-dependent. Speed and efficiency IMO demand
> that.
>
> Looking at existing, open-source CPU JITs, there are certainly general
> pieces and CPU-specific pieces. But for GPUs, I think the best method
> is to start at the more-GPU-specific end of the spectrum, and _evolve_
> towards a more general solution, as hardware needs dictate.
Yes, you are partially right. The GCC project had already the problem
that they startet too simple with their pipeline management and had to
redesign it.
If the kernel framework will not suffice the vendor needs (e.g. they
don't win in the benchmark, just because we cannot model their
hardware), it will be simply not used and we'll get just another nvidia
like driver.
But maybe I've read to much GCC internals recently, so I favor machine
descriptions and stateful pipeline descriptions for this ;-)
Your key argument still holds: This is just taking a instruction/data stream
from multiple sources and mapping it to another one with multiple
data/instruction sinks -> JIT.
> I followed GGI for a while. Trying to be all things to all people was
> their principle mistake. As Pat Morita said in Karate Kid,
> "Focus, Daniel-san!" Be specific before general.
I noticed that it's ok to keep the design in mind, even in the comments,
but it never proved good to me to keep the design in dead code and
useless layers.
So I guess, we agree here ;-)
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 19:17 ` [Dri-devel] " Jeff Garzik
@ 2003-10-27 15:14 ` Keith Whitwell
-1 siblings, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:14 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
Jeff Garzik wrote:
> 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).
To enable secure direct rendering on current hardware (ie without secure
command submission mechanisms), you need command valididation somewhere. This
could be a layer on top of the minimal dma engine Linus describes.
> 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.
You mean like the programmable fragment and vertex hardware that has been in
use for a couple of years now?
Keith
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-27 15:14 ` Keith Whitwell
0 siblings, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:14 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
Jeff Garzik wrote:
> 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).
To enable secure direct rendering on current hardware (ie without secure
command submission mechanisms), you need command valididation somewhere. This
could be a layer on top of the minimal dma engine Linus describes.
> 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.
You mean like the programmable fragment and vertex hardware that has been in
use for a couple of years now?
Keith
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-27 15:14 ` [Dri-devel] " Keith Whitwell
(?)
@ 2003-10-27 15:38 ` Jeff Garzik
-1 siblings, 0 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-27 15:38 UTC (permalink / raw)
To: Keith Whitwell
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote:
> Jeff Garzik wrote:
> >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).
>
> To enable secure direct rendering on current hardware (ie without secure
> command submission mechanisms), you need command valididation somewhere.
> This could be a layer on top of the minimal dma engine Linus describes.
Certainly.
> >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.
>
> You mean like the programmable fragment and vertex hardware that has been
> in use for a couple of years now?
I mean, taking current fragment and vertex processing and making it
even _more_ general. Which has already happened, on one particular chip
maker's chip...
Jeff
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-27 15:14 ` [Dri-devel] " Keith Whitwell
(?)
(?)
@ 2003-10-27 15:38 ` Jeff Garzik
2003-10-27 15:50 ` [Dri-devel] " Keith Whitwell
2003-10-27 15:50 ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
-1 siblings, 2 replies; 67+ messages in thread
From: Jeff Garzik @ 2003-10-27 15:38 UTC (permalink / raw)
To: Keith Whitwell
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote:
> Jeff Garzik wrote:
> >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).
>
> To enable secure direct rendering on current hardware (ie without secure
> command submission mechanisms), you need command valididation somewhere.
> This could be a layer on top of the minimal dma engine Linus describes.
Certainly.
> >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.
>
> You mean like the programmable fragment and vertex hardware that has been
> in use for a couple of years now?
I mean, taking current fragment and vertex processing and making it
even _more_ general. Which has already happened, on one particular chip
maker's chip...
Jeff
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-27 15:38 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
@ 2003-10-27 15:50 ` Keith Whitwell
2003-10-27 15:50 ` [Dri-devel] Re: [Linux-fbdev-devel] " Keith Whitwell
1 sibling, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
Jeff Garzik wrote:
> On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote:
>
>>Jeff Garzik wrote:
>>
>>>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).
>>
>>To enable secure direct rendering on current hardware (ie without secure
>>command submission mechanisms), you need command valididation somewhere.
>>This could be a layer on top of the minimal dma engine Linus describes.
>
>
> Certainly.
>
>
>
>>>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.
>>
>>You mean like the programmable fragment and vertex hardware that has been
>>in use for a couple of years now?
>
>
> I mean, taking current fragment and vertex processing and making it
> even _more_ general. Which has already happened, on one particular chip
> maker's chip...
I think that generally you can view all the current generation of hardware as
arbitary programmable devices, and most of the graphics drivers are doing
code-generation for that hardware on the fly. This isn't exactly new ground
for graphics drivers as graphics hardware has alternated (I'm told) between
fixed function and programmable cores multiple times now.
In addition, graphics drivers have been doing on-the-fly codegen for the host
cpu since year dot. The orignal software-rasterization SGI opengl drivers for
windows were supposed to be pretty much state of the art in this respect.
Now that the barriers for codegen have lowered so dramatically (see, eg.
http://fabrice.bellard.free.fr/tcc/), it is now feasible to talk of building a
code-generating software rasterizer for mesa.
Keith
Keith
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-27 15:38 ` [Dri-devel] Re: [Linux-fbdev-devel] " Jeff Garzik
2003-10-27 15:50 ` [Dri-devel] " Keith Whitwell
@ 2003-10-27 15:50 ` Keith Whitwell
1 sibling, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Egbert Eich, Jon Smirl, Eric Anholt, kronos,
Kernel Mailing List, linux-fbdev-devel, dri-devel
Jeff Garzik wrote:
> On Mon, Oct 27, 2003 at 03:14:11PM +0000, Keith Whitwell wrote:
>
>>Jeff Garzik wrote:
>>
>>>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).
>>
>>To enable secure direct rendering on current hardware (ie without secure
>>command submission mechanisms), you need command valididation somewhere.
>>This could be a layer on top of the minimal dma engine Linus describes.
>
>
> Certainly.
>
>
>
>>>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.
>>
>>You mean like the programmable fragment and vertex hardware that has been
>>in use for a couple of years now?
>
>
> I mean, taking current fragment and vertex processing and making it
> even _more_ general. Which has already happened, on one particular chip
> maker's chip...
I think that generally you can view all the current generation of hardware as
arbitary programmable devices, and most of the graphics drivers are doing
code-generation for that hardware on the fly. This isn't exactly new ground
for graphics drivers as graphics hardware has alternated (I'm told) between
fixed function and programmable cores multiple times now.
In addition, graphics drivers have been doing on-the-fly codegen for the host
cpu since year dot. The orignal software-rasterization SGI opengl drivers for
windows were supposed to be pretty much state of the art in this respect.
Now that the barriers for codegen have lowered so dramatically (see, eg.
http://fabrice.bellard.free.fr/tcc/), it is now feasible to talk of building a
code-generating software rasterizer for mesa.
Keith
Keith
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
@ 2003-10-25 21:02 ` Jon Smirl
-1 siblings, 0 replies; 67+ messages in thread
From: Jon Smirl @ 2003-10-25 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik, Egbert Eich
--- Linus Torvalds <torvalds@osdl.org> 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.
>
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
>
Linus, why don't you refuse updates from these projects until this is sorted
out? Your proposal is exactly what it needed. For a year now I have been poking
at these issues and making very little progress. I do know that all of the
pieces needed already exist; but without some incentive there is very little
reason to rearchitect the existing code.
Personally I'm working on a standalone version of Mesa (OpenGL). This would
allow us to write a 3D hardware based windowing system in response to the ones
on the Mac and MS Longhorn. But instead of working on a windowing system I've
spent all of my time trying to help sort out the video device drivers.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-25 21:02 ` Jon Smirl
0 siblings, 0 replies; 67+ messages in thread
From: Jon Smirl @ 2003-10-25 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik, Egbert Eich
--- Linus Torvalds <torvalds@osdl.org> 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.
>
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
>
Linus, why don't you refuse updates from these projects until this is sorted
out? Your proposal is exactly what it needed. For a year now I have been poking
at these issues and making very little progress. I do know that all of the
pieces needed already exist; but without some incentive there is very little
reason to rearchitect the existing code.
Personally I'm working on a standalone version of Mesa (OpenGL). This would
allow us to write a 3D hardware based windowing system in response to the ones
on the Mac and MS Longhorn. But instead of working on a windowing system I've
spent all of my time trying to help sort out the video device drivers.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
@ 2003-10-25 22:07 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 67+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-25 22:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, Kronos, Kernel Mailing List,
Linux Fbdev development list, dri-devel, Jeff Garzik
> Face it, a good graphics driver needs more than just "set up the ROM". It
> needs DMA access, and the ability to use interrupts. It needs a real
> driver.
>
> It basically needs something like what the DRI modules tend to do.
>
> I'd be really happy to have real graphics drivers in the kernel, but quite
> frankly, so far the abstractions I've seen have sucked dead donkeys
> through a straw. "fbcon" does way too much (it's not a driver, it's more a
> text delivery system and a mode switcher). And DRI is too complex and
> fluid to be a good low-level driver.
Well... While I tend to agree, note that in 2.6 fbcon and the fbdev
itself _do_ have been separated. The fbdevs are moving toward that
low level driver thing.
> 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.
IMHO, that low level driver should be ... the fbdev. The main reason for
that is the necessary locking & synchronisation between the command flow
and mode switching, palette control and cursor control (which aren't
things doable via the normal command path on moth cases).
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
I agree that fbcon itself should (and is now in 2.6) be a separate
module. The interface is still scary, the locking is almost absent,
which is a real problem even with current mode switching beeing racy
with printk & blanking, but at least we have something that works and
can evolve in the right direction.
Look how the fbdev interface was simplified in the 2.4 -> 2.6
transition, it's really a lot saner now, and I hope it will continue
to improve.
> But I'm _not_ interested in some interfaces to let user mode just bypass
> the kernel. Because they will not solve any of the other problems that
> clearly _do_ need solving, and if the X server continues to believe that
> it can just access the hardware directly, it will never play well together
> with projects like fbcon/dri.
Fully agreed. My point is that this low-level driver and the fbdev should
be one thing.
Ben.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-25 22:07 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 67+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-25 22:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, Kronos, Kernel Mailing List,
Linux Fbdev development list, dri-devel, Jeff Garzik
> Face it, a good graphics driver needs more than just "set up the ROM". It
> needs DMA access, and the ability to use interrupts. It needs a real
> driver.
>
> It basically needs something like what the DRI modules tend to do.
>
> I'd be really happy to have real graphics drivers in the kernel, but quite
> frankly, so far the abstractions I've seen have sucked dead donkeys
> through a straw. "fbcon" does way too much (it's not a driver, it's more a
> text delivery system and a mode switcher). And DRI is too complex and
> fluid to be a good low-level driver.
Well... While I tend to agree, note that in 2.6 fbcon and the fbdev
itself _do_ have been separated. The fbdevs are moving toward that
low level driver thing.
> 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.
IMHO, that low level driver should be ... the fbdev. The main reason for
that is the necessary locking & synchronisation between the command flow
and mode switching, palette control and cursor control (which aren't
things doable via the normal command path on moth cases).
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
I agree that fbcon itself should (and is now in 2.6) be a separate
module. The interface is still scary, the locking is almost absent,
which is a real problem even with current mode switching beeing racy
with printk & blanking, but at least we have something that works and
can evolve in the right direction.
Look how the fbdev interface was simplified in the 2.4 -> 2.6
transition, it's really a lot saner now, and I hope it will continue
to improve.
> But I'm _not_ interested in some interfaces to let user mode just bypass
> the kernel. Because they will not solve any of the other problems that
> clearly _do_ need solving, and if the X server continues to believe that
> it can just access the hardware directly, it will never play well together
> with projects like fbcon/dri.
Fully agreed. My point is that this low-level driver and the fbdev should
be one thing.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
` (3 preceding siblings ...)
(?)
@ 2003-10-27 14:01 ` jlnance
-1 siblings, 0 replies; 67+ messages in thread
From: jlnance @ 2003-10-27 14:01 UTC (permalink / raw)
To: linux-kernel
On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
> Face it, a good graphics driver needs more than just "set up the ROM". It
> needs DMA access, and the ability to use interrupts. It needs a real
> driver.
>
> It basically needs something like what the DRI modules tend to do.
On Tue, 16 Jan 1996, Linus Torvalds wrote:
> X goes to hardware directly, but that's just because it should do it.
> And exactly _because_ it's an application, it can be just about as
> complex as it wants (and needs) to be. So you have a user-level device
> driver: is that not a good idea? The microkernel people are jumping up
> and down and wetting themselves in excitement over things like that.
Its not that I dont think you are entitled to change your mind. Its just
that the second version is so quotable that it has stuck in my mind oh
these many years.
Jim
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
@ 2003-10-27 15:10 ` Eric W. Biederman
-1 siblings, 0 replies; 67+ messages in thread
From: Eric W. Biederman @ 2003-10-27 15:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
> >
> > Speaking of XFree86: when I developed the PCI resource stuff in
> > XFree86 I was trying to get support from kernel folks to get the
> > appropriate user space interfaces into the kernel. When I got
> > nowhere I decided to do everything myself.
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
Well almost. There is still one significant flaw in the kernel space stuff.
The BIOS can specify arbitrary regions as reserved in the E820 map and then
a kernel driver can't use that region itself. This shows up in corner
cases where the resource on the PCI device is a boolean rather than
a general purpose thing. Particularly for mtd map drivers to allow
flashing your ROM from linux this is a problem.
This is not required for 2.6.0 but it would be nice to actually be able
to reliably reserve resources in kernel drivers.
Eric
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-27 15:10 ` Eric W. Biederman
0 siblings, 0 replies; 67+ messages in thread
From: Eric W. Biederman @ 2003-10-27 15:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
> >
> > Speaking of XFree86: when I developed the PCI resource stuff in
> > XFree86 I was trying to get support from kernel folks to get the
> > appropriate user space interfaces into the kernel. When I got
> > nowhere I decided to do everything myself.
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
Well almost. There is still one significant flaw in the kernel space stuff.
The BIOS can specify arbitrary regions as reserved in the E820 map and then
a kernel driver can't use that region itself. This shows up in corner
cases where the resource on the PCI device is a boolean rather than
a general purpose thing. Particularly for mtd map drivers to allow
flashing your ROM from linux this is a problem.
This is not required for 2.6.0 but it would be nice to actually be able
to reliably reserve resources in kernel drivers.
Eric
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
2003-10-25 18:37 ` Linus Torvalds
@ 2003-10-27 15:10 ` Keith Whitwell
-1 siblings, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik
Linus Torvalds wrote:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
>
>>Speaking of XFree86: when I developed the PCI resource stuff in
>>XFree86 I was trying to get support from kernel folks to get the
>>appropriate user space interfaces into the kernel. When I got
>>nowhere I decided to do everything myself.
>
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
>
> The kernel module can be a simple interface layer like DRI, but the thing
> is, it needs to be specific to some kind of hardware. I refuse to have
> some kind of crap "user space driver" interface - drivers in user space
> are a mistake.
>
>
>>Is there any API that allows one to do this from user space?
>
>
> No. And I don't really see any huge reason for it.
>
>
>>There are plenty of XFree86 drivers around that don't have a
>>DRM kernel module and it should be possible to run those which
>>do without DRI support, therefore it would be a good if the
>>XFree86 driver could do this registration itself.
>
>
> If you do this, do it _right_. Look at what X really needs, and make a
> driver for it. A _real_ driver. Not just a half-hearted "we want to do
> things in user space, but we can't".
>
> Face it, a good graphics driver needs more than just "set up the ROM". It
> needs DMA access, and the ability to use interrupts. It needs a real
> driver.
>
> It basically needs something like what the DRI modules tend to do.
>
> I'd be really happy to have real graphics drivers in the kernel, but quite
> frankly, so far the abstractions I've seen have sucked dead donkeys
> through a straw. "fbcon" does way too much (it's not a driver, it's more a
> text delivery system and a mode switcher). And DRI is too complex and
> fluid to be a good low-level driver.
>
> 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.
>
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
That makes sense - the abstraction of dma engine away from the
security-providing gumpf that is so much of the DRM modules, to form a single
kernel-level "owner" of the graphics hardware.
This would also answer various questions that float around regarding who is
the ultimate "owner" of the graphics hardware - in particular, who is
responsible for virtualization of the graphics memory.
Of course, that's a trickier task because it is one which doesn't just rip
existing code out of various poorly-conceived modules.
Keith
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
@ 2003-10-27 15:10 ` Keith Whitwell
0 siblings, 0 replies; 67+ messages in thread
From: Keith Whitwell @ 2003-10-27 15:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Egbert Eich, Jon Smirl, Eric Anholt, kronos, Kernel Mailing List,
linux-fbdev-devel, dri-devel, Jeff Garzik
Linus Torvalds wrote:
> On Sat, 25 Oct 2003, Egbert Eich wrote:
>
>>Speaking of XFree86: when I developed the PCI resource stuff in
>>XFree86 I was trying to get support from kernel folks to get the
>>appropriate user space interfaces into the kernel. When I got
>>nowhere I decided to do everything myself.
>
>
> There won't be any "user space interfaces". There are perfectly good
> in-kernel interfaces, and anybody who needs them needs to be in kernel
> space. Ie the kernel interfaces are for kernel modules, not for user space
> accesses.
>
> The kernel module can be a simple interface layer like DRI, but the thing
> is, it needs to be specific to some kind of hardware. I refuse to have
> some kind of crap "user space driver" interface - drivers in user space
> are a mistake.
>
>
>>Is there any API that allows one to do this from user space?
>
>
> No. And I don't really see any huge reason for it.
>
>
>>There are plenty of XFree86 drivers around that don't have a
>>DRM kernel module and it should be possible to run those which
>>do without DRI support, therefore it would be a good if the
>>XFree86 driver could do this registration itself.
>
>
> If you do this, do it _right_. Look at what X really needs, and make a
> driver for it. A _real_ driver. Not just a half-hearted "we want to do
> things in user space, but we can't".
>
> Face it, a good graphics driver needs more than just "set up the ROM". It
> needs DMA access, and the ability to use interrupts. It needs a real
> driver.
>
> It basically needs something like what the DRI modules tend to do.
>
> I'd be really happy to have real graphics drivers in the kernel, but quite
> frankly, so far the abstractions I've seen have sucked dead donkeys
> through a straw. "fbcon" does way too much (it's not a driver, it's more a
> text delivery system and a mode switcher). And DRI is too complex and
> fluid to be a good low-level driver.
>
> 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.
>
> Then, fbcon and DRI and X could all three use these basics - and they'd be
> _so_ basic that the hardware layer could be really stable (unlike the DRI
> code that tends to have to upgrade for each new type of command that DRI
> adds - since it has to take care of untrusted clients. So DRI would
> basically use the low-level driver as a separate module, the way it
> already uses AGP).
That makes sense - the abstraction of dma engine away from the
security-providing gumpf that is so much of the DRM modules, to form a single
kernel-level "owner" of the graphics hardware.
This would also answer various questions that float around regarding who is
the ultimate "owner" of the graphics hardware - in particular, who is
responsible for virtualization of the graphics memory.
Of course, that's a trickier task because it is one which doesn't just rip
existing code out of various poorly-conceived modules.
Keith
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <20031027114006.A66611@xfree86.org>]
* Re: [Dri-devel] Re: DRM and pci_driver conversion
[not found] ` <20031027114006.A66611@xfree86.org>
@ 2003-10-27 19:38 ` Ian Romanick
2003-10-27 21:32 ` Linus Torvalds
0 siblings, 1 reply; 67+ messages in thread
From: Ian Romanick @ 2003-10-27 19:38 UTC (permalink / raw)
To: David Dawes; +Cc: dri-devel, fb-devel
David Dawes wrote:
> On Sat, Oct 25, 2003 at 11:37:05AM -0700, Linus Torvalds wrote:
>
>>But I'm _not_ interested in some interfaces to let user mode just bypass
>>the kernel. Because they will not solve any of the other problems that
>>clearly _do_ need solving, and if the X server continues to believe that
>>it can just access the hardware directly, it will never play well together
>>with projects like fbcon/dri.
>
> XFree86 cares more about being a useable X server on a wide range of
> platforms than on playing well with a few Linux-specific hacks.
>
> The real problem is that you have a mix of ideologies in the Linux
> kernel, each struggling for supremacy. Come back to us when you know
> who the winner is. At that time I'm sure you'll feel free to re-write
> history and claim that we should have been doing things that way all
> along.
I'm really baffled here. Why would you even say such a thing? In
relation to Linus' *whole* message, your first paragraph and second
paragraph are incongruous. Linus (or anyone else) did not suggest that
XFree86 be shoe-horned into any of the existing Linux video driver
architectures. In fact, he said quite the opposite. He said that
XFree86 is trying to do things that really do need kernel support, and
all the existing methods for doing that suck.
Part of the problem is that, with the exception of DRI, the existing
video specific interfaces in Linux were, as far as I know, created
without input from XFree86. You're suggesting that same mistake be
repeated.
I'm also baffled by the general animosty shown towards Linux. Judging
by the traffic on the various lists, it seems to me that Linux and *BSD
represent the lion's share of the XFree86 user base. Making a consious
choice to not support those platforms better is making a consious choice
to not support our users. I simply don't understand the rationalle
behind such a decision.
Not only that, there is no requirement that the drivers use any given
kernel interface. Just because the drivers use a kernel interface on
Linux or *BSD does not mean that they have to use a kernel interface on
Solaris or HPUX. There will be growing pains involved in having a
kernel path and a non-kernel path. I think that several of the DRI
drivers (Radeon and Rage128) have shown that it *is* doable.
The next step is to create a kernel interface that is both generic
enough and specific enough to acomplish the task at hand. After
watching the development of fbdev / fbcon, DRI, and XFree86 for a long
time, I can say that there is no point in squabling over whether or not
a kernel interface is useful for performance or necessary for proper
device configuration. Both of those questions have been sufficiently
answered. The question of where we go from here has not been answered.
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-27 19:38 ` Ian Romanick
@ 2003-10-27 21:32 ` Linus Torvalds
2003-10-27 23:55 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 67+ messages in thread
From: Linus Torvalds @ 2003-10-27 21:32 UTC (permalink / raw)
To: Ian Romanick; +Cc: David Dawes, dri-devel, fb-devel
On Mon, 27 Oct 2003, Ian Romanick wrote:
>
> I'm also baffled by the general animosty shown towards Linux.
I don't think it is animosity vs Linux per se, but I do think that XFree86
tends to have a very strong bias against infrastructure change.
Which is somewhat understandable: I'm a kernel person, so infrastructure
change is what I'm all about, but most other projects really hate having
any kind of rug pulled out from under them.
And kernel modules are _nasty_. From past experience, I can just say that
external kernel modules (ones not integrated into the standard kernel
tree) just generate a lot of pain on all sides. Users, project developers,
and kernel developers universally _hate_ having to try to keep external
modules working and debugging the problems that inevitably happen when
they don't work.
So animosity toward them is certainly understandable - they just don't
work very well, and are a total maintenance nightmare.
This is the reason why I decided I had to follow the DRI CVS tree: just to
try to make the DRI kernel modules basically irrelevant to most people. My
theory is that peopel are more likely to happily upgrade the whole kernel
than to try to fight the version skew that inevitable happens with
external kernel modules.
This is, btw, also the reason why I have been an asshole about backwards
compatibility wrt the DRI project, and was less-than-perfectly-polite to
some people when DRI upgrades caused older setups to fail. That's simply
because my belief is that version skew is simply unacceptable, which means
that the only _acceptable_ situation is to try to make it ok to always
have the most recent kernel.
So otherwise we'd have to go back to the "use external modules" thing,
which I just don't believe works.
This is also the reason I believe that the only really workable way to
handle this is to have a very version-neutral (and thus _stupid_)
minimal driver for handling the low-level needs of all the projects
involved (DRI/XFree86/fbcon). Exactly to avoid the possibility of version
skew.
In other words, I'd keep it so simple that versions don't really matter,
because the low-level driver doesn't do enough complex things that you'd
be forced to upgrade it all the time. I don't think fbdev is at all the
proper interface - I think the proper interface is something that is so
close to the hardware that the hardware _forces_ all issues, and there are
never any questions of what the low-level driver should be.
And since people still want to run X on old setups too, clearly X will
have to have the ability to have its own user-space module. That's needed
for other operating systems _anyway_, so this wouldn't obviate that.
Linus
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-27 21:32 ` Linus Torvalds
@ 2003-10-27 23:55 ` Benjamin Herrenschmidt
2003-10-28 2:13 ` Linus Torvalds
0 siblings, 1 reply; 67+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-27 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ian Romanick, David Dawes, dri-devel, fb-devel
> In other words, I'd keep it so simple that versions don't really matter,
> because the low-level driver doesn't do enough complex things that you'd
> be forced to upgrade it all the time. I don't think fbdev is at all the
> proper interface - I think the proper interface is something that is so
> close to the hardware that the hardware _forces_ all issues, and there are
> never any questions of what the low-level driver should be.
>
> And since people still want to run X on old setups too, clearly X will
> have to have the ability to have its own user-space module. That's needed
> for other operating systems _anyway_, so this wouldn't obviate that.
I see your point about fbdev not beeing the proper interface here.
But then, what would be the relationchip between that low level stuff
and fbdev ? (fbdev beeing a driver providing basically mode setting &
basic framebuffer support for client applications, fbcon beeing just
one of them here, with possibly later on some accel modules as well)
Same question goes for XFree.
Do they still just map register space and blast registers ? Or do you
expect all register accesses to go through some kind of "command pipe" ?
There are lots of tricky things to do especially at board init time
that basically require direct register access (and if possible beeing
in the kernel with irq off for subtle things like "measuring" the
board PLL, unfortunately necessary on some cards).
So the main service the "low level" module would provide would be
just basic card identification (list of PCI IDs), mapping facilities
for fb & registers, arbitration so that things like fbdev can get full
ownership (prevent ring commands) when mode switching & such, and the
actual DMA/IRQ command blasting engine (equivalent of current DRI module).
This looks like just an extension of the current DRI modules, and having
things like fbdev stack on top of them...
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-27 23:55 ` Benjamin Herrenschmidt
@ 2003-10-28 2:13 ` Linus Torvalds
2003-10-28 3:27 ` Philip Brown
2003-10-28 19:40 ` James Simmons
0 siblings, 2 replies; 67+ messages in thread
From: Linus Torvalds @ 2003-10-28 2:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Ian Romanick, David Dawes, dri-devel, fb-devel
On Tue, 28 Oct 2003, Benjamin Herrenschmidt wrote:
>
> I see your point about fbdev not beeing the proper interface here.
>
> But then, what would be the relationchip between that low level stuff
> and fbdev ?
My suggestion, as a starting point, is to really think very rudimentary at
first. A truly _minimal_ thing. Minimal partly because that just avoids
all the interface design issues ("there are none" ;), but partly because
everybody involved will have rather different goals. In particular, the
XFree86 people would have as a goal to keep the differences to a
user-space implementation minimal, so in that sense you really want to
have an abstraction that doesn't hide the hardware AT ALL.
NOTE! I'm not saying this is necessarily the best interface or a truly
great idea. This is just throwing out my thought of the day. I'm nothing
if not flexible - some people think I change my mind _too_ often ;)
So the thing should really just have
- discovery and attach/detach
- interrupt event notification (and it can't just be "an interrupt
happened" - the interrupt driver actually has to know enough to ACK the
interrupt, so that we can tell user space that an interrupt happened
without having to disable the interrupt until the event goes away)
- serialization (ie a lock) and waiting for events ("engine idle" or
"command queue less than half full")
- DMA arbitration and setup.
Most of the rest (actual IO accesses etc) can be done outside the lowlevel
crud, once you have the lock. This is also why DMA really _is_ special,
since it's asynchronous: so it can and does happen independently of the
lock. But normal synchronous programmed IO doesn't need any real help, and
there's no point in forcing that into the low-level driver. All the users
might as well do any direct IO directly.
So the low-level driver wouldn't know about palettes or cursors or any
"high-level" concepts like that. It would have a few locks to make sure
that the users that try to access the things don't stop on each other,
nothing more (maybe the locks themselves would be grouped into "palette
lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded
enough to allow it, but the point is that the low-level driver wouldn't
actually _do_ anything, it only allows others to do what they want without
stomping on each others toes).
Is this wonderful and solves all problems? Hell no. The interfaces would
be pretty ugly and specialized.
That doesn't mean that there aren't any issues at all. For example for
locking, you probably don't want just "lock" and "unlock": you'd likely
want the low-level driver to implement the "expensive lock", but do your
own cheap locks in low-level drivers. That in turn means that the
lowlevel lock needs to have a "please release the lock" callback thing.
Something that works for everybody. Which might not be all that east at
all.
> There are lots of tricky things to do especially at board init time
> that basically require direct register access (and if possible beeing
> in the kernel with irq off for subtle things like "measuring" the
> board PLL, unfortunately necessary on some cards).
This is exactly the kinds of things I would advice against very strongly.
You do _not_ want to have a common driver that knows that much about the
hardware. Because if the common driver has to know all the esoteric
details, there's no way it will get them all right. And once it gets
something wrong, people start trying to work around it and have driver
quirks and version dependencies etc.
> This looks like just an extension of the current DRI modules, and having
> things like fbdev stack on top of them...
Quite the reverse, I think. It would be a _shrink_ of the DRI modules.
Linus
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 2:13 ` Linus Torvalds
@ 2003-10-28 3:27 ` Philip Brown
2003-10-28 19:40 ` James Simmons
1 sibling, 0 replies; 67+ messages in thread
From: Philip Brown @ 2003-10-28 3:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dri-devel, fb-devel
On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote:
>..
> So the thing should really just have
> - discovery and attach/detach
> - interrupt event notification (and it can't just be "an interrupt
> happened" - the interrupt driver actually has to know enough to ACK the
> interrupt, so that we can tell user space that an interrupt happened
> without having to disable the interrupt until the event goes away)
> - serialization (ie a lock) and waiting for events ("engine idle" or
> "command queue less than half full")
> - DMA arbitration and setup.
>[....]
> So the low-level driver wouldn't know about palettes or cursors or any
> "high-level" concepts like that. It would have a few locks to make sure
> that the users that try to access the things don't stop on each other,
> nothing more (maybe the locks themselves would be grouped into "palette
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded
> enough to allow it, but the point is that the low-level driver wouldn't
> actually _do_ anything, it only allows others to do what they want without
> stomping on each others toes).
Sounds like a good idea. Simple Is Better.
Now, would that "DMA arbitration" include
"submit a chunk o dma memory for GPU processing",
or would it just allow [whatever] to map the registers, and basically say,
"I'll tell you when something completes (aka sends an interrupt)
but it's up to you to START it"
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 2:13 ` Linus Torvalds
2003-10-28 3:27 ` Philip Brown
@ 2003-10-28 19:40 ` James Simmons
2003-10-28 21:35 ` Benjamin Herrenschmidt
2003-10-28 22:54 ` Linus Torvalds
1 sibling, 2 replies; 67+ messages in thread
From: James Simmons @ 2003-10-28 19:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Benjamin Herrenschmidt, Ian Romanick, David Dawes, dri-devel, fb-devel
> > I see your point about fbdev not beeing the proper interface here.
> >
> > But then, what would be the relationchip between that low level stuff
> > and fbdev ?
>
> My suggestion, as a starting point, is to really think very rudimentary at
> first. A truly _minimal_ thing. Minimal partly because that just avoids
> all the interface design issues ("there are none" ;), but partly because
> everybody involved will have rather different goals. In particular, the
> XFree86 people would have as a goal to keep the differences to a
> user-space implementation minimal, so in that sense you really want to
> have an abstraction that doesn't hide the hardware AT ALL.
>
> NOTE! I'm not saying this is necessarily the best interface or a truly
> great idea. This is just throwing out my thought of the day. I'm nothing
> if not flexible - some people think I change my mind _too_ often ;)
>
> So the thing should really just have
> - discovery and attach/detach
> - interrupt event notification (and it can't just be "an interrupt
> happened" - the interrupt driver actually has to know enough to ACK the
> interrupt, so that we can tell user space that an interrupt happened
> without having to disable the interrupt until the event goes away)
> - serialization (ie a lock) and waiting for events ("engine idle" or
> "command queue less than half full")
> - DMA arbitration and setup.
This is good design for DMA based graphics cards. Unfortunely at present
maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers
use IO access :-( Sure we could convert as many as possible to DMA, which I was
planning to do anyways :-)
> Most of the rest (actual IO accesses etc) can be done outside the lowlevel
> crud, once you have the lock. This is also why DMA really _is_ special,
> since it's asynchronous: so it can and does happen independently of the
> lock. But normal synchronous programmed IO doesn't need any real help, and
> there's no point in forcing that into the low-level driver. All the users
> might as well do any direct IO directly.
>
> So the low-level driver wouldn't know about palettes or cursors or any
> "high-level" concepts like that. It would have a few locks to make sure
> that the users that try to access the things don't stop on each other,
> nothing more (maybe the locks themselves would be grouped into "palette
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded
> enough to allow it, but the point is that the low-level driver wouldn't
> actually _do_ anything, it only allows others to do what they want without
> stomping on each others toes).
Unfortunely most fbdev drivers set the hardware in IO access mode. Plus
some of the devices lack any kind of DMA support. In this case seperating
out the parts of the driver that program the "high level" stuff leaves
almost nothing left. Would it still be wise to seperate it out as you
suggest? Would we really gain that much doing this for the case of IO
access only graphics hardware?
> > This looks like just an extension of the current DRI modules, and having
> > things like fbdev stack on top of them...
>
> Quite the reverse, I think. It would be a _shrink_ of the DRI modules.
:-)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 19:40 ` James Simmons
@ 2003-10-28 21:35 ` Benjamin Herrenschmidt
2003-10-28 22:09 ` Jon Smirl
2003-10-28 22:54 ` Linus Torvalds
1 sibling, 1 reply; 67+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-28 21:35 UTC (permalink / raw)
To: James Simmons
Cc: Linus Torvalds, Ian Romanick, David Dawes, dri-devel, fb-devel
> Unfortunely most fbdev drivers set the hardware in IO access mode. Plus
> some of the devices lack any kind of DMA support. In this case seperating
> out the parts of the driver that program the "high level" stuff leaves
> almost nothing left. Would it still be wise to seperate it out as you
> suggest? Would we really gain that much doing this for the case of IO
> access only graphics hardware?
The problem is the same. DMA or not DMA, what we want is arbitration.
When fbdev sets up a mode, the X server mustn't blast 2D engine (either
using PIO or sending DMA commands) etc... So that "arbitration" module
will have to provide the necessary arbitration so that the 2D/3D DMA
command flow can be interrupted (if any), and/or the hw access "lock"
passed between things like fbdev/fbcon and userland clients.
Right now, even plain fbdev as it exist is racy in this regard. Nothing
prevent an accelerated printk or cursor operation to happen in the middle
of a userland initiated mode switch, potentially locking up the card. My
latest radeonfb has minimal spinlock so at least the indirect register
accesses (like PLL) are safe, but it's still broken in some way.
Unfortunately, the way fbcon currently works, the only way to deal with
those issues is by taking the console semaphore on every fbdev operations.
(Thanks to printk & blanking coming from irq). If fbcon can completely
separate update of the text/attr buffer from actual refresh of the
framebuffer, it may be possible to do something smarter.
This problem isn't really an issue we need to deal with in that proposed
"low level" driver though. It's entirely an fbdev/fbcon issue that is
caused by having fbcon active on a VT, that is by having a KDTEXT VT.
I expect that when such a console is frontmost, the HW lock will be solely
owned by fbdev/fbcon. Only a KDGRAPHICS vt shall release that HW lock,
letting userland grab it for drawing operations, fbdev taking it only when
requested to do things like mode changes or palette changes.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 21:35 ` Benjamin Herrenschmidt
@ 2003-10-28 22:09 ` Jon Smirl
2003-10-28 22:26 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 67+ messages in thread
From: Jon Smirl @ 2003-10-28 22:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt, James Simmons
Cc: Linus Torvalds, Ian Romanick, David Dawes, dri-devel, fb-devel
--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> The problem is the same. DMA or not DMA, what we want is arbitration.
>
> When fbdev sets up a mode, the X server mustn't blast 2D engine (either
> using PIO or sending DMA commands) etc... So that "arbitration" module
> will have to provide the necessary arbitration so that the 2D/3D DMA
> command flow can be interrupted (if any), and/or the hw access "lock"
> passed between things like fbdev/fbcon and userland clients.
Do we really want arbitration between multiple things (FB, X, DRI, etc) all
trying to control the video hardware at a register level? This is like writing
a multitaking system for device drivers.
Or do we want a single device driver with multiple clients?
A major complaint from the framebuffer console people is that we have to do
mode setting/EDID in the device driver so that there is a console to look at
from the first second the kernel boots. This also means we have to map the
framebuffer into kernel space (sucking up to 256MB of kernel address space).
In the 2.7 time frame is it possible to write a low level driver like Linus
proposed plus a small DSO for mode setting/EDID. Then write fbconsole as a user
space app that is loaded much eariler in the boot process than user-mode
currently starts? In other words is there a solution to having a boot time
console that doesn't involve running it in a device driver?
Another possible solution to the boot time problem would be to write a
disposable device driver. The disposable driver would set the mode/EDID and run
the console until user mode started; then self destruct.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 22:09 ` Jon Smirl
@ 2003-10-28 22:26 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 67+ messages in thread
From: Benjamin Herrenschmidt @ 2003-10-28 22:26 UTC (permalink / raw)
To: Jon Smirl
Cc: James Simmons, Linus Torvalds, Ian Romanick, David Dawes,
dri-devel, fb-devel
On Wed, 2003-10-29 at 09:09, Jon Smirl wrote:
> Do we really want arbitration between multiple things (FB, X, DRI, etc) all
> trying to control the video hardware at a register level? This is like writing
> a multitaking system for device drivers.
>
> Or do we want a single device driver with multiple clients?
Here, you are going away from Linus suggestion. While it makes sense
too, it would be a real pain to keep that single driver in sync between
the different parties, to keep backward compatibility, etc... re-read
Linus emails on this topic. I tend to agree with him here, what we want
is a small low level layer that does the strict minimum to provide
DMA/irq and arbitration.
> A major complaint from the framebuffer console people is that we have to do
> mode setting/EDID in the device driver so that there is a console to look at
> from the first second the kernel boots. This also means we have to map the
> framebuffer into kernel space (sucking up to 256MB of kernel address space).
That mode setting / EDID is done in drivers on other platforms as well,
I don't see the problem here. It's the basic "feature" provided by the
framebuffer driver, it doesn't only make sense for fbcon but also for
other framebuffer apps.
Mapping the framebuffer into kernel space isn't necessary. It's how
today's fbcon works, but it's not mandatory. In fact, if fbcon was
fully accelerated, mapping the fb would be useless.
> In the 2.7 time frame is it possible to write a low level driver like Linus
> proposed plus a small DSO for mode setting/EDID.
DSO ? Can you translate ?
> Then write fbconsole as a user
> space app that is loaded much eariler in the boot process than user-mode
> currently starts? In other words is there a solution to having a boot time
> console that doesn't involve running it in a device driver?
So we lose the ability to get early boot messages and printk at
interrupt time ? no thanks ! Looks you aren't regulary faced with the
need to debug kernel code ;)
> Another possible solution to the boot time problem would be to write a
> disposable device driver. The disposable driver would set the mode/EDID and run
> the console until user mode started; then self destruct.
fbcon can still be in the kernel. I see no point in your push to move it
down to userland, provided that it stays a clearly separate entity from the
fbdev itself, just another client.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [Dri-devel] Re: DRM and pci_driver conversion
2003-10-28 19:40 ` James Simmons
2003-10-28 21:35 ` Benjamin Herrenschmidt
@ 2003-10-28 22:54 ` Linus Torvalds
1 sibling, 0 replies; 67+ messages in thread
From: Linus Torvalds @ 2003-10-28 22:54 UTC (permalink / raw)
To: James Simmons
Cc: Benjamin Herrenschmidt, Ian Romanick, David Dawes, dri-devel, fb-devel
On Tue, 28 Oct 2003, James Simmons wrote:
>
> This is good design for DMA based graphics cards. Unfortunely at present
> maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers
> use IO access :-( Sure we could convert as many as possible to DMA, which I was
> planning to do anyways :-)
Even if you don't use DMA, you still want the discovery/enumeration and
serialization parts, which you want in the kernel.
And if the driver ends up being really small - all the better. If the card
literally doesn't even have a command buffer (ie a truly stupid entirely
synchronous IO programming model like classic VGA) then the driver won't
even need the "wait for command ring empty" kind of thing.
Now, your reaction might be that "oh, but what a wasteful thing to have a
driver for just a simple serialization and discovery". True. But on the
other hand, it's not like it would be actually wasting that much, and the
nice thing is that this kind of truly minimal driver that doesn't have to
worry about DMA etc can quite likely be shared with pretty much _all_ of
the stupid cards. So we could have just _one_ driver that covers all of
the "this card doesn't do DMA or even retrace interrupts".
So don't worry about the fact that for some hardware the driver might be
really simple. Even a simple driver is worth it if it means that we can
have a unified model for synchronizing between the different agents that
want to touch the video hardware. I think.
> Unfortunely most fbdev drivers set the hardware in IO access mode. Plus
> some of the devices lack any kind of DMA support.
I don't think this is "unfortunately" at all. Quite the reverse. If the
card doesn't use/need DMA, that just makes for a simple low-level driver.
The reason I mentioned DMA arbitration as a major thing the driver would
do is not because I think that every driver _has_ to have DMA. I mentioned
it specially because DMA is kind of special in that it is done
asynchronously and thus needs an abitration model that is above-and-beyond
just a normal "lock this card" thing.
Linus
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
^ permalink raw reply [flat|nested] 67+ messages in thread