On Fri, 10 Sep 2004 17:00:33 +0100, Alan Cox <[email protected]> wrote:
> > > > On Gwe, 2004-09-10 at 17:37, Jon Smirl wrote:
> > > > The plan is to add fbdev capability to the DRM so that you won't need
> > > > to run vesafb. DRM will give you the features found in VESA fb instead
> > > > of you needing to load it separately.
> > > >
> > > Your personal plan.
> >
> > I'm writing code to fix the conflicts between vesafb, fbdev, DRM and
> > XAA and you're not. Either provide your own code for sorting out the
> > resource conflicts or keep your opinions to yourself.
>
> You can write all the code you like its still "your personal plan". I
> have seen nothing but rejection of it by the kernel community.
My "personal plan" has been posted for comment to all relevant email
lists -- xorg, fbdev, dri, and lkml. All feedback that was received
was addressed and incorporated. Various aspects of the plan were
talked about at three OLS sessions. Everyone has been invited to
participate. I even went through significant effort to encourage
fbdev developers to come to OLS and discuss the changes.
Plan as orginally posted to lkml:
http://lkml.org/lkml/2004/8/2/111
If the kernel community is going to reject this plan please let me
know now so that I won't waste a year of my life writing the code for
it. If Linux wants to stay with a 1980's desktop that's fine; at least
Microsoft and Apple are innovating.
--
Jon Smirl
[email protected]
On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
> My "personal plan" has been posted for comment to all relevant email
> lists -- xorg, fbdev, dri, and lkml. All feedback that was received
> was addressed and incorporated. Various aspects of the plan were
Addressed and eliminated would be closer. The BSD folks don't want GPL
frame buffer code in there kernel, nobody needs a single nasty splat
where DRI and fbdev got hammered into one block of code by someone with
a glue gun.
> Plan as orginally posted to lkml:
> http://lkml.org/lkml/2004/8/2/111
None of which is about nailing all the code together. You just don't
need to do that kind of stuff, and it'll make it much harder to
maintain.
Now, think about what happens if you register a pci handler for
everything which is "Video" class (or VIDEO/VGA). Your one mini module
now claims every video object in the kernel with a couple of exceptions
you can hand list.
vga_class.c now owns all the video devices. It can keep a global list
and a sorted by vga router list as well as letting frame buffer drivers
and other code add heads of a device lists.
Add register/unregister functions in the same format to allow DRI and FB
(and any future layers) to find cards and you don't need to glue stuff
together at all. You can load dri, you can load fb drivers, you can load
both. You also require minimal kernel changes to the drivers.
That is what I keep telling you, that is what I've been fiddling with
but keep getting distracted from by immediate locking and other kernel
catastrophes.
===
If the kernel community is going to reject this plan please let me
know now so that I won't waste a year of my life writing the code for
it. If Linux wants to stay with a 1980's desktop that's fine; at least
Microsoft and Apple are innovating.
I see you've been taking lessons from Hans Reiser.
Alan
PS: Don't get me wrong - we have to address the main points on that list
(the ones on the list not in your head). The last thing I want to see is
another person march off into the distance with a framebuffer agenda and
a lack of understanding about the importance of getting
from where we are now to where we want to be without breaking anything
major and without leaving everyone else behind or going a different
way.
Thats happened at least twice before in the console world because people
didn't get it. Kgi is one case, ruby is another.
Alan
On Fri, 10 Sep 2004 18:04:19 +0100, Alan Cox <[email protected]> wrote:
> On Gwe, 2004-09-10 at 18:22, Jon Smirl wrote:
> > My "personal plan" has been posted for comment to all relevant email
> > lists -- xorg, fbdev, dri, and lkml. All feedback that was received
> > was addressed and incorporated. Various aspects of the plan were
>
> Addressed and eliminated would be closer. The BSD folks don't want GPL
> frame buffer code in there kernel, nobody needs a single nasty splat
> where DRI and fbdev got hammered into one block of code by someone with
> a glue gun.
This has been discussed and we see the need to keep BSD's version of
DRM isolated from the Linux one. There are several different schemes
that can be used to achieve this but there is agreement that GPL code
from Linux should not be mixed into the BSD code base.
For example DRM can link into the existing fbdev cfb* modules without
changing them. These modules are needed to implement OOPs display from
X. Another example is the radeon GPL I2C DDC driver. This will start
off as an isolated Linux feature. If a BSD coder wants to reimplement
this existing code GPL with a BSD license it can be added to the BSD
driver.
>
> > Plan as orginally posted to lkml:
> > http://lkml.org/lkml/2004/8/2/111
>
> None of which is about nailing all the code together. You just don't
> need to do that kind of stuff, and it'll make it much harder to
> maintain.
>
> Now, think about what happens if you register a pci handler for
> everything which is "Video" class (or VIDEO/VGA). Your one mini module
> now claims every video object in the kernel with a couple of exceptions
> you can hand list.
>
> vga_class.c now owns all the video devices. It can keep a global list
> and a sorted by vga router list as well as letting frame buffer drivers
> and other code add heads of a device lists.
>
> Add register/unregister functions in the same format to allow DRI and FB
> (and any future layers) to find cards and you don't need to glue stuff
> together at all. You can load dri, you can load fb drivers, you can load
> both. You also require minimal kernel changes to the drivers.
You are focusing on the resource claiming problem. That is an easy
problem to solve, it's also not the one that is causing the hard
problems.
Hard problems:
1) Video cards have more than one head, fbdev can only set the mode on
one of them.
2) Video cards with more than one display buffer need memory
management, fbdev has none. OpenGL needs complex memory management.
3) Simultaneous users on two heads, fbdev cannot put the chip into 2D
mode while the other head is being used in 3D mode. Both heads have to
stay in 3D mode.
4) Conflicting use and programming of the 3D mode acceleration
registers between accelerated fbdev drivers and DRM
5) Support for multiple video cards - not addressed in fbdev.
6) Device driver multi-tasking. The concept that one device driver
should be suspended and another one allowed to take over the hardware
on a key stroke command. This completely violates normal OS rules of
one driver per device. If video can do it, I want to do it for the
disk and net subsystems too.
7) Building a bunch of cooperative interfaces between two groups of
developers that ignore each other.
I have to stick by a very basic rule of operating systems - one device
driver per device. The driver can have modules but these modules have
to make coordinated use of the hardware. Building a base layer for
fbdev and DRM that coordinates resource reservations does nothing to
address the above issues if everyone continues to do what they please
in the modules.
If you look at the recent changes to DRM you will notice that I am
building a base layer that will continue to work during the transition
period. Code for accessing video ROMs is finished and should be in mm
soon. I'm in the middle of writing a VGA device driver that properly
does bridge chip routing. When it's finished we'll be able to reset
secondary cards. Once the reset program is finished the next step is
to alter DRM so that it can support take_over_console().
--
Jon Smirl
[email protected]
>
> You are focusing on the resource claiming problem. That is an easy
> problem to solve, it's also not the one that is causing the hard
> problems.
I have to agree with Jon, nobody has addressed any of the issues he raises
except the one that is quite simple to solve, resource sharing is easy,
I think people are stuck in a graphics card having separate 2d/3d paths
and never the twain need meet, well that doesn't work, the 2d/3d split is
only in your mind, a graphics card is a single device, hence should only
one device driver, fbdev is not a complete driver, for all the reasons JOn
mentions (dualhead being a major one), the DRM is not a complete driver as
it ignores the basic VGA parts of the chip and relies on X or fb to set
them up..
> on a key stroke command. This completely violates normal OS rules of
> one driver per device. If video can do it, I want to do it for the
> disk and net subsystems too.
If the kernel developers can address this point I would be most
interested, in fact I don't want to hear any more about sharing lowlevel
VGA device drivers until someone addresses why it is acceptable to have
two separate driver driving the same hardware for video and not for
anything else.. (remembering graphics cards are not-multifunction cards -
like Christoph used as an example before - 2d/3d are not separate
functions...)...
Also I don't think what Jon has in mind is going to be truly possible and
IMHO an efficient flexible graphics card memory management system is
something worthy of multiple PhDs (maybe I'll go back to college), Ians
work is going to exist mainly in userspace using the DRM for paging things
and locking, I think the only way we can really do this is with a simple
fb memory manager in the kernel that the userspace one overrides and then
tells the fb drivers the new settings - and the fb drivers use those
settings until told otherwise..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the same hardware for video and not for
> anything else.. (remembering graphics cards are not-multifunction cards -
> like Christoph used as an example before - 2d/3d are not separate
> functions...)...
We've addressed this before. Zillions of drivers provide multiple
functions to multiple higher level subsystems. They don't all have to
be compiled together to make it work.
2D and 3D _are_ to most intents and purposes different functions. They
are as different as IDE CD and IDE disk if not more so.
> something worthy of multiple PhDs (maybe I'll go back to college), Ians
> work is going to exist mainly in userspace using the DRM for paging things
> and locking, I think the only way we can really do this is with a simple
> fb memory manager in the kernel that the userspace one overrides and then
> tells the fb drivers the new settings - and the fb drivers use those
> settings until told otherwise..
The memory manager is a later problem. Yes you need minimal memory
management in kernel but you have to put the pieces together in a sane
way *first*. Having a vga class device is easy. It fixes up your
multiple pci device registration problem, it allows DRI/fbdev
co-existance, it fixes hotplugging. It's about using the kernel tools we
already have and implementing it the way the kernel wants to think. If
you fight the kernel you get a mess, if you move with it then it ends up
where you want it. Kind of like Aikido source management.
The basics I have provide (well they crash but they will provide) the
equivalent of pci_register_* for video and DRI modules. Notifiers for
use between the two and an ability to find one from the other.
Once you have that then you can begin plugging in crap like memory
managers for those cases you need it kernel side.
Alan
On Fri, 10 Sep 2004 23:19:42 +0100 (IST), Dave Airlie <[email protected]> wrote:
> Also I don't think what Jon has in mind is going to be truly possible and
> IMHO an efficient flexible graphics card memory management system is
> something worthy of multiple PhDs (maybe I'll go back to college), Ians
> work is going to exist mainly in userspace using the DRM for paging things
> and locking, I think the only way we can really do this is with a simple
> fb memory manager in the kernel that the userspace one overrides and then
> tells the fb drivers the new settings - and the fb drivers use those
> settings until told otherwise..
I'm counting on Ian to provide the memory management code. I haven't
even looked at it very much. The point is simply that we have to have
something, you just can't support multiple heads without minimal
memory management and fbdev doesn't currently have any memory
management. Since the plan is for a mode setting command to take a
path unto user space via hotplug it may be possible for all memory
management code to exist in user space. The basic point is that the
memory management code must be unified.
--
Jon Smirl
[email protected]
On Sad, 2004-09-11 at 00:10, Jon Smirl wrote:
> I'm counting on Ian to provide the memory management code. I haven't
> even looked at it very much. The point is simply that we have to have
> something, you just can't support multiple heads without minimal
> memory management and fbdev doesn't currently have any memory
> management. Since the plan is for a mode setting command to take a
> path unto user space via hotplug it may be possible for all memory
> management code to exist in user space. The basic point is that the
> memory management code must be unified.
DRI's memory allocator needs are very different to the others. That
probably means the kernel API should be very simple and push most of the
allocation to user space for rendering work. You want
"give me 4Mb" in kernel , but you don't want allocation for textures in
kernel (just profile the via driver).
fbdev does btw have memory management, quite a bit of it for some
multihead cards.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.
stop saying this, it isn't true and hasn't been for years, for the mach64
type cards I'd agree, for something even like the i810 this isn't
true, most cards have two paths (at least), an unaccelerated 2D path via
programmed registers, and an accelerated path via some DMA mechanism, this
isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
acceleration and you have to use it for all 3d acceleration normally,
Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
wrong...X/DRM at least lock each other out, but the fb just tramps in
wearing its size nines.. so in summary the 2D/3D split exists in peoples
minds (graphics cards designers excepted...)
> multiple pci device registration problem, it allows DRI/fbdev
> co-existance, it fixes hotplugging. It's about using the kernel tools we
> already have and implementing it the way the kernel wants to think. If
> you fight the kernel you get a mess, if you move with it then it ends up
> where you want it. Kind of like Aikido source management.
I'm with this, I want to see this stuff stay working on the way, I think
doing this might be a good step on the way, and it shouldn't break
anything too badly, I was going to start hacking something up myself but
the real world job just kicked me to get something done :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
Alan,
I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
>> If the kernel developers can address this point I would be most
>> interested, in fact I don't want to hear any more about sharing lowlevel
>> VGA device drivers until someone addresses why it is acceptable to have
>> two separate driver driving the same hardware for video and not for
>> anything else.. (remembering graphics cards are not-multifunction cards -
>> like Christoph used as an example before - 2d/3d are not separate
>> functions...)...
>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.
Functions - yes, but they become such only at a higher level. 3d for
example does not really exist in kernel in any form.
I would like to see unified fb (or the hardware-specific part of fb) and
drm for one simple reason that I think you mentioned:
One driver per device. I.e. one driver per *physical* device.
Lastly, one point that you appear to have missed: DRM does DMA transfers
(among everything else). FB sets video modes - i.e. messes with PLL.
The problem is that there are configurations where messing with PLL while
a DMA trasfer is active will lock up PCI (or AGP) bus hard.
For example, a video decoder can be clocked off pixel clock for video pass
through mode. If we trasfer video data to main RAM at the same time and
FB gets a command instructing it to change resolution there would be a
hard lockup.
best
Vladimir Dergachev
>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.
So the IDE-CD driver and IDE-disk drivers both program registers on the
IDE controller directly.. oh no the ide driver seems to do that.. this is
FUD, a graphics card is a device, singular one device, it requires one
device driver, the device driver should provide control over the device
and be the only one to program its registers.. it can provide services to
who ever wants services, be it a 2D console driver or a 3D client or a 4D
super-time-travelling application,
I can't write a user space IDE driver and still expect the kernel one to
be happy, I can't write a second IDE driver for a chipset for formatting
disks and expect the normal kernel driver to stay working with it, why do
people think graphics driver are meant to be different..
Alan, I agree with how you want to proceed with this, and keep things
stable, but anything short of a single card-specific driver looking after
the registers and DMA queueing and locking is going to have deficiencies
and the DRM has a better basis than the fb drivers,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Sat, 2004-09-11 at 01:50 +0100, Dave Airlie wrote:
>
> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> [...]
You're probably right, but it still doesn't follow that this driver must
include all the fbdev and DRM code as well. Both fbdev and the DRM could
use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
> You're probably right, but it still doesn't follow that this driver must
> include all the fbdev and DRM code as well. Both fbdev and the DRM could
> use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
>
I think your wrong, look at drivers/video/aty/radeon* and tell me what in
there is capable of being abstracted from the hardware, every file access
lowlevel registers for something or other, be it mode setting or I2C, now
accessing lowlevels while the CP is running on a radeon is a one way
express to the land of the lockups... (think mode setting a second head,
while a 3d app is running on the first head...), the lowlevel driver can
provide a DRM and FB interface to fbcon and 3d stuff, but the lowlevel
driver needs all the code to do both...
The other thing I think some people are confusing is 2.4 fbdev and 2.6...
there is no console support in 2.6 fbdev drivers, it is all in the fbcon
stuff, so the fbdev drivers are only doing 2d mode setting and monitor
detection, some points I've considered are:
1. It doesn't matter where the code lives, fbdev/DRM need to start talking
about things
2. A generic interface between the two is probably going to be impossible,
graphics card interfaces aren't based on a standard like IDE (stop using
IDE for comparisons, it isn't the same IDE is a standard, and is designed
for things like cd drivers and hard drives, graphics card have no standard
interfaces, just because your pet card has a nice 2D/3D split it doesn't
mean that all do, if someone provides a better analogy feel free to use it
but can we all agree to drop the IDE comparisons now...)
I'm interested in seeing what Alan comes up with, even in a non-working
form .. I much prefer the evolution of these things than complete new
solutions... but I also think linking the fb and drm code together will
remove alot of the headaches and result in a more maintainable system
longterm, even if shortterm there are some ugly hacks..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:
> >
> > You're probably right, but it still doesn't follow that this driver must
> > include all the fbdev and DRM code as well. Both fbdev and the DRM could
> > use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.
>
> I think your wrong, look at drivers/video/aty/radeon* and tell me what in
> there is capable of being abstracted from the hardware, every file access
> lowlevel registers for something or other, be it mode setting or I2C,
I'm not talking about abstracting much of anything, just moving
(arbitration of) actual hardware access to a common lowlevel driver. The
things you mentioned but snipped above, basically.
> now accessing lowlevels while the CP is running on a radeon is a one way
> express to the land of the lockups...
No need to tell me that...
> (think mode setting a second head, while a 3d app is running on the first
> head...), the lowlevel driver can provide a DRM and FB interface to fbcon
> and 3d stuff, but the lowlevel driver needs all the code to do both...
I still haven't seen a complete logical chain leading to that
conclusion.
The lowlevel driver could provide all the necessary arbitration and
safety measures to prevent the two from stepping on each other's toes.
> The other thing I think some people are confusing is 2.4 fbdev and 2.6...
Again, not me.
> there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> detection, [...]
Exactly. Why not leave it like that, and the DRM taking care of memory
management and rendering?
> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things
Agreed.
> 2. A generic interface between the two is probably going to be impossible,
Probably true, I'm not talking about a generic interface (although some
parts might be generic, just like the DRM userspace interface).
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
> I still haven't seen a complete logical chain leading to that
> conclusion.
>
> The lowlevel driver could provide all the necessary arbitration and
> safety measures to prevent the two from stepping on each other's toes.
>
The thing is I know of no way to provide arbitration in such a way as to
permit other code to access PLL registers directly.
One way or the other you will have to add "please set mode X" function to
DRM and then the point of having a separate file for fb-con related 2d
only is moot.
Additional argument for this is that DRM *NEEDS* to know about mode
setting so that when it detects an engine lockup it is able to restore the
card to a sane state without FB driver.
Right now there are two places where engine reset is handled: DRM driver
(where we reset the chip and leave it as is, with mode all screwed up) and
in Xserver (where we set the mode, but I have never seen this code path
triggered).
Thus at the very least you would want to mandate the availability of mode
setting part of FB when DRM is loaded - and they you can just as well link
the relevant code together.
best
Vladimir Dergachev
On Sat, 11 Sep 2004, Dave Airlie wrote:
> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)
Who tramps on who actually depends on your point of view... ;-)
First we had fbdev in the kernel (and some X played nice with it), then we also
got DRM...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Alan Cox wrote:
> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
>
>>If the kernel developers can address this point I would be most
>>interested, in fact I don't want to hear any more about sharing lowlevel
>>VGA device drivers until someone addresses why it is acceptable to have
>>two separate driver driving the same hardware for video and not for
>>anything else.. (remembering graphics cards are not-multifunction cards -
>>like Christoph used as an example before - 2d/3d are not separate
>>functions...)...
>
>
> We've addressed this before. Zillions of drivers provide multiple
> functions to multiple higher level subsystems. They don't all have to
> be compiled together to make it work.
>
> 2D and 3D _are_ to most intents and purposes different functions. They
> are as different as IDE CD and IDE disk if not more so.
This depends to a great deal what you mean by 2D. The idea of a blitter or
dedicated 2D acceleration engine is rapidly becoming history. Several cards
currently ship without one, and I expect to see that become the norm in future.
But if you define 2D to include things like mode setting, etc, and not any
acceleration, then the split sortof works.
It might be better to call the components different names, like
"configuration" and "acceleration".
Keith
Dave Airlie wrote:
>>2D and 3D _are_ to most intents and purposes different functions. They
>>are as different as IDE CD and IDE disk if not more so.
>
>
> stop saying this, it isn't true and hasn't been for years, for the mach64
> type cards I'd agree, for something even like the i810 this isn't
> true, most cards have two paths (at least), an unaccelerated 2D path via
> programmed registers, and an accelerated path via some DMA mechanism, this
> isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
> acceleration and you have to use it for all 3d acceleration normally,
>
> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)
Yes, it is closest to the truth to believe there is one acceleration engine
that does all drawing, and this should ideally have a single owner.
But that doesn't mean that mode-setting, etc, has to be moved into the DRM -
for my money that stuff can stay where it is, provided there are some sensible
interfaces put in place between the two components.
Keith
Vladimir Dergachev wrote:
>
> Alan,
> I would like to disagree with you.
>
> On Fri, 10 Sep 2004, Alan Cox wrote:
>
>> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
>>
>>> If the kernel developers can address this point I would be most
>>> interested, in fact I don't want to hear any more about sharing lowlevel
>>> VGA device drivers until someone addresses why it is acceptable to have
>>> two separate driver driving the same hardware for video and not for
>>> anything else.. (remembering graphics cards are not-multifunction
>>> cards -
>>> like Christoph used as an example before - 2d/3d are not separate
>>> functions...)...
>>
>>
>> We've addressed this before. Zillions of drivers provide multiple
>> functions to multiple higher level subsystems. They don't all have to
>> be compiled together to make it work.
>>
>> 2D and 3D _are_ to most intents and purposes different functions. They
>> are as different as IDE CD and IDE disk if not more so.
>
>
> Functions - yes, but they become such only at a higher level. 3d for
> example does not really exist in kernel in any form.
>
> I would like to see unified fb (or the hardware-specific part of fb) and
> drm for one simple reason that I think you mentioned:
>
> One driver per device. I.e. one driver per *physical* device.
>
> Lastly, one point that you appear to have missed: DRM does DMA transfers
> (among everything else). FB sets video modes - i.e. messes with PLL.
> The problem is that there are configurations where messing with PLL
> while a DMA trasfer is active will lock up PCI (or AGP) bus hard.
>
> For example, a video decoder can be clocked off pixel clock for video
> pass through mode. If we trasfer video data to main RAM at the same time
> and
> FB gets a command instructing it to change resolution there would be a
> hard lockup.
I can see this being the case, but why can't fb just using existing drm
interfaces to achieve device quiescence before touching the PLL's?
Keith
On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> detection, some points I've considered are:
Correct. fbdev is almost completely separate from fbcon. And you can
actually rip out fbdev and place it anywhere you want. As long as fbcon has
access to a pointer to framebuffer memory, and the characteristics of the
display such as depth, pitch, etc, then the framebuffer console will work.
Throw in a few functions, such as for buffer flipping, and fbcon will be happy.
Hardware acceleration is entirely optional, and most drivers except for a few
(such as vga16fb or amiga) can use the cfb_* drawing functions.
There's also a recent change in the latest bk tree that changes the
intialization order of the framebuffer system. Previously, fbcon triggers
fbmem, then fbmem triggers each individual drivers. This method requires
that a working fbdev is present, otherwise fbcon will fail (although you can
do a con2fbmap later, or modprobe a driver). With the change, the
order is reversed, driver->fbmem->fbcon. This change is probably
significant because fbcon can wait until an active framebuffer activates.
In theory, one can have a process (kernel or userland) change the video
mode, then provide the in-kernel driver with the necessary information
about the layout of the framebuffer. When this in-kernel driver gets the
necessary information, it can trigger fbcon. This in-kernel driver need not
know anything about the hardware (unless 2D acceleration is needed).
Tony
--- Keith Whitwell <[email protected]> wrote:
> Vladimir Dergachev wrote:
> >
> > Alan,
> > I would like to disagree with you.
> >
> > On Fri, 10 Sep 2004, Alan Cox wrote:
> >
> >> On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:
> >>
> >>> If the kernel developers can address this point I would be most
> >>> interested, in fact I don't want to hear any more about sharing
> lowlevel
> >>> VGA device drivers until someone addresses why it is acceptable to
> have
> >>> two separate driver driving the same hardware for video and not for
> >>> anything else.. (remembering graphics cards are not-multifunction
> >>> cards -
> >>> like Christoph used as an example before - 2d/3d are not separate
> >>> functions...)...
> >>
> >>
> >> We've addressed this before. Zillions of drivers provide multiple
> >> functions to multiple higher level subsystems. They don't all have to
> >> be compiled together to make it work.
> >>
> >> 2D and 3D _are_ to most intents and purposes different functions.
> They
> >> are as different as IDE CD and IDE disk if not more so.
> >
> >
> > Functions - yes, but they become such only at a higher level. 3d for
> > example does not really exist in kernel in any form.
> >
> > I would like to see unified fb (or the hardware-specific part of fb)
> and
> > drm for one simple reason that I think you mentioned:
> >
> > One driver per device. I.e. one driver per *physical* device.
> >
> > Lastly, one point that you appear to have missed: DRM does DMA
> transfers
> > (among everything else). FB sets video modes - i.e. messes with PLL.
> > The problem is that there are configurations where messing with PLL
> > while a DMA trasfer is active will lock up PCI (or AGP) bus hard.
> >
> > For example, a video decoder can be clocked off pixel clock for video
> > pass through mode. If we trasfer video data to main RAM at the same
> time
> > and
> > FB gets a command instructing it to change resolution there would be a
>
> > hard lockup.
>
> I can see this being the case, but why can't fb just using existing drm
> interfaces to achieve device quiescence before touching the PLL's?
>
I can see the problem here...
This happens with old(current) gatos and fglrx. Where DRI sets up some
state in the card and then dosen't clear it after being unloaded. This
leaves the card in an unknowen state that gatos or fglrx dosen't know any
thing about.
What will happen is that when the FB or DRM turns on a new feature the
other driver MAY need to be aware of the change. This would imply that we
must now version as if there where an ABI. The REAL problem is that the
ABI is all in hardware! The bottom line is that nether of these drivers
SHOULD assume that the other won't change the way it uses the card, thus
forcing a bianary compatability issue.
> Keith
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
> If the kernel developers can address this point I would be most
> interested, in fact I don't want to hear any more about sharing lowlevel
> VGA device drivers until someone addresses why it is acceptable to have
> two separate driver driving the same hardware for video and not for
> anything else.. (remembering graphics cards are not-multifunction cards -
> like Christoph used as an example before - 2d/3d are not separate
> functions...)...
Well, Alan's proposal gets things back into a working shape with both
fbdev and get additional benefits like hotplug and autloading without
a major revamp of everything. The major rework will have to happen sooner
or later anyway, but by fixing the obvious problems we face now first it
can be done in small pieces and with far less pressure.
--- Christoph Hellwig <[email protected]> wrote:
> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing
> lowlevel
> > VGA device drivers until someone addresses why it is acceptable to
> have
> > two separate driver driving the same hardware for video and not for
> > anything else.. (remembering graphics cards are not-multifunction
> cards -
> > like Christoph used as an example before - 2d/3d are not separate
> > functions...)...
>
> Well, Alan's proposal gets things back into a working shape with both
> fbdev and get additional benefits like hotplug and autloading without
> a major revamp of everything. The major rework will have to happen
> sooner
> or later anyway, but by fixing the obvious problems we face now first it
> can be done in small pieces and with far less pressure.
>
Not to step on toes, but... From what I can tell the idea is to add code
into FB that calles functions in the DRM and vice vers. This would seam
to add another ABI. Unless the code gets linked into one module, this
idea has been flamed and killed already.
I would be willing to bet that if some one did this, into one module, it
would be exepted by all. However I don't see why we can't add multi-head
support, posibly at the same time? -Since Joe seams so willing to do this,
why not let him.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
On Sad, 2004-09-11 at 00:24, Dave Airlie wrote:
> stop saying this, it isn't true and hasn't been for years, for the mach64
> type cards I'd agree, for something even like the i810 this isn't
Its true. Its still true whether you demand people stop saying it or
not.
> true, most cards have two paths (at least), an unaccelerated 2D path via
> programmed registers, and an accelerated path via some DMA mechanism, this
> isn't a 2d/3d split, you have to use the DMA mechanism for doing some 2d
> acceleration and you have to use it for all 3d acceleration normally,
And a CD ROM is a round thing with removable optical media, while a hard
disk has a different command set and is magnetic. They are juat as
different. Its simple a matter of correct architecture.
> Lots of X DDX drivers use the accelerator for 2d stuff, some fbs use it
> for accelerating scrolling, the DRM uses it, this is wrong wrong wrong
> wrong...X/DRM at least lock each other out, but the fb just tramps in
> wearing its size nines.. so in summary the 2D/3D split exists in peoples
> minds (graphics cards designers excepted...)
Thats a different issue. IDE has to stop the CD and disk drivers from
stomping on each other over a shared bus. This is the problem of them
knowing each other exist and interacting. This is the point you need to
be able to find DRI from FB and vice versa. The point they need to know
about each other being loaded.
Multiple registrations on the same object is exactly what the class code
in the kernel is for.
You end up with a VGA class driver that knows all the video devices.
That has the usual match/install functions to allow the frame buffer to
attach, but can also have other sets for attaching different client
classes.
On Sad, 2004-09-11 at 01:47, Vladimir Dergachev wrote:
> One driver per device. I.e. one driver per *physical* device.
This is a religion the kernel doesn't follow. Its a pointless
religion
> Lastly, one point that you appear to have missed: DRM does DMA transfers
> (among everything else). FB sets video modes - i.e. messes with PLL.
> The problem is that there are configurations where messing with PLL while
> a DMA trasfer is active will lock up PCI (or AGP) bus hard.
Yes its a co-ordination issue. If the IDE disk writes to the bus the
same moment as the IDE CD shit also happens.
> For example, a video decoder can be clocked off pixel clock for video pass
> through mode. If we trasfer video data to main RAM at the same time and
> FB gets a command instructing it to change resolution there would be a
> hard lockup.
Gosh, just like if the IDE disk driver changes the bus clocking during
an IDE CD transfer.
You need co-ordination not some horrible glue it all together and pray
hack. Thats always going to be true, and since you can do it without
glueing it all together you might get somewhere by keeping them apart,
otherwise I see no future. Most DRI users don't want FB, most FB users
don't care about DRI or want to control the DRI from the fb side.
Alan
On Sad, 2004-09-11 at 01:50, Dave Airlie wrote:
> So the IDE-CD driver and IDE-disk drivers both program registers on the
> IDE controller directly.. oh no the ide driver seems to do that.. this is
> FUD,
Its a shame the DRI people having nothing better to do than tell folks
to shut up or mutter FUD about things they don't grasp. You've almost
got the point by now at least.
The IDE CD and IDE disk drivers do both write to registers on the IDE
controller directly - often the same registers. The reason it doesn't
end up in a nasty heap is because the core IDE code does co-ordination.
Two drivers, independant drivers, an access protocol an the ability for
some entity to co-ordinate them and lo - it all works.
> a graphics card is a device, singular one device, it requires one
> device driver,
That appears to be the pet religion but repeating bullshit doesn't make
it true.
> I can't write a user space IDE driver and still expect the kernel one to
> be happy, I can't write a second IDE driver for a chipset for formatting
> disks and expect the normal kernel driver to stay working with it, why do
> people think graphics driver are meant to be different..
Because they are not different, and you can write such a formatting
driver providing it follows the IDE access protocols in the core code.
You won't have to modify existing IDE drivers either. It works because
the co-ordination layer is there.
> Alan, I agree with how you want to proceed with this, and keep things
> stable, but anything short of a single card-specific driver looking after
> the registers and DMA queueing and locking is going to have deficiencies
> and the DRM has a better basis than the fb drivers,
"I want to own it, mine mine". Pathetic really isn't it. The FB writers
I've no doubt think they should own it and their code is better too.
They also support a lot more hardware than you do of course, and on
platforms that DRI doesn't support.
What is actually so hard about driver code that instead looks like
my_fb_attach_notify(struct vga_dev *dev, int type)
{
if(type == TYPE_DRI)
{
me->fb_ops = &dri_ops;
my_fb_dri_init(dev);
return 0;
}
if(type == TYPE_OVERLAY && dev->rev < 0xC4) /* Errata */
return -EINVAL; /* Refuse overlays in fb mode */
}
or
down(&dev->lock);
vga_quiesce_all_drivers(dev);
do nasty non parallel stuff
up(&dev->lock);
This is essentially what the IDE layer does, although its closer to
queue_this_function_and_args_to_list(dev, callback, args);
if(!doing_stuff);
begin_queue_run(dev);
Either model works
On Sad, 2004-09-11 at 06:19, Dave Airlie wrote:
> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking
> about things
It matters immensely what the divison is because people talking doesn't
scale ..
> I'm interested in seeing what Alan comes up with, even in a non-working
> form .. I much prefer the evolution of these things than complete new
> solutions... but I also think linking the fb and drm code together will
> remove alot of the headaches and result in a more maintainable system
> longterm, even if shortterm there are some ugly hacks..
What I'm trying to end up with is this
drv.type = TYPE_FB0; /* Head 0 */
/* Rest much like PCI */
vga_register_driver(&drv)
drv.type = TYPE_DRI;
vga_register_driver(&drv)
all working like the PCI API, so you get add/remove notifications, you
also don't need to modify the video and DRI drivers much. Unlike the
pci_register it allows multiple claims for each device (one memory
manager, one dri driver, up to four "heads" for now - multihead needs
more pondering perhaps)
Each of these gets notified when the others are added/removed and can
veto such an add or remove. They can also provide whatever methods it
turns out are appropriate to each other for co-ordination.
For example I can see the radeon DRM driver providing
->queue_commands()
->quiesce()
to the 2D driver. And the 2D driver providing
->define_fb_layout() for DRI to provide to X
That way it is only these calls between drivers you and the fb authors
have to argue about the functionality and interfaces between. (eg who
saves registers, which registers)
Alan
>>>> anything else.. (remembering graphics cards are not-multifunction cards -
>>>> like Christoph used as an example before - 2d/3d are not separate
>>>> functions...)...
>>>
>>>
>>> We've addressed this before. Zillions of drivers provide multiple
>>> functions to multiple higher level subsystems. They don't all have to
>>> be compiled together to make it work.
>>>
>>> 2D and 3D _are_ to most intents and purposes different functions. They
>>> are as different as IDE CD and IDE disk if not more so.
>>
>>
>> Functions - yes, but they become such only at a higher level. 3d for
>> example does not really exist in kernel in any form.
>>
>> I would like to see unified fb (or the hardware-specific part of fb) and
>> drm for one simple reason that I think you mentioned:
>>
>> One driver per device. I.e. one driver per *physical* device.
>>
>> Lastly, one point that you appear to have missed: DRM does DMA transfers
>> (among everything else). FB sets video modes - i.e. messes with PLL.
>> The problem is that there are configurations where messing with PLL while a
>> DMA trasfer is active will lock up PCI (or AGP) bus hard.
>>
>> For example, a video decoder can be clocked off pixel clock for video pass
>> through mode. If we trasfer video data to main RAM at the same time and
>> FB gets a command instructing it to change resolution there would be a hard
>> lockup.
>
> I can see this being the case, but why can't fb just using existing drm
> interfaces to achieve device quiescence before touching the PLL's?
Video decoder is not part of 3d engine. In fact if we are not transferring
data via DMA into system RAM the video decoder will be running
continuously and none of currently examined for quiescence flags would
show it.
To do all this properly there should be a piece of code that knows all
about currrent state of the card - which clocks are connected to what,
which transfers are running and which parts of the engine are busy.
Btw, it would also be nice if that code received interrupts that can occur
when user hotplugs monitors.
best
Vladimir Dergachev
On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote:
> The thing is I know of no way to provide arbitration in such a way as to
> permit other code to access PLL registers directly.
This arises solely because the DRM and framebuffer drivers cannot find
each other and have no shared structures. The moment you have that it
becomes
down(&dev->foo->pll_lock);
> Thus at the very least you would want to mandate the availability of mode
> setting part of FB when DRM is loaded - and they you can just as well link
> the relevant code together.
You are making a generic assumption for a single card specific problem
in a specific situation. That leads to bad decisions for embedded. It
does argue for mode setting and fb to be separate too.
(Remember for most embedded devices mode setting code is trivial)
On Sad, 2004-09-11 at 10:20, Antonino A. Daplas wrote:
> In theory, one can have a process (kernel or userland) change the video
> mode, then provide the in-kernel driver with the necessary information
> about the layout of the framebuffer. When this in-kernel driver gets the
> necessary information, it can trigger fbcon. This in-kernel driver need not
> know anything about the hardware (unless 2D acceleration is needed).
Thats great because one of the things X wants to tell DRI to tell the
kernel eventually is "by the way the area visible is laid out like this
shoudl you want to panic on it".
(Jon wants to move the mode setting out of X eventually and that follows
the same line of requirement nicely).
>
>> Thus at the very least you would want to mandate the availability of mode
>> setting part of FB when DRM is loaded - and they you can just as well link
>> the relevant code together.
>
> You are making a generic assumption for a single card specific problem
> in a specific situation. That leads to bad decisions for embedded. It
> does argue for mode setting and fb to be separate too.
>
> (Remember for most embedded devices mode setting code is trivial)
>
Alan,
My point was that you would want to have DRM working on Radeon cards,
right ? And there are complexities of current Radeon hardware that one
would have to deal with, no matter how simple it might be to do the same
thing for embedded.
Lastly, I am not saying you have to put all the code in the same file.
All I am saying we can mandate that all Radeon HW specific code is linked
in one module - and this would make things easier for developers.
Alternatively, you can have a complicated scheme whereby you load FB
and DRM drivers in any order. But DRM would want FB (or part of it) to be
present anyway so it should be able to recover from engine lockup.
I would agree that this can be coded as well - but why bother ? Or is
it done and working already ?
best
Vladimir Dergachev
On Sat, 11 Sep 2004 13:27:27 +0100, Christoph Hellwig <[email protected]> wrote:
> > If the kernel developers can address this point I would be most
> > interested, in fact I don't want to hear any more about sharing lowlevel
> > VGA device drivers until someone addresses why it is acceptable to have
> > two separate driver driving the same hardware for video and not for
> > anything else.. (remembering graphics cards are not-multifunction cards -
> > like Christoph used as an example before - 2d/3d are not separate
> > functions...)...
>
> Well, Alan's proposal gets things back into a working shape with both
> fbdev and get additional benefits like hotplug and autloading without
> a major revamp of everything. The major rework will have to happen sooner
> or later anyway, but by fixing the obvious problems we face now first it
> can be done in small pieces and with far less pressure.
>
The resource reservation conflicts are already solved in the current
DRM code. Most of the changes are in kernel and the rest are in the
pipeline. DRM loads in two modes, primary where it behaves like a
normal Linux driver and stealth where it uses the resources without
telling the kernel. Stealth/primary mode is a transition tool until
things get fixed. Once everything is sorted out stealth mode can be
removed.
Think of this as having the shared resource platform code in the DRM
driver. This shared platform knows how to load DRM. The next step is
to teach it how to load fbcon. Final step is to integrate the chip
specific code from DRM and fbdev.
I believe this method is less disruptive that simultaneously tearing
up vesafb, fbdev and DRM. The end result will be the same.
--
Jon Smirl
[email protected]
On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
> Lastly, I am not saying you have to put all the code in the same file.
> All I am saying we can mandate that all Radeon HW specific code is linked
> in one module - and this would make things easier for developers.
And if I want dri but not frame buffer, or vice versa, as the majority
of current users do
> I would agree that this can be coded as well - but why bother ? Or is
> it done and working already ?
Splitting the modules up is the easy bit. The API is the hard bit so you
might as well formalize it. It also gives the users the ability to not
load huge radeon modules.
On Sat, 11 Sep 2004 17:20:38 +0800, Antonino A. Daplas
<[email protected]> wrote:
> On Saturday 11 September 2004 13:19, Dave Airlie wrote:
> > The other thing I think some people are confusing is 2.4 fbdev and 2.6...
> > there is no console support in 2.6 fbdev drivers, it is all in the fbcon
> > stuff, so the fbdev drivers are only doing 2d mode setting and monitor
> > detection, some points I've considered are:
>
> Correct. fbdev is almost completely separate from fbcon. And you can
> actually rip out fbdev and place it anywhere you want. As long as fbcon has
> access to a pointer to framebuffer memory, and the characteristics of the
> display such as depth, pitch, etc, then the framebuffer console will work.
> Throw in a few functions, such as for buffer flipping, and fbcon will be happy.
The intention of the DRM work is to reuse fbcon without change if
possible or minimize the changes needed.
> Hardware acceleration is entirely optional, and most drivers except for a few
> (such as vga16fb or amiga) can use the cfb_* drawing functions.
No code has been written for this, but part of the plan is to split
the console function into two pieces: boot and user. The boot console
would be non-accelerated and use fbcon for drawing. It's goal is to be
as reliable as possible and to work in all environments including
interrupt time. Booting in single user mode would use boot console. So
would OOPs and initial boot.
Another major console use is for normal users doing things like
editing and command line stuff. This console would be implemented in
user space. User space console can call into DRM and achieve full
acceleration. This would also allow consoles in Asian and Indic
languages.
> There's also a recent change in the latest bk tree that changes the
> intialization order of the framebuffer system. Previously, fbcon triggers
> fbmem, then fbmem triggers each individual drivers. This method requires
> that a working fbdev is present, otherwise fbcon will fail (although you can
> do a con2fbmap later, or modprobe a driver). With the change, the
> order is reversed, driver->fbmem->fbcon. This change is probably
> significant because fbcon can wait until an active framebuffer activates.
>
> In theory, one can have a process (kernel or userland) change the video
> mode, then provide the in-kernel driver with the necessary information
> about the layout of the framebuffer. When this in-kernel driver gets the
> necessary information, it can trigger fbcon. This in-kernel driver need not
> know anything about the hardware (unless 2D acceleration is needed).
The plan for mode setting is to move as much as possible of it to user
space via a hotplug event. The driver would then be informed of the
information it needs like framebuffer location, dimensions, mode
register values, etc.
>
> Tony
>
>
--
Jon Smirl
[email protected]
On Sat, Sep 11, 2004 at 12:11:13PM -0400, Jon Smirl wrote:
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline. DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses the resources without
> telling the kernel. Stealth/primary mode is a transition tool until
> things get fixed. Once everything is sorted out stealth mode can be
> removed.
Not, it's not been solved. You hacked around the most common symptoms.
On Sat, Sep 11, 2004 at 05:49:30AM -0700, Mike Mestnik wrote:
> Not to step on toes, but... From what I can tell the idea is to add code
> into FB that calles functions in the DRM and vice vers. This would seam
> to add another ABI. Unless the code gets linked into one module, this
> idea has been flamed and killed already.
in-kernel ABIs are absolutely not an issue for Linux.
On Sat, 11 Sep 2004 15:33:43 +0100, Alan Cox <[email protected]> wrote:
> For example I can see the radeon DRM driver providing
>
> ->queue_commands()
> ->quiesce()
>
> to the 2D driver. And the 2D driver providing
>
> ->define_fb_layout() for DRI to provide to X
>
> That way it is only these calls between drivers you and the fb authors
> have to argue about the functionality and interfaces between. (eg who
> saves registers, which registers)
>
Take a system with two simultaneous users on two heads of a dual head
card. The kernel will be process swapping between these two users as
needed.
User 1 is playing a 3D game.
User 2 is editing with emacs on fbdev
User 1's game queues up 20ms of 3D drawing commands.
Process swap to user 2. ->quiesce() is going to take 20ms.
User 2's timeslice expires and we go back to user 1.
User 1 queues up another 20ms.
User 2's editor is never going to function.
The correct solution is to leave the chip in 3D mode and merge DMA
command streams. User 2 wouldn't have problems if it's console driver
queued 3D commands instead of stopping the 3D coprocessor, changing
the chip mode, executing a host based 2D command, and then restarting
the coprocessor.
--
Jon Smirl
[email protected]
On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> The resource reservation conflicts are already solved in the current
> DRM code. Most of the changes are in kernel and the rest are in the
> pipeline. DRM loads in two modes, primary where it behaves like a
> normal Linux driver and stealth where it uses the resources without
> telling the kernel. Stealth/primary mode is a transition tool until
> things get fixed. Once everything is sorted out stealth mode can be
> removed.
I _think_ Alan's argument is that this isn't about the resource
reservation conflicts. In many ways resource reservations don't much
matter, since for PCI devices the kernel can (and does) make sure that
nobody else stomps on that particular IO range anyway.
So to some degree the real issue is not so much about who "owns" the
device: clearly nobody _can_ "own" it, as there are multiple drivers that
do want to access it. So the real issue is about how to serialize the
existing multiple "owners".
At least this is where I _think_ Alan is coming from. You're been an
argumentative bunch, it's hard to tell in between all the flamage ;)
> Think of this as having the shared resource platform code in the DRM
> driver. This shared platform knows how to load DRM. The next step is
> to teach it how to load fbcon. Final step is to integrate the chip
> specific code from DRM and fbdev.
Again, I think you're thinking about the problem from two fundamentally
different standpoints.
Jon, you want to get to that "Final step is to integrate the chip specific
code from DRM and fbdev". Alan doesn't even want to get there. I think
Alan just wants some simple infrastructure to let everybody play together.
(Hey, at this point everybody will jump at me and tell me I'm taking
lessons from Hans, and that I'm totally misrepresenting what people want.
"Bring it on", as those stupid US politicians would say).
So look at this another way: maybe we do _not_ want to integrate any code.
It's ok to have fbdev/fbcon/X/DRM all sharing the same device. The only
thing we need is something to serialize the damn things with.
My personal preference for this whole mess has always been the "silly
driver" that isn't even hardware-specific, and really does _nothing_ on
its own. This one would be the only thing that actually reserves the IO
regions and "owns" the card from the respect of the resources. EVERYBODY
else would be a "stealth" driver. Not just DRM.
And the drivers would never become non-stealth. They'd stay as stealth
drivers, and just use the silly hardware-independent thing as a way to
serialize themselves.
So what does the hw-independent thing need to do?
- locking. This is the first-order problem, and maybe it never even needs
to go beyond this stage. If DRM can say "I want to own the
accelerator", and others will wait for it, then that's already a big
step forward.
Implementation: have a data structure with <n> different pointers to
locks, for each independent function you can think of that somebody
would want exclusive access over. "accelerator" "modeswitch"
"framebuffer" "memory alloc" whatever.
Now, the reason why these things are _pointers_ to locks rather than
locks themselves is that maybe some hardware ends up sharing resources
between these things (maybe "modeswitch" needs the accelerator to
work), and then they have to use the same lock. Fine - just make the
pointer point to that lock. The hardware-independent part doesn't even
need to _know_ about this: it just sets up all <n> locks as being
independent, and then the low-level drivers can move the lock pointers
around since _they_ know what the rules are.
Or something like this.
- memory allocation. Many of these issues really are generic, and once
you have the locking setup done, maybe you can have a generic memory
allocation layer for splitting up AGP memory or whatever. See the
"dma_declare_coherent_memory()" interfaces that James Bottomley did for
some SCSI devices that have on-board memory that they want to let the
kernel allocate as DMA'able.
In fact, maybe the existing _general_ dma_declare_coherent_memory()
interfaces can be enhanced enough that the drivers can just use that
directly. See Documentation/DMA-API.txt for some docs (it's very
limited right now, because nobody _needs_ any more, but it already has
support for "if you can't find memory directly on the card, allocate
some from system RAM instead" kind of operations).
Anyway, please stop the flamage. It all sounds like you're arguing across
each other. Now you can flame me instead, but please try to direct the
flamage to specific points so that I don't get the feeling that you're
talking about something else..
Linus
On Sat, 11 Sep 2004, Alan Cox wrote:
> On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
>> Lastly, I am not saying you have to put all the code in the same file.
>> All I am saying we can mandate that all Radeon HW specific code is linked
>> in one module - and this would make things easier for developers.
>
> And if I want dri but not frame buffer, or vice versa, as the majority
> of current users do
You are missing my point - I do not say we need to *activate* the
framebuffer, just link the mode setting (and other hardware dependent
code) into DRM driver.
This is kinda like vesafb driver is doing now - if I don't pass vga=XX
parameter on the command line it does not touch the graphics card.
Thus, even if framebuffer support is not compiled into the kernel the DRM
driver is able to reinitialize the card into a sane state.
>
>> I would agree that this can be coded as well - but why bother ? Or is
>> it done and working already ?
>
> Splitting the modules up is the easy bit. The API is the hard bit so you
> might as well formalize it. It also gives the users the ability to not
> load huge radeon modules.
>
This is a good point - if we don't need DMA or 3d acceleration we can
reduce memory footprint. This would seem that current DRM driver would
need to be dependent on whatever driver contains the mode setting code.
What do you think ?
best
Vladimir Dergachev
Coprocessor 3D mode is deeply pipelined
2D mode is immediate
How can you build a system that process swaps between these two modes?
The 3D pipeline has to be emptied before you can enter 2D immediate
mode.
My solution is to leave the coprocessor always running and convert
everything to use the DMA based commands.
On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> My personal preference for this whole mess has always been the "silly
> driver" that isn't even hardware-specific, and really does _nothing_ on
> its own. This one would be the only thing that actually reserves the IO
> regions and "owns" the card from the respect of the resources. EVERYBODY
> else would be a "stealth" driver. Not just DRM.
How do you plan to deal with hot plug. At the point the "silly driver"
(in my case this is the vga class driver) claims the PCI device and
propogates things onwards hotplug seems to work.
The second fun bit is that Jon is right that in some cases the fb driver
for a card may want to use the DRI layer if loaded - but only some and
only in a controlled manner. Sometimes the drivers want to co-operate
sometimes they just want to avoid beating each other senseless.
> Now, the reason why these things are _pointers_ to locks rather than
> locks themselves is that maybe some hardware ends up sharing resources
> between these things (maybe "modeswitch" needs the accelerator to
How do you deal with making sure the lock doesn't get freed and knowing
who needs it still ? I ended up with locks in the shared area itself
because I couldn't figure that one out ?
> - memory allocation. Many of these issues really are generic, and once
> you have the locking setup done, maybe you can have a generic memory
> allocation layer for splitting up AGP memory or whatever. See the
> "dma_declare_coherent_memory()" interfaces that James Bottomley did for
> some SCSI devices that have on-board memory that they want to let the
> kernel allocate as DMA'able.
I think allocation is genuinely a hard problem in the 3D card case. Some
devices have the most wonderful restrictions on layout that range
from "the frame buffer is here" to "I want 2Mb, 1Mb aligned within a 4Mb
range and you can free this stuff if you notify me but its not
textures". Multihead really makes this interesting and DRI itself
doesn't really address this problem either.
Linus let me run what I have now past you for comment (the code isnt
working yet since I've been having a fight with the class code)
The vga_class module registers itself as the owner of every VGA class
device on the PCI bus. The PCI layer duely gives it all the video
hotplug events.
On creation it creates a set of (currently 3) vga bus objects for each
card. So if we find say a Voodoo 3, we will create vga bus objects
Voodoo 3 memory manager
Voodoo 3 DRI
Voodoo 3 Frame buffer 0
(for now. Quite possibly mode management is separate, maybe memory
manager eventually will or will not be)
and stick them onto global and per vga router lists.
vga_register_driver works like PCI register driver but also takes a
"type" field and will attach to the appropriate one of the 3 objects,
detach on hotplug and all the rest as the base/* code provides.
When you attach or detach you get a notifier to the other members that
are loaded.
Finally there is a shared structure between the different vga bus
objects for each video card which allows you to find one function from
another (maybe the notifiers should pass these) and also a semaphore.
On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> This is a good point - if we don't need DMA or 3d acceleration we can
> reduce memory footprint. This would seem that current DRM driver would
> need to be dependent on whatever driver contains the mode setting code.
>
> What do you think ?
Jon wants to get mode setting into a seperate piece of functionality -
preferably in user space for many cards. I'd dearly love to see hotplug
handing all but some "emergency" pre-computed mode settings.
Alan
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2. ->quiesce() is going to take 20ms.
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
>
> User 2's editor is never going to function.
If you implement it wrongly sure. If you implemented it right then
this occurs.
User 1 queues 20 ms of 3D commands
User 1 is pre-empted
User 2 wants the 2D engine
User 2 beings wait for 2D
User 2 sleeps
User 1 wakes
User 1 beings wait for 3D but discovers a claim is in progress
User 1 sleeps
User 2 wakes, runs commands
If you have DRI loaded then as you rightly say the obvious desired
outcome is that the fb engine either turns acceleration off or switches
to using the DRI layer.
But this is a pretty obscure case, and one we can't even begin to
support yet anyway.
On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> User 1's game queues up 20ms of 3D drawing commands.
> Process swap to user 2. ->quiesce() is going to take 20ms.
> User 2's timeslice expires and we go back to user 1.
> User 1 queues up another 20ms.
>
> User 2's editor is never going to function.
If you implement it wrongly sure. If you implemented it right then
this occurs.
User 1 queues 20 ms of 3D commands
User 1 is pre-empted
User 2 wants the 2D engine
User 2 beings wait for 2D
User 2 sleeps
User 1 wakes
User 1 beings wait for 3D but discovers a claim is in progress
User 1 sleeps
User 2 wakes, runs commands
If you have DRI loaded then as you rightly say the obvious desired
outcome is that the fb engine either turns acceleration off or switches
to using the DRI layer.
But this is a pretty obscure case, and one we can't even begin to
support yet anyway.
On Sad, 2004-09-11 at 18:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Card dependant.
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
> My solution is to leave the coprocessor always running and convert
> everything to use the DMA based commands.
On such a card when DRI is available that is probably the right path,
especially if it has the "can't software touch the frame buffer while
the engine runs" design flaw.
If DRI isn't loaded, or isn't running you can carry on unaccelerated.
On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[email protected]> wrote:
> On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
> > User 1's game queues up 20ms of 3D drawing commands.
> > Process swap to user 2. ->quiesce() is going to take 20ms.
> > User 2's timeslice expires and we go back to user 1.
> > User 1 queues up another 20ms.
> >
> > User 2's editor is never going to function.
>
> If you implement it wrongly sure. If you implemented it right then
> this occurs.
>
> User 1 queues 20 ms of 3D commands
> User 1 is pre-empted
> User 2 wants the 2D engine
> User 2 beings wait for 2D
> User 2 sleeps
> User 1 wakes
> User 1 beings wait for 3D but discovers a claim is in progress
> User 1 sleeps
> User 2 wakes, runs commands
This model destroys the parallel processing between the main CPU and the GPU.
>
> If you have DRI loaded then as you rightly say the obvious desired
> outcome is that the fb engine either turns acceleration off or switches
> to using the DRI layer.
>
> But this is a pretty obscure case, and one we can't even begin to
> support yet anyway.
>
>
--
Jon Smirl
[email protected]
On Sat, 11 Sep 2004, Jon Smirl wrote:
>
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Now it is _you_ who confuse "3D mode" and "2D mode".
THERE IS NO SUCH THING.
There is only hardware.
> How can you build a system that process swaps between these two modes?
You don't switch between the two non-existent modes. You serialize on
hardware accesses.
If the 2D graphics driver uses the accelerator, it takes the accelerator
lock.
If the 2D graphics just uses the framebufferm it takes the framebuffer
lock.
If there are hardware dependencies on the accelerator and the framebuffer,
then the two lock pointers point to the same lock.
The locks themselves need to have a release mechanism, of course, the same
way we already have "stateful" locks for X interactions where something
needs to be done when a lock is given to another person. So the locks
can't just be regular spinlocks or semaphores, they need to be slightly
more complicated things where each user has an "ID" cookie.
This way:
- the hardware-independent part really _is_ hardware-independent. It
literally hass _no_ clue what the different users do.
- the hardware-independent part makes no policy at all. It just has a set
of lock pointers, and a generic locking mechanism which basically looks
something like
/*
* Generic "release lock"
*/
typedef struct release_lock_struct {
struct semaphore sem;
void *cookie;
void (*releasefn)(release_lock_t *, void *);
} release_lock_t;
/*
* get a lock. Return 1 if the resource had been owned by
* somebody else in the meantime. We may need to re-initialize
* hw state if so..
*
* Otherwise, just return 0, to let the caller know that it
* didn't have anybody else screw with its state in between.
*
* (The caller could just keep this information by tracking
* it's "releasefn()" calls, of course, since if another
* locker came in, we would have asked it to release the
* info. The return value is just a convenient interface).
*/
int get_lock(release_lock_t *lock, void *cookie,
void (*releasefn)(release_lock_t *, void *))
{
down(lock->sem);
/* Same old owner? Coolio.. */
if (lock->cookie == cookie)
return 0;
/* Tell the previous lock owner to clean up */
lock->releasefn(lock, lock->cookie);
/* We now have a new owner */
lock->releasefn = releasefn;
lock->cookie = cookie;
return 1;
}
/*
* Release the lock
*/
void put_lock(release_lock_t *lock, void *cookie)
{
/*
* People screw up all the time. Only let the owner
* release the lock. Complain loudly when somebody gets
* mixed up.
*/
BUG_ON(lock->cookie != cookie);
up(lock->sem);
}
Notice? There's _zero_ hardware knowledge here. This can work for
video-cards, but it can work for anything else too.
And yes, maybe you need more complicated locks than the above, but hey,
they probably don't need to be _much_ more complicated.
So how would you use the above? Just combine it with the "graphics
subsystem" specific list of locks, which you attach to each device some
way (so that each driver that _shares_ the hardware device can find it):
struct gfx_lock_ptr {
release_lock_t *accelerator;
release_lock_t *framebuffer;
release_lock_t *memorymanager;
..
};
struct gfx_data {
struct gfx_lock_ptr ptr;
release_lock_t locks[MAXLOCKS];
};
and then the code just does
- hw-independent gfx code initializes the locks to defaults:
gfx_data->ptr.accelerator = gfx_data->locks + 0;
gfx_data->ptr.framebuffer = gfx_data->locks + 1;
gfx_data->ptr.memorymanager = gfx_data->locks + 2;
...
dev->gfx_data = gfx_data;
- the _low_level_ drivers at their initialization will know what hardware
structures are shared, so they do (when _they_ init, and notice how
this doesn't actually matter in which order they loaded - they can both
do this thing without knowing about each other):
/* This chip can't access the frame buffer when the accelerator is busy */
gfx_data->ptr.accelerator = gfx_data->ptr.framebuffer;
- then the low-level drivers just do
/* execute command */
if (get_lock(gfx_data->ptr.accelerator, mydev, myrelease)) {
/*
* Somebody else used the accelerator earlier, need to
* re-load my cached pointers:
*/
mydev->offset = readl(command_buffer + CMD_OFFSET);
}
WRITE_RING(mydev, cmd);
WRITE_RING(mydev, arg);
put_lock(gfx_data->ptr.accelerator, mydev);
- and then the "myrelease" function just does whatever writer-side
synchronization needed (wait for commands to flush, for example).
Do I know what the hell I'm talking abut? No. You should see the above as
a very quick "this _kind_ of approach should work", and work out the
details. But I really think something like the above would be quite
doable. No?
And yes, it requires changes to _both_ DRM and to fbcon, but the changes
are hopefully fairly independent, and it doesn't really require that they
share any fundamental code - it only requires a fbcon driver and a DRM
driver for the same hardware to agree on an use some _very_ simple
serialization.
Linus
On Sat, 11 Sep 2004, Alan Cox wrote:
> On Sad, 2004-09-11 at 18:02, Linus Torvalds wrote:
> > My personal preference for this whole mess has always been the "silly
> > driver" that isn't even hardware-specific, and really does _nothing_ on
> > its own. This one would be the only thing that actually reserves the IO
> > regions and "owns" the card from the respect of the resources. EVERYBODY
> > else would be a "stealth" driver. Not just DRM.
>
> How do you plan to deal with hot plug. At the point the "silly driver"
> (in my case this is the vga class driver) claims the PCI device and
> propogates things onwards hotplug seems to work.
Since the users would have to use the locking methods, they'd all be
dependent on it, so it would either be compiled in, or "modprobe" would
just automagically load it.
And yes, it would just attach directly to any VGA class device on PCI (and
have some other way to detect any other kind of graphics devices).
If we make it small, simple and generic enough (serialization isn't really
a gfx-only thing), we could frigging attach it to _every_ device in the
system, at which point it doesn't even need to "attach" any more. It would
just be there. That obviously requires that it really only do a _very_
generic set of minimal locks.
> The second fun bit is that Jon is right that in some cases the fb driver
> for a card may want to use the DRI layer if loaded - but only some and
> only in a controlled manner. Sometimes the drivers want to co-operate
> sometimes they just want to avoid beating each other senseless.
They can put whatever data they want in the shared data area (called
"gfx_data" in my previous pseudo-code-posting). They'd need to know about
each other if they want to cooperate, of course. The "silly driver" never
uses the data area itself, really. It just contains a few predefined
things, like the lock pointers, but the silly driver doesn't really even
access them, it's up to the low-level drivers to pass in the proper lock
to the silly driver.
> > Now, the reason why these things are _pointers_ to locks rather than
> > locks themselves is that maybe some hardware ends up sharing resources
> > between these things (maybe "modeswitch" needs the accelerator to
>
> How do you deal with making sure the lock doesn't get freed and knowing
> who needs it still ? I ended up with locks in the shared area itself
> because I couldn't figure that one out ?
That's exactly what I would do. See the example I sent out.
> Linus let me run what I have now past you for comment (the code isnt
> working yet since I've been having a fight with the class code)
Please realize that I have not a _frigging_ clue what I'm talking about.
I'm just listening in to the flame war, and throwing out suggestions in
the middle to try to get the discussion going _forward_. I hate seeing
hundreds of emails in my mailbox that don't seem to actually make any
_progress_.
So my comments are likely worthless.
Linus
On Sat, 11 Sep 2004, Alan Cox wrote:
> On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
>> This is a good point - if we don't need DMA or 3d acceleration we can
>> reduce memory footprint. This would seem that current DRM driver would
>> need to be dependent on whatever driver contains the mode setting code.
>>
>> What do you think ?
>
> Jon wants to get mode setting into a seperate piece of functionality -
> preferably in user space for many cards. I'd dearly love to see hotplug
> handing all but some "emergency" pre-computed mode settings.
I think there is a misunderstanding.
My view was that PLL setting (and setting of a fixed mode) would be done
in DRM driver. This way it would be able to restore previous settings
after a lockup or respond to FB request to change modes.
However the decision of which mode to set, as well as where the
framebuffer is located is done in user-space. (So that subtleties of
layout of offscreen memory are not in the kernel).
Jon - did I understand you correctly ?
best
Vladimir Dergachev
On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
<[email protected]> wrote:
> Jon, you want to get to that "Final step is to integrate the chip specific
> code from DRM and fbdev". Alan doesn't even want to get there. I think
> Alan just wants some simple infrastructure to let everybody play together.
This is the core problem. I want to get to a point where there is a
single, integrated piece of code controlling the complex functions of
the 3D hardware.
I want to get away from the model of "I just got control of the chip,
who knows what the state of it is, I better reset everything". I also
want to get away from "now I want to use this register, i need to
inspect every over driver and piece of user space code to make sure
they don't stomp it". Or "I didn't even know your code existed, sorry
about stomping that critical register and causing 100 bug reports". Or
"why don't we just split the VRAM in half so we don't have to share
memory management". Or suspend code that restores 2D mode and ignores
3D.
The problem with everyone playing together in separate code bases
assumes that everyone knows what everyone else is doing and that's
never the case. A single card specific code base collects everything
to a single place where it can be monitored.
A good example of this is switching the GPU between 2D and 3D mode on
every process swap.
In general the current X design only has a single 3D client. With a
composited display and pbuffer background drawing we are going to have
one 3D client for every top level window. This is going to require
complicated code to smoothly multitask the 3D drawing streams. The
last thing we need is something in the middle of this switching the
chip in and out of 2D mode.
--
Jon Smirl
[email protected]
On Sat, 2004-09-11 at 13:13 -0400, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
Have you looked at the radeon X driver acceleration code in the last
couple of years?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev
<[email protected]> wrote:
> On Sat, 11 Sep 2004, Alan Cox wrote:
>
> > On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote:
> >> This is a good point - if we don't need DMA or 3d acceleration we can
> >> reduce memory footprint. This would seem that current DRM driver would
> >> need to be dependent on whatever driver contains the mode setting code.
> >>
> >> What do you think ?
> >
> > Jon wants to get mode setting into a seperate piece of functionality -
> > preferably in user space for many cards. I'd dearly love to see hotplug
> > handing all but some "emergency" pre-computed mode settings.
>
> I think there is a misunderstanding.
>
> My view was that PLL setting (and setting of a fixed mode) would be done
> in DRM driver. This way it would be able to restore previous settings
> after a lockup or respond to FB request to change modes.
>
> However the decision of which mode to set, as well as where the
> framebuffer is located is done in user-space. (So that subtleties of
> layout of offscreen memory are not in the kernel).
>
> Jon - did I understand you correctly ?
All register writes would occur in the driver. There is nothing
stopping the code that computes those register values from running in
user space.
A example mode setting IO would take:
display buffer offset
width, height, stride, etc - for fbcon to use
register values to set the mode
Mode setting needs to be serialized. It may be better to do the
serialization before the hotplug event, in that case the mode setting
IOCTL would be implicitly serialized and not need a separate lock.
--
Jon Smirl
[email protected]
On Sat, 11 Sep 2004, Jon Smirl wrote:
>>
>> My view was that PLL setting (and setting of a fixed mode) would be done
>> in DRM driver. This way it would be able to restore previous settings
>> after a lockup or respond to FB request to change modes.
>>
>> However the decision of which mode to set, as well as where the
>> framebuffer is located is done in user-space. (So that subtleties of
>> layout of offscreen memory are not in the kernel).
>>
>> Jon - did I understand you correctly ?
>
> All register writes would occur in the driver. There is nothing
> stopping the code that computes those register values from running in
> user space.
>
> A example mode setting IO would take:
> display buffer offset
> width, height, stride, etc - for fbcon to use
> register values to set the mode
>
> Mode setting needs to be serialized. It may be better to do the
> serialization before the hotplug event, in that case the mode setting
> IOCTL would be implicitly serialized and not need a separate lock.
Just to clear up things - do you plan to retain the knowledge of last mode
set in the DRM driver ?
best
Vladimir Dergachev
>
> --
> Jon Smirl
> [email protected]
>
On Sat, 11 Sep 2004 14:05:54 -0400 (EDT), Vladimir Dergachev
<[email protected]> wrote:
> > All register writes would occur in the driver. There is nothing
> > stopping the code that computes those register values from running in
> > user space.
> >
> > A example mode setting IO would take:
> > display buffer offset
> > width, height, stride, etc - for fbcon to use
> > register values to set the mode
> >
> > Mode setting needs to be serialized. It may be better to do the
> > serialization before the hotplug event, in that case the mode setting
> > IOCTL would be implicitly serialized and not need a separate lock.
>
> Just to clear up things - do you plan to retain the knowledge of last mode
> set in the DRM driver ?
Yes, you have to do that for fbcon and suspend/restore to work.
--
Jon Smirl
[email protected]
On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <[email protected]> wrote:
> > Jon, you want to get to that "Final step is to integrate the chip specific
> > code from DRM and fbdev". Alan doesn't even want to get there. I think
> > Alan just wants some simple infrastructure to let everybody play together.
>
> This is the core problem. I want to get to a point where there is a
> single, integrated piece of code controlling the complex functions of
> the 3D hardware.
I think you can get there without having to merge the two.
How about just accepting the fact that there might be other people
accessing your hardware, and then trying to make it _rare_?
> I want to get away from the model of "I just got control of the chip,
> who knows what the state of it is, I better reset everything". I also
> want to get away from "now I want to use this register, i need to
> inspect every over driver and piece of user space code to make sure
> they don't stomp it". Or "I didn't even know your code existed, sorry
> about stomping that critical register and causing 100 bug reports". Or
> "why don't we just split the VRAM in half so we don't have to share
> memory management". Or suspend code that restores 2D mode and ignores
> 3D.
Well, what _I_ want to get away from is a "I'm the only game in town"
mentality.
I want people to be able to play with other things, without having one
driver that has to know about it all. I also want to avoid flag-days, ie
I'd like to be able to have a gradual transition.
And I don't think your model really has the option for a gradual
transition, and other people doing their thing.
So I'd much rather see the "hey, somebody else might have stolen my
hardware, and now I need to re-initialize" as the _basic_ model. That just
allows others to do their own thing, and play well together. More
importantly, it allows the existing status quo, which means that if we
take that as the basic approach, we _never_ have to make a complete flag
day when we switch over to "_this_ driver does everything". See?
HOWEVER, I do realize that that is horribly inefficient as a common thing
to happen, which is why I have the cunning plan (always steal good ideas
from others and call them "your" cunning plans) to have the locking that
allows for caching over locks. That means that _if_ you get to the point
where your driver does everything, you'll never really have to worry about
performance, because you'll never see the bad cases.
Or maybe you'll only see the bad cases when the kernel oopses, and decides
that it _has_ to write to the screen and screw your model. See what I'm
saying? Having a model that allows for that is a _good_ thing.
And you can do it. Basically, if you build on top of the "silly driver"
locks, your DRM layer would have _one_ cookie (per hw device, of course)
that it ever uses, and it would point to your basic device descriptor.
You'd then do the X cookies within that decide descriptor, ie they'd never
change the "silly driver" cookie, and thus you'd never see a "conflict".
You'd take care of the existing DRM locking methods yourself, you wouldn't
try to shoe-horn them into the silly driver locks.
So what I'm saying is that you _can_ get to your ideal world, without
taking the option away from others to decide that they prefer having two
(or three, or fifteen) drivers all accessing the same hardware. For
example, the single-driver approach might be good for some hadrware. It
might not be so good for others (think vendor drivers etc).
> A good example of this is switching the GPU between 2D and 3D mode on
> every process swap.
>
> In general the current X design only has a single 3D client. With a
> composited display and pbuffer background drawing we are going to have
> one 3D client for every top level window.
But if you make your DRM thing be the "master" of these different 3D
client contexts, then you _can_ handle that without ever having to lose
your "hardware lock". See what I'm saying? You do two-level locking:
- the "hardware level" is the silly driver one. It's the one that allows
multiple kinds of subsystems to play together, be it DRM of fbcon. When
you get a "release event" for this one, you basically have to serialize
_everything_, because this level of release means that you literally
don't know what happened (with the exception of mode switching, I
really think that one has to be a totally separate class of events).
- you have your _own_ "DRM level" context lock, which is the one the 3D
clients from X actually interface to. That one also has to reset _some_
client state, of course, when you switch between clients, but now it's
only state that _you_ know about.
You can have your cake and eat it too. I don't think these things are
incompatible.
Linus
On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 10:02:57 -0700 (PDT), Linus Torvalds
> <[email protected]> wrote:
>> Jon, you want to get to that "Final step is to integrate the chip specific
>> code from DRM and fbdev". Alan doesn't even want to get there. I think
>> Alan just wants some simple infrastructure to let everybody play together.
>
> This is the core problem. I want to get to a point where there is a
> single, integrated piece of code controlling the complex functions of
> the 3D hardware.
Jon,
Alan did have a valid point about the current size of DRM driver.
Would it not be possible to separate parts that assist 3d acceleration -
like DRM ioctls to submit textures etc and the code to validate the
command stream submitted from userspace ? This should cut down the size
considerably.
best
Vladimir Dergachev
>
> I want to get away from the model of "I just got control of the chip,
> who knows what the state of it is, I better reset everything". I also
> want to get away from "now I want to use this register, i need to
> inspect every over driver and piece of user space code to make sure
> they don't stomp it". Or "I didn't even know your code existed, sorry
> about stomping that critical register and causing 100 bug reports". Or
> "why don't we just split the VRAM in half so we don't have to share
> memory management". Or suspend code that restores 2D mode and ignores
> 3D.
>
> The problem with everyone playing together in separate code bases
> assumes that everyone knows what everyone else is doing and that's
> never the case. A single card specific code base collects everything
> to a single place where it can be monitored.
>
> A good example of this is switching the GPU between 2D and 3D mode on
> every process swap.
>
> In general the current X design only has a single 3D client. With a
> composited display and pbuffer background drawing we are going to have
> one 3D client for every top level window. This is going to require
> complicated code to smoothly multitask the 3D drawing streams. The
> last thing we need is something in the middle of this switching the
> chip in and out of 2D mode.
>
> --
> Jon Smirl
> [email protected]
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
Alan Cox wrote:
>On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>
>
>>User 1's game queues up 20ms of 3D drawing commands.
>>Process swap to user 2. ->quiesce() is going to take 20ms.
>>User 2's timeslice expires and we go back to user 1.
>>User 1 queues up another 20ms.
>>
>>User 2's editor is never going to function.
>>
>>
>
>If you implement it wrongly sure. If you implemented it right then
>this occurs.
>
>User 1 queues 20 ms of 3D commands
>User 1 is pre-empted
>User 2 wants the 2D engine
>User 2 beings wait for 2D
>User 2 sleeps
>User 1 wakes
>User 1 beings wait for 3D but discovers a claim is in progress
>User 1 sleeps
>User 2 wakes, runs commands
>
>If you have DRI loaded then as you rightly say the obvious desired
>outcome is that the fb engine either turns acceleration off or switches
>to using the DRI layer.
>
>But this is a pretty obscure case, and one we can't even begin to
>support yet anyway.
>
>
>
What about if you want to use fb when in text mode (Because you get
200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
back & forth between X & fb... (i.e. how I currently use it but with
unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
Currently this fails to work... Presumably because the fb & DRI code
(fglrx here BTW) don't talk to each other & so the display gets garbled
if you're lucky... Lockup if you're not.
Although I didn't like (Understand?) Jon's suggestion at first, I have
to admit, that his scheme would let this work... because the low level
driver would know what mode was in place, and you'd call the low-level
driver to change between 3D & fb mode...
Although Linus' suggestion works for memory allocation... I don't
believe it addresses two competing drivers wanting to play with the same
screen... Even when it's serialised like that. And unfortunately
although Alan's probably works for DRI & fb on separate heads, how does
it guarantee that the chipset is all setup the same way for each process
on different heads... (When they have to share some of the hardware). Or
is that necessary?
On Sat, 2004-09-11 at 10:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
>
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
>
> My solution is to leave the coprocessor always running and convert
> everything to use the DMA based commands.
Now, I'll admit that I've only really worked on three sets of hardware
(SiS 300-series, Radeon, Rage 128), but they don't have any "3d mode"
and "2d mode" concept. On SiS both 3d and 2d go through a FIFO, so for
switching between clients you just have to check how much free space
there is in the fifo. For Radeon and Rage 128 you can send rendering
commands either through the CP/CCE (DMA) or an MMIO FIFO. You can do 2d
and 3d commands both ways. In fact, you can send DMA commands through
an MMIO aperture as well. But there is nothing "immediate" about 2d.
It goes through the FIFO or the CP just like 3d rendering. If I'm not
mistaken about other hardware I've poked at (3dfx, mach64), they don't
have any "2d mode" and "3d mode" either.
To summarize, there is no "2d mode" and "3d mode." Please stop
referring to it. If you were actually trying to talk about
synchronization for MMIO vs DMA command submission (which is and would
be a very rare case anyway), well, I don't see why that can't be done
using Linus' example, which seemed like what Alan Cox has been driving
toward for a long time.
If you want to avoid idling to switch from DMA to MMIO in that rare
case, then have whatever client in question write all commands into a
DMA buffer, then dispatch it through either the DRM or decoding into
MMIO writes. Xati is an example of doing just that, and it's not that
hard. Or, you could go the route that the XFree86 X Server has and
just have two sets of your acceleration functions, generated through
macros, which write to MMIO or write DMA buffers depending on which has
been set up.
But I see nothing in this issue that requires all the drivers live in
one module together, which would only make life a little more convenient
for some developers, at the expense of all the users who don't want all
of those drivers necessarily.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
Alan, if you will commit Redhat to implementing all of the features
referenced in this message:
http://lkml.org/lkml/2004/8/2/111
then I'll back off and go work on the X server.
Use whatever mechanism you want, but implement all of the features.
There are two main goals:
#1) Get mesa-solo running with superbuffers, this means memory
allocation and mode setting have to be fixed. This will be the base
platform for X on GL.
#2) Support independent users logged into each head. One using the
console with fbdev and the other X and a 3D game.
--
Jon Smirl
[email protected]
On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> Alan, if you will commit Redhat to implementing all of the features
> referenced in this message:
You definitly start sounding like Hans ;-)
On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <[email protected]> wrote:
> On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > Alan, if you will commit Redhat to implementing all of the features
> > referenced in this message:
>
> You definitly start sounding like Hans ;-)
Getting the Linux display subsystem to a point where it can compete
with Longhorn/Mac is a very complicated problem. It is going to take
several years of work and the cooperation of a lot of people. It's a
pyramid problem with lot's of layers.
Of course Linux can choose not to build a display system based on 3D
hardware. But I've seen the
current Longhorn/Mac implementations and they are way, way better than
X. If Linux ignores 3D mode it is going to be very visible on the
desktop.
I've tried to follow the Linux model for proposing the changes. The
plan has been circulated to all relevant lists: fbdev, dri, xorg, lkml
for over six months. Three sessions at OLS talked about various parts
of the plan. Nothing has been kept secret, there must be 5,000
messages in the archive on this subject.
But since I've written most of the code so far I get to pick the
details of the implementation. If Alan would instead like to pick the
details I've offered to withdraw if he'll write the code needed to
implement the major points of the plan. Of course if Redhat wants to
send me a check for a couple of hundred thousand dollars I'll write
whatever they want, but they haven't done that.
--
Jon Smirl
[email protected]
On Sat, 11 Sep 2004 13:29:33 -0700, Eric Anholt <[email protected]> wrote:
> To summarize, there is no "2d mode" and "3d mode." Please stop
> referring to it. If you were actually trying to talk about
> synchronization for MMIO vs DMA command submission (which is and would
You are right on all of this, I'm just using 2D and 3D as shorthand
for GPU coprocessor/DMA vs CPU/registers. Don't take this as literally
meaning 2D vs 3D.
--
Jon Smirl
[email protected]
> What about if you want to use fb when in text mode (Because you get
> 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
> you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
> back & forth between X & fb... (i.e. how I currently use it but with
> unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
Thats actually the easy case. We don't care if it takes another 30th of
a second to flip console. The hard one Jon was trying to point out is
a dual head card. Head 0 has someone running bzflag, head 1 has someone
editing an open office document. You have one accelerator set for both
heads. At that point you do care about the switch over, but the drivers
can co-operate for it. So it would always work, but it would work better
with friendly drivers when there is a need to do so.
> Currently this fails to work... Presumably because the fb & DRI code
> (fglrx here BTW) don't talk to each other & so the display gets garbled
> if you're lucky... Lockup if you're not.
fglrx stomps blindly on everything including your AGP. Not much we can
do about it.
> although Alan's probably works for DRI & fb on separate heads, how does
> it guarantee that the chipset is all setup the same way for each process
> on different heads... (When they have to share some of the hardware). Or
> is that necessary?
You assume someone else crapped on the hardware. That is how DRI works
for example. You have multiple rendering clients each of which when it
takes the lock finds out if it was the last user (thats one thing Linus
sketch lacked but is easy to add).
My code ends up looking like
lock
if(someone_else_used_it)
restore_my_state()
blah
unlock
On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
<[email protected]> wrote:
> So I'd much rather see the "hey, somebody else might have stolen my
> hardware, and now I need to re-initialize" as the _basic_ model. That just
> allows others to do their own thing, and play well together. More
> importantly, it allows the existing status quo, which means that if we
> take that as the basic approach, we _never_ have to make a complete flag
> day when we switch over to "_this_ driver does everything". See?
We already have a mechanism for this: suspend/resume. The downside to
this approach is that after I get a resume I have to rebuild the
hardware state. It takes a while to rebuild half a gig of graphics
state but this model will provide the required isolation.
> HOWEVER, I do realize that that is horribly inefficient as a common thing
> to happen, which is why I have the cunning plan (always steal good ideas
> from others and call them "your" cunning plans) to have the locking that
> allows for caching over locks. That means that _if_ you get to the point
> where your driver does everything, you'll never really have to worry about
> performance, because you'll never see the bad cases.
suspend/resume will address this too. On VT switch DRM would receive a
suspend command and fbdev a resume, then vice versa on the way back.
We will have to build a scheme for assigning a driver to each VT. A
general mechanism would extend this beyond the video drivers.
This is implementing device driver multitasking something I didn't
want to do. I never said it wouldn't work, I just didn't want to do
it. I thought the complexity/performance trade offs weren't worth it.
>
> Or maybe you'll only see the bad cases when the kernel oopses, and decides
> that it _has_ to write to the screen and screw your model. See what I'm
> saying? Having a model that allows for that is a _good_ thing.
>
> And you can do it. Basically, if you build on top of the "silly driver"
> locks, your DRM layer would have _one_ cookie (per hw device, of course)
> that it ever uses, and it would point to your basic device descriptor.
> You'd then do the X cookies within that decide descriptor, ie they'd never
> change the "silly driver" cookie, and thus you'd never see a "conflict".
> You'd take care of the existing DRM locking methods yourself, you wouldn't
> try to shoe-horn them into the silly driver locks.
>
> So what I'm saying is that you _can_ get to your ideal world, without
> taking the option away from others to decide that they prefer having two
> (or three, or fifteen) drivers all accessing the same hardware. For
> example, the single-driver approach might be good for some hadrware. It
> might not be so good for others (think vendor drivers etc).
Why do we have fifteen video drivers for the radeon and only one for
each SCSI card? Could it be that the SCSI drivers are well designed
and do everything needed, thus removing the incentive for most people
to write new ones? If we had a good, standardized library for
accessing accelerated drawing functions people might stop rewriting
the video drivers. I'd rather spend my effort trying to build a good
library rather than building sandboxes to keep fifteen partial
libraries from interfering.
> > A good example of this is switching the GPU between 2D and 3D mode on
> > every process swap.
> >
> > In general the current X design only has a single 3D client. With a
> > composited display and pbuffer background drawing we are going to have
> > one 3D client for every top level window.
>
> But if you make your DRM thing be the "master" of these different 3D
> client contexts, then you _can_ handle that without ever having to lose
> your "hardware lock". See what I'm saying? You do two-level locking:
>
> - the "hardware level" is the silly driver one. It's the one that allows
> multiple kinds of subsystems to play together, be it DRM of fbcon. When
> you get a "release event" for this one, you basically have to serialize
> _everything_, because this level of release means that you literally
> don't know what happened (with the exception of mode switching, I
> really think that one has to be a totally separate class of events).
You almost said resume - "release event" was real close.
> - you have your _own_ "DRM level" context lock, which is the one the 3D
> clients from X actually interface to. That one also has to reset _some_
> client state, of course, when you switch between clients, but now it's
> only state that _you_ know about.
>
> You can have your cake and eat it too. I don't think these things are
> incompatible.
Build the sandboxes and then let everyone play.
>
> Linus
>
--
Jon Smirl
[email protected]
On Sad, 2004-09-11 at 22:37, Jon Smirl wrote:
> But since I've written most of the code so far I get to pick the
> details of the implementation.
Umm thats what happened to ruby and thats what happened to KGI.
> If Alan would instead like to pick the
> details I've offered to withdraw if he'll write the code needed to
> implement the major points of the plan.
I'll try and debug the vga generic (Linus "stupid" driver as he calls
it). That'll provide the framework to plug the other bits in. That needs
doing anyway to get hotplugging and all the other sane stuff right (oh
and probably sysfs but someone else can do that).
I was using much simpler lock ideas than Linus but I'll have a poke at
that too, something more like a dri lock that knows who had it last.
Alan
On Sat, 11 Sep 2004, Jon Smirl wrote:
> On Sat, 11 Sep 2004 11:13:17 -0700 (PDT), Linus Torvalds
> <[email protected]> wrote:
> > So I'd much rather see the "hey, somebody else might have stolen my
> > hardware, and now I need to re-initialize" as the _basic_ model. That just
> > allows others to do their own thing, and play well together. More
> > importantly, it allows the existing status quo, which means that if we
> > take that as the basic approach, we _never_ have to make a complete flag
> > day when we switch over to "_this_ driver does everything". See?
>
> We already have a mechanism for this: suspend/resume.
Jon, you're not making sense any more.
This discussion is just ridiculous, and I don't think it's worth cc'ing me
if people can't try to work together, since I'm sadly not going to have
time to actually implement any of this myself.
If you are claiming that we should suspend/resume the whole chip just
because two different programs want to access it, you're just crazy.
We clearly _do_ have different subsystems already working together
accessign the same chip, and they are _not_ doing stupid things like you
are suggesting. They _work_. Today. No suspend/resume involved.
That interaction has some troubles, and we're trying to _fix_ them. We're
not trying to make idiotic statments.
Yours was a singularly idiotic statment.
Linus
--- Alan Cox <[email protected]> wrote:
> On Sad, 2004-09-11 at 16:53, Vladimir Dergachev wrote:
> > Lastly, I am not saying you have to put all the code in the same
> file.
> > All I am saying we can mandate that all Radeon HW specific code is
> linked
> > in one module - and this would make things easier for developers.
>
> And if I want dri but not frame buffer, or vice versa, as the majority
> of current users do
>
Hopefully any change to the kernel will allow building FB without DRM.
This is a trivial seperation of code, that I might add has allready been
done, a good point that we should keep it this way. Yes, there will be
some new memory mngmt code, posibly optonal as well, that is needed for
multi-headed setups.
> > I would agree that this can be coded as well - but why bother ?
> Or is
> > it done and working already ?
>
> Splitting the modules up is the easy bit. The API is the hard bit so you
> might as well formalize it. It also gives the users the ability to not
> load huge radeon modules.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
On Sat, 2004-09-11 at 14:37, Jon Smirl wrote:
> On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <[email protected]> wrote:
> > On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > > Alan, if you will commit Redhat to implementing all of the features
> > > referenced in this message:
> >
> > You definitly start sounding like Hans ;-)
>
> Getting the Linux display subsystem to a point where it can compete
> with Longhorn/Mac is a very complicated problem. It is going to take
> several years of work and the cooperation of a lot of people. It's a
> pyramid problem with lot's of layers.
>
> Of course Linux can choose not to build a display system based on 3D
> hardware. But I've seen the
> current Longhorn/Mac implementations and they are way, way better than
> X. If Linux ignores 3D mode it is going to be very visible on the
> desktop.
>
> I've tried to follow the Linux model for proposing the changes. The
> plan has been circulated to all relevant lists: fbdev, dri, xorg, lkml
> for over six months. Three sessions at OLS talked about various parts
> of the plan. Nothing has been kept secret, there must be 5,000
> messages in the archive on this subject.
>
> But since I've written most of the code so far I get to pick the
> details of the implementation. If Alan would instead like to pick the
> details I've offered to withdraw if he'll write the code needed to
> implement the major points of the plan. Of course if Redhat wants to
> send me a check for a couple of hundred thousand dollars I'll write
> whatever they want, but they haven't done that.
I don't see what longhorn and quartz have to do with the question at
hand (this plan to cram FB and DRM together).
If we want to do the pretty graphics things that these improvements to
graphics on other OSes have done, we don't need to touch FB at all. We
already have X Servers with the composite extension. We've got a vector
graphics library. Now we need to make those go fast. We can do the
go-faster part within the X Server and the vector graphics library
without touching the DRM, FB, or anyone else. I'm spending far too much
of my free time currently working on this.
Now, another good project is to get our 3d drivers to the point that we
could write our X Server on top of that. Basically, we need pbuffer
support for that. That'll touch the DRM and client drivers (and our
current X Servers, though that part wouldn't be used in the X-on-GL
model). Again, not FB.
A completely separate issue is how to arrange for synchronization
between the multiple users of the graphics hardware on linux. I think a
pretty decent model has been proposed by the Linux kernel people, and it
seems rather simple. FreeBSD is happy with it because it doesn't affect
us in any way. (When we get around to dealing with the issue (if ever),
i.e. when we've got accelerated graphics layers for console, I'm quite
sure we'll follow the same model of a relatively generic lock in the
kernel which all graphics clients will use to arbitrate hardware
access).
Please, stop trotting out Longhorn and Quartz to justify whatever you're
trying to push into the kernel.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
On Sun, 12 Sep 2004, Alan Cox wrote:
> > What about if you want to use fb when in text mode (Because you get
> > 200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
> > you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
> > back & forth between X & fb... (i.e. how I currently use it but with
> > unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
>
> Thats actually the easy case. We don't care if it takes another 30th of
> a second to flip console. The hard one Jon was trying to point out is
BTW, it's not always O(30th of seconds): if we have to reprogram the PLLs
(someone else may have changed the hardware state, let's play safe), it can
take much longer.
People already complained about long switching times between different VCs
using the same video mode, due to reprogramming the PLL from scratch, just to
be safe no one else did something to the hardware state we don't know about.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Alan Cox wrote:
>>What about if you want to use fb when in text mode (Because you get
>>200x75 on a 1600x1200 screen) AND run DRI because the rest of the time
>>you want to run fast 3D. Plus you want to be able to CTRL-ALT-F1/F2/F7
>>back & forth between X & fb... (i.e. how I currently use it but with
>>unaccelerated x.org radeon drivers, becaus ethe 3D ones WON'T play nicely).
>>
>>
>
>Thats actually the easy case. We don't care if it takes another 30th of
>a second to flip console. The hard one Jon was trying to point out is
>a dual head card. Head 0 has someone running bzflag, head 1 has someone
>editing an open office document. You have one accelerator set for both
>heads. At that point you do care about the switch over, but the drivers
>can co-operate for it. So it would always work, but it would work better
>with friendly drivers when there is a need to do so.
>
>
>
I see you point of view. And agree with the sentiment about another
1/30th of a scond to switch modes... Heck, I'd put up with 500ms...
(1000ms looks like too much of a lag & makes me impatient when I want to
switch. Especially if there's no feedback).
But this relies on drivers co-operating with each other. Which is a real
pain, and we'd still be stuck with finger pointing whenever two drivers
didn't manage to co-operate successfully... And you'd need co-operation
& understanding to solve the problem... If one of the sides is
proprietary closed source drivers then the co-operation may not be there.
At the end of the day, if it works & works well, it doesn't appear to
matter too much whether it's a single driver, or multiple drivers
accessing the same hardware. I have no axe to grind either way, and hope
I'm keeping an open mind.
But from a supportability point of view I think Jon's single driver
wins. Even if it's a closed source driver, as long as the entry points &
callbacks are documented well & can be tested, it's easier to find where
the problem lies (i.e. inside or outside the one driver). Having
competing ones may well prove to be near impossible to get to work
together (Risking the wrath and going back to an example like the ide cd
& disk one, it would be like having a proprietary driver talking to your
SCSI DVD drive, manipulating the chipset on your SCSI card & another one
doing the same thing for you HD... It just doesn't happen that way
now... We have a SCSI card driver that looks after the card & separate
drivers that use the low-level one to just push SCSI commands to each. -
Bad analogy?
>>Currently this fails to work... Presumably because the fb & DRI code
>>(fglrx here BTW) don't talk to each other & so the display gets garbled
>>if you're lucky... Lockup if you're not.
>>
>>
>
>fglrx stomps blindly on everything including your AGP. Not much we can
>do about it.
>
>
>
Yeah. Would fglrx be more stable if you used the external AGP rather
than fglrx's built in AGP driver?
>>although Alan's probably works for DRI & fb on separate heads, how does
>>it guarantee that the chipset is all setup the same way for each process
>>on different heads... (When they have to share some of the hardware). Or
>>is that necessary?
>>
>>
>
>You assume someone else crapped on the hardware. That is how DRI works
>for example. You have multiple rendering clients each of which when it
>takes the lock finds out if it was the last user (thats one thing Linus
>sketch lacked but is easy to add).
>
>My code ends up looking like
>
> lock
> if(someone_else_used_it)
> restore_my_state()
> blah
> unlock
>
>
>
Ah... Now I understand what you've been talking about as well... The
only caveat is whether you can always restore your own state from the
state the other person put it into. Do any cards exist where you could
perhaps still lock the card up because you didn't know the current state
of the card?
Would it be better to do the state_changed flag as a callback to each
registered driver?
On Sul, 2004-09-12 at 12:36, Hamie wrote:
> But this relies on drivers co-operating with each other.
Only minimally, and providing the co-operation is easy the rest comes
out fine. We don't often get ide-disk and ide-cd people arguing over
whose fault something is
> Yeah. Would fglrx be more stable if you used the external AGP rather
> than fglrx's built in AGP driver?
Who knows, ATI have the source, ask them 8)
> >My code ends up looking like
> >
> > lock
> > if(someone_else_used_it)
> > restore_my_state()
> > blah
> > unlock
>
> Ah... Now I understand what you've been talking about as well... The
> only caveat is whether you can always restore your own state from the
> state the other person put it into. Do any cards exist where you could
> perhaps still lock the card up because you didn't know the current state
> of the card?
There are lots of cards where you might need more than the basic
example. You need to know your own state clearly, you often can't
retrieve that from the card. You may also need to know the previous user
has left it in a sane state. That might lead you to say
lock
oldowner->release()
blah
unlock (&release_func)
so that the previous caller is told it is losing the lock and can
for example wait for its commands to complete.
>
> > Alan, I agree with how you want to proceed with this, and keep things
> > stable, but anything short of a single card-specific driver looking after
> > the registers and DMA queueing and locking is going to have deficiencies
> > and the DRM has a better basis than the fb drivers,
>
> "I want to own it, mine mine". Pathetic really isn't it. The FB writers
> I've no doubt think they should own it and their code is better too.
> They also support a lot more hardware than you do of course, and on
> platforms that DRI doesn't support.
I actually don't give a rats arse who owns it, this isn't a them and us
despite these rather obvious attempts to make it so.. this is a who writes
the code and does the design and at the moment I'm seeing you and Jon with
differing view points, and I'm trying to get both sides to figure out what
needs to be done, I'll gladly review any changes for the drm but saying
it's a DRI vs kernel is a very small minded view that I don't really care
for..
The worst things that will happen for all concerened is this:
Jon does all this work on a merged solution outside the kernel, and it
works well, and the X team decide to do a decent X on mesa-solo on Jons
super-DRM, now the super-DRM gets pushed via the X tree and distributions
start relasing kernels with it merged into it and it never goes into the
main tree... it won't matter, RH/SuSE/whomever will want to pick up the
new features for the *enhanced user experience* and people will give out
about not being able to use Linus's kernels and it'll be a bit of a big
mess sort of like when the DRM came out first... now I think X is
probably the only project that can push this sort of change without
kernel developer consent, I personally would rather this didn't happen,
I think yourself and Linus's ideas for a locking scheme look good, I also
know they won't please Jon too much as he can see where the potential
ineffecienes with saving/restore card state on driver swap are, especailly
on running fbcon and X on a dual-head card with different users.
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Sun, 12 Sep 2004, Dave Airlie wrote:
>
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.
Now, how much do you actually really need to restore/save?
Yes, intelligent restore/save means that there needs to be independent
memory management, but I thought that was the long-term plan _anyway_, no?
And once you have reasonably intelligent memory management, you really
only need to save/restore the engine state, if even that (ie it should be
enough to just "idle" the engine).
Now, I'll agree that getting a good MM that solves peoples issues is a
huge problem. Much harder that some little locks. But on the other hand,
it really should be able to be largely card-agnostic, I sincerely hope.
And once you have some way to manage memory allocations between different
clients, saving/restoring card state really shouldn't be problematic. You
make the rule be that everybody has to be able to re-create their caches
(as with the locks, the cache manager would obviously have to have a
callback), and you should never be in the position where you have to
really save/restore any video memory contents at all.
(Yes, and if your working set ends up being bigger than your video ram,
you won't perform well, but that's pretty fundamental regardless of number
of clients or how they communicate).
The MM is still fairly complex, especially wrt areas that are "busy"
(the client may be able to re-create them, but if the currently executing
_engine_ has pointers to it, the cache obviously can't be thrown away).
Many of those things might be simplified by having fairly strict rules
("you can do video memory garbage collection only when the engine is
idle"), otherwise you'll need to have some complex infrastructure to keep
track of which areas are used by which commands...
Linus
> >
> > We already have a mechanism for this: suspend/resume.
>
> Jon, you're not making sense any more.
> This discussion is just ridiculous, and I don't think it's worth cc'ing me
> if people can't try to work together, since I'm sadly not going to have
> time to actually implement any of this myself.
>
> If you are claiming that we should suspend/resume the whole chip just
> because two different programs want to access it, you're just crazy.
>
> We clearly _do_ have different subsystems already working together
> accessign the same chip, and they are _not_ doing stupid things like you
> are suggesting. They _work_. Today. No suspend/resume involved.
I think you are missing Jon's point here, we do complete suspend/resume
nowdays, just look at the radeon DDX Enter/Leave VT code, now I don't
particularly want that code in the kernel, it assumes nothing about the
chip after you switch back to X and restores the whole lot.. so we are
doing this today, they work because of that code, the DRM doesn't do
anything unless X is running in most scenarios today, so the DRM and fb
never do anything that simulatenous that you might notice as when you
switch away from X the drm is locked against working, and the fb can take
over, in the future this isn't going to be true, the mesa-solo work being
one case where fb and drm are going to be accessed from the one
process....
So his statement didn't seem that idiotic to me... he might have explained
himself better, and may have assumed everyone understands the internals of
the X DDXes,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.
Frankly, I don't understand the fuss about that. When you run a 3D
client on X today, 3D client and X server share the accelerator with
this scheme, and as imperfect as it is, it seems to do a pretty good job
in my experience.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
On Sun, 12 Sep 2004, Michel [ISO-8859-1] D?nzer wrote:
> On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>>
>> I think yourself and Linus's ideas for a locking scheme look good, I also
>> know they won't please Jon too much as he can see where the potential
>> ineffecienes with saving/restore card state on driver swap are, especailly
>> on running fbcon and X on a dual-head card with different users.
>
> Frankly, I don't understand the fuss about that. When you run a 3D
> client on X today, 3D client and X server share the accelerator with
> this scheme, and as imperfect as it is, it seems to do a pretty good job
> in my experience.
Not that good - try dragging something while a DVD video is playing.
But, I don't understand what the fuss is about either. What's wrong with
putting PLL setting code inside DRM driver and letting it be the client of
fbcon ? And the transition problems could be well solved by leaving the
existing fbcon in for the time being, it is not like the kernel does not
have duplicate drivers.
best
Vladimir Dergachev
>
>
> --
> Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
> Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
>
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >> know they won't please Jon too much as he can see where the potential
> >> ineffecienes with saving/restore card state on driver swap are, especailly
> >> on running fbcon and X on a dual-head card with different users.
> >
> > Frankly, I don't understand the fuss about that. When you run a 3D
> > client on X today, 3D client and X server share the accelerator with
> > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > in my experience.
>
> Not that good - try dragging something while a DVD video is playing.
What are you getting at?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
<[email protected]> wrote:
>
>
> On Sun, 12 Sep 2004, Michel [ISO-8859-1] D�nzer wrote:
>
> > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> >>
> >> I think yourself and Linus's ideas for a locking scheme look good, I also
> >> know they won't please Jon too much as he can see where the potential
> >> ineffecienes with saving/restore card state on driver swap are, especailly
> >> on running fbcon and X on a dual-head card with different users.
> >
> > Frankly, I don't understand the fuss about that. When you run a 3D
> > client on X today, 3D client and X server share the accelerator with
> > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > in my experience.
>
> Not that good - try dragging something while a DVD video is playing.
The overlay could be converted to use the CP engine as well. right now
it has to switch to MMIO for overlay.
Alex
>
> But, I don't understand what the fuss is about either. What's wrong with
> putting PLL setting code inside DRM driver and letting it be the client of
> fbcon ? And the transition problems could be well solved by leaving the
> existing fbcon in for the time being, it is not like the kernel does not
> have duplicate drivers.
>
> best
>
> Vladimir Dergachev
>
>
>
> >
> >
> > --
> > Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
> > Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
>
On Mon, 2004-09-13 at 00:42, Dave Airlie wrote:
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets pushed via the X tree and distributions
> start relasing kernels with it merged into it and it never goes into the
> main tree... it won't matter, RH/SuSE/whomever will want to pick up the
> new features for the *enhanced user experience* and people will give out
fwiw RH will ship the DRM that is in Linus' kernel not some weird
oddball external one, so at least that portion of your argument is moot
;)
Jon Smirl wrote:
> On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[email protected]> wrote:
>
>>On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>>
>>>User 1's game queues up 20ms of 3D drawing commands.
>>>Process swap to user 2. ->quiesce() is going to take 20ms.
>>>User 2's timeslice expires and we go back to user 1.
>>>User 1 queues up another 20ms.
>>>
>>>User 2's editor is never going to function.
>>
>>If you implement it wrongly sure. If you implemented it right then
>>this occurs.
>>
>>User 1 queues 20 ms of 3D commands
>>User 1 is pre-empted
>>User 2 wants the 2D engine
>>User 2 beings wait for 2D
>>User 2 sleeps
>>User 1 wakes
>>User 1 beings wait for 3D but discovers a claim is in progress
>>User 1 sleeps
>>User 2 wakes, runs commands
>
>
> This model destroys the parallel processing between the main CPU and the GPU.
And this is the reason that cards tend to do 2d and 3d through the same
command queue, and often the same hardware at the backend - there's no need on
such hardware to quiesce between acclerated 2d and 3d commands.
Of course, if either user ends up wanting to touch the framebuffer directly,
they will have to flush the queue & wait for quiescence. There's nothing
particularly 2D or 3D about this - they both have fallbacks, and they're both
faster if fallbacks can be avoided.
Keith (who has lost track of who's arguing about what or why)
On Sul, 2004-09-12 at 23:42, Dave Airlie wrote:
> The worst things that will happen for all concerened is this:
> Jon does all this work on a merged solution outside the kernel, and it
> works well, and the X team decide to do a decent X on mesa-solo on Jons
> super-DRM, now the super-DRM gets pushed via the X tree and distributions
> start relasing kernels with it merged into it
Unlikely. Its rapidly unmaintainable because the core kernel changes
will obsolete it (see for example KGI).
> I think yourself and Linus's ideas for a locking scheme look good, I also
> know they won't please Jon too much as he can see where the potential
> ineffecienes with saving/restore card state on driver swap are, especailly
> on running fbcon and X on a dual-head card with different users.
Well this is what I came up with so far. It creates a vga class so you
can bind the drivers to functions of the card (and we can add/remove
functions later as appropriate), tells functions about each other and
now implements Linux lock proposal as I understood it.
Alan
On Sun, 12 Sep 2004, Michel [ISO-8859-1] D?nzer wrote:
> On Sun, 2004-09-12 at 20:45 -0400, Vladimir Dergachev wrote:
>>
>> On Sun, 12 Sep 2004, Michel [ISO-8859-1] Dnzer wrote:
>>
>>> On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
>>>>
>>>> I think yourself and Linus's ideas for a locking scheme look good, I also
>>>> know they won't please Jon too much as he can see where the potential
>>>> ineffecienes with saving/restore card state on driver swap are, especailly
>>>> on running fbcon and X on a dual-head card with different users.
>>>
>>> Frankly, I don't understand the fuss about that. When you run a 3D
>>> client on X today, 3D client and X server share the accelerator with
>>> this scheme, and as imperfect as it is, it seems to do a pretty good job
>>> in my experience.
>>
>> Not that good - try dragging something while a DVD video is playing.
>
> What are you getting at?
The overlay window is currently using part of what is being proposed by
"multiple drivers" proponents. It has to make engine queiscent so it can
write data directly to the video memory. It does *not* have to save the
state.
So, as Jon rightly points out the "multiple drivers" scheme only makes
sense in the current usage patter - you either use X or framebuffer, never
both at the same time and you consider a few seconds per switch normal.
(Not that it actually has to take few seconds, I am just pointing out the
the expectations are well below what we do now)
However, if we want the switch from X to framebuffer to be as fast as
switching between different text consoles (assuming they have the same
resolution) and if we want to be able to run different Xservers on
different consoles or Xserver+framebuffer combinations Jon's proposal
wins.
best
Vladimir Dergachev
>
>
> --
> Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
> Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
On Mon, 13 Sep 2004 12:26:33 +0100, Alan Cox <[email protected]> wrote:
> Well this is what I came up with so far. It creates a vga class so you
> can bind the drivers to functions of the card (and we can add/remove
> functions later as appropriate), tells functions about each other and
> now implements Linux lock proposal as I understood it.
It needs something to sort out both drivers attaching to the IRQ.
It also needs something to sort out both drivers using pci_drvdata()
to get to their private data. For example in the hotplug routines you
only get passed a pdev and you want to use that to locate your private
data.
It also needs to track pci_enable_device() so that if one driver
unloads it won't turn the device off for the other driver.
VGA routing needs to be supported. I attached the code I was writing
for that. I was in the middle of writing it so it doesn't compile.
This code should be integrated into the VGA driver.
It needs to integrate into VGAcon. VGAcon should require the vga
device before loading. The resource reservation code in VGAcon needs
to be moved to the VGA driver. If you use a command to switch the
active VGA device, VGAcon needs to reset itself for the new device.
VGA driver needs to generate hotplug events for the VGA device that
indicate if they are primary or secondary. If they are secondary there
needs to be a user space reset program that uses the new ROM hooks to
reset the card.
It should support more than two drivers, I forgot to check, does it already?
fbdev takes a snapshot of the video registers when it loads. When you
unload it it writes those registers back. That doesn't work if you
load from an xterm and rmmod it from the command line. It snapshots
the card in graphics mode and then restores it in an environment
expecting text mode.
Something needs to be done for DMA processing. What if I get an
interrupt that the DMA queue has been completed but we've switched to
a driver that doesn't understand DMA? I guess the only safe thing to
do is make sure all DMA queue are finished before releasing control.
--
Jon Smirl
[email protected]
On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
>
> The overlay window is currently using part of what is being proposed by
> "multiple drivers" proponents. It has to make engine queiscent so it can
> write data directly to the video memory. It does *not* have to save the
> state.
It doesn't even really need to make the engine quiesce.
If two subsystems are aware of the locking rules (and the helper driver
obviously doesn't much care), they can just design their own handoff
trivially. For example, it might make sense to make the "wait for the
engine to stop" be the responsibility of the side that actually _needs_
it, namely the PIO user.
So if both users use the engine, not PIO, there's no need to ever stop the
engine. In my example of how to use the locking, it looked something like
this:
if (get_lock(data->gfx.accelerator)) {
/* Somebody else used the engine, need to re-load cached index */
mydev->offset = readl(mydev->mmio + OFFSET_PORT);
}
OUT_RING(mydev, cmd);
OUT_RING(mydev, arg);
put_lock(data->gfx.accelerator);
See? You can have two clients doing accelerator things, and they _never_
wait for anything (well, obviously "OUT_RING()" needs to wait for the
buffer to be empty enough ;).
They still need to know whether there was a previous user, because
efficient command filling does require that you don't read the "where is
the command buffer end" thing all the time, so that's why you have to
cache that one in real RAM instead of reading it from the card every op.
And because you cache it, you have to update your cache if somebody else
uses the engine.
Now, a PIO writer would look different
if (get_lock(data->gfx.accelerator)) {
/* Somebody else used the engine, need to quiesce */
wait_for_engine_idle(mydev);
}
outl(cmd, mydev->pio + OFFSET_CMD);
...
put_lock(data->gfx.accelerator);
and here if we switch back and forth between a client that uses
synchronous commands (ie normally PIO) rather than the engine, then yes,
we'd obviously halt the engine all the time. But hey, you can't avoid
that: if you want good performance with most modern chips, you do all your
work with the engine, not with synchronous commands.
> So, as Jon rightly points out the "multiple drivers" scheme only makes
> sense in the current usage patter - you either use X or framebuffer, never
> both at the same time and you consider a few seconds per switch normal.
I disagree. You can use a combination of X, framebuffer and "special
clients", where the special client can be _exactly_ things like video
overlays etc.
Now, obviously we'd wish that X has support for video overlays directly,
and thus you wouldn't even need to switch between clients at that level,
but there are certainly cases where you may end up with an "external
client". It might be some very card-specific thing that X or DRM just
doesn't support yet, so you whip up a quick client for just that.
For example (and this may be a horribly _bad_ example, for all I know),
let's say that somebody decides that they want to do a DirectX library,
and all the DRM people just throw their hands up in horror and say "over
my dead body".
In that case you have two choices: kill the DRM people and dance on their
graves, or just say "ok, I'll make this other client that does the DirectX
interfaces". And the thing is, it shouldn't fundamentally not work. As far
as I can tell, with some rudimentary locking support like the above (the
trivial part) and some memory management support (the _hard_ part), you
should be able to have the two clients work together quite well.
And yes, I realize that this is what DRM already does internally. I agree.
I applaud it. I'm saying that if we moved that internal locking to be
_external_, so that other clients can use it too, then fbcon and DRM and
some random new subsystem could all live together in peace and harmony.
Now, let's all sit around the fire and sing Kumbaya.
Linus
On Mon, 13 Sep 2004, Alan Cox wrote:
> On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
>> However, if we want the switch from X to framebuffer to be as fast as
>> switching between different text consoles (assuming they have the same
>> resolution) and if we want to be able to run different Xservers on
>> different consoles or Xserver+framebuffer combinations Jon's proposal
>> wins.
>
> It depends how the various components fit together. Clearly for Radeon
> you want everyone using the DMA command path when DRI is loaded. That
> doesn't require "one driver".
>
Alan, do I understand right that you are proposing to have two pieces of
code in the framebuffer - one that can program the card in the absence of
DRM driver and one that uses CP when it is present ?
best
Vladimir Dergachev
On Llu, 2004-09-13 at 15:52, Vladimir Dergachev wrote:
> However, if we want the switch from X to framebuffer to be as fast as
> switching between different text consoles (assuming they have the same
> resolution) and if we want to be able to run different Xservers on
> different consoles or Xserver+framebuffer combinations Jon's proposal
> wins.
It depends how the various components fit together. Clearly for Radeon
you want everyone using the DMA command path when DRI is loaded. That
doesn't require "one driver".
On Llu, 2004-09-13 at 16:20, Vladimir Dergachev wrote:
> > It depends how the various components fit together. Clearly for Radeon
> > you want everyone using the DMA command path when DRI is loaded. That
> > doesn't require "one driver"
>
> Alan, do I understand right that you are proposing to have two pieces of
> code in the framebuffer - one that can program the card in the absence of
> DRM driver and one that uses CP when it is present ?
We could do, or the DRM driver could provide DMA methods for the
framebuffer driver to use. I mean it might be that we should always be
using DMA methods in all the drivers for radeon all the time anyway ?
The fb driver gets told when DRI comes and goes which means the two can
choose to co-operate if they wish.
On Llu, 2004-09-13 at 16:06, Jon Smirl wrote:
> It also needs something to sort out both drivers using pci_drvdata()
> to get to their private data. For example in the hotplug routines you
> only get passed a pdev and you want to use that to locate your private
> data.
The hotplug routines for vga objects in the code I posted get passed
vga_dev objects. You can put what you like in those. I guessed at
"memory manager" "dri" and "framebuffer0" being the ones to create for
now but we can invent anything thats more appropriate.
> It also needs to track pci_enable_device() so that if one driver
> unloads it won't turn the device off for the other driver.
The ->remove function is passed the number of remaining clients for
exactly this reason. We could move the resource grabbing up the tree.
IRQ handling is rather harder. Quiescing and handing back the IRQ on
lock loss is ugggggggggly so I want to think about it - it works but its
not nice.
Should pci_enable and friends be done by the vga class driver- it can do
this and it would have to do it if it did the hotplug ?
> VGA routing needs to be supported. I attached the code I was writing
> for that. I was in the middle of writing it so it doesn't compile.
> This code should be integrated into the VGA driver.
Agreed.
> It needs to integrate into VGAcon. VGAcon should require the vga
> device before loading. The resource reservation code in VGAcon needs
> to be moved to the VGA driver. If you use a command to switch the
> active VGA device, VGAcon needs to reset itself for the new device.
I saw vgacon as being a client of the vga class driver like the various
fb drivers would be.
> VGA driver needs to generate hotplug events for the VGA device that
> indicate if they are primary or secondary. If they are secondary there
> needs to be a user space reset program that uses the new ROM hooks to
> reset the card.
The VGA driver at the moment doesn't really know about legacy vga space.
That was something I wanted to touch last of all because it is foul. It
can do this and as you say its the perfect person to issue the hotplug
notifications. It also needs to do it for vesafb so if it is handed an
ISA hole it can work out the right PCI device.
> It should support more than two drivers, I forgot to check, does it already?
As many as you want. Just change the array size or the number
registered. One neat trick we can support is adding extra devices when
necessary - thus if the boot code in user space boots a card and decides
its multihead we'd want to add extra heads.
> fbdev takes a snapshot of the video registers when it loads. When you
> unload it it writes those registers back. That doesn't work if you
> load from an xterm and rmmod it from the command line. It snapshots
> the card in graphics mode and then restores it in an environment
> expecting text mode.
Big lock issue. You get told if someone else ate your environment. Being
more polite about that would help performance a ton. You know who had
the lock before and who has it now - so we can be intelligent about
->release cleanup I hope. (eg FB0 finds FB1 had it last it might do a
minimal restore)
> Something needs to be done for DMA processing. What if I get an
> interrupt that the DMA queue has been completed but we've switched to
> a driver that doesn't understand DMA? I guess the only safe thing to
> do is make sure all DMA queue are finished before releasing control.
The ->remove path takes the lock (so calls ->release) and then drops it
with no callback needed so providing the hand over code is robust this
will come for free.
Alan
On Mon, 2004-09-13 at 10:52 -0400, Vladimir Dergachev wrote:
>
> So, as Jon rightly points out the "multiple drivers" scheme only makes
> sense in the current usage patter - you either use X or framebuffer, never
> both at the same time and you consider a few seconds per switch normal.
You are mixing up things. VT switch != context switch.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
Doesn't the base platform need to be designed to also treat individual
heads as resources?
fbdev only sets the mode on a single head. My cards have more that one
head. When I tried adding mode setting to DRM so that I could handle
my other heads there was a big uproar that fbdev owns mode setting and
that code shouldn't be duplicated. Making fbdev support more than one
head means that it's API has to be redesigned. DRM doesn't have a mode
API so one can be designed from scratch.
In a two head system with simultaneous users, one using fbdev console
and the other playing a 3D game, how is this locking thing going to
work on a process swap basis? Even though we don't have the code for
this today the architecture needs to be designed for it. The reason
you can't do this today is because the kernel level drivers won't
allow it, you can do this currently from the X server.
Heads need to stay in an "unassigned state" until someone logs in on
them. This allows a head to issue a request for "merged fb" mode and
take over the other head. This may require some creativity for drawing
the log in prompts.
Don't forget about SAK and drawing prompts that can't be spoofed.
--
Jon Smirl
[email protected]
On Mon, 2004-09-13 at 02:05 -0400, Alex Deucher wrote:
> On Sun, 12 Sep 2004 20:45:18 -0400 (EDT), Vladimir Dergachev
> <[email protected]> wrote:
> >
> >
> > On Sun, 12 Sep 2004, Michel [ISO-8859-1] D�nzer wrote:
> >
> > > On Sun, 2004-09-12 at 23:42 +0100, Dave Airlie wrote:
> > >>
> > >> I think yourself and Linus's ideas for a locking scheme look good, I also
> > >> know they won't please Jon too much as he can see where the potential
> > >> ineffecienes with saving/restore card state on driver swap are, especailly
> > >> on running fbcon and X on a dual-head card with different users.
> > >
> > > Frankly, I don't understand the fuss about that. When you run a 3D
> > > client on X today, 3D client and X server share the accelerator with
> > > this scheme, and as imperfect as it is, it seems to do a pretty good job
> > > in my experience.
> >
> > Not that good - try dragging something while a DVD video is playing.
>
> The overlay could be converted to use the CP engine as well. right now
> it has to switch to MMIO for overlay.
The question is whether that matters at all, i.e. whether the registers
used for the overlay are FIFO'd.
Either way, I don't see how this is related to the way DRM context
switches are handled.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
On Llu, 2004-09-13 at 17:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
Already covered - although at the moment the question is open about who
tells the vga generic code "It has 4 heads" ?
Had a look over your class code - its nice and it should integrate
really easily as well as remove most of the PCI layer patching it now
does.
Alan
How's this going to work with hotplug? Hotplug works by associating a
device with a driver by the PCI ID table contained in the driver. Both
the fbdev and DRI drivers currently contain the same PCI IDs for the
cards that the chipsets they support.
So when a card gets hotplugged, which driver do I load? If it's the
VGA driver, then how do I tell the VGA driver that I want to use fbdev
or DRM? What if I want a different one on each head?
There is one VGA driver and multiple fbdev/DRM drivers, one for each chipset.
I guess you need to build something into the VGA driver that gets the
PCI ID tables out of the various fbdev/DRM drivers and combine them
into a single table visible to hotplug. Then let the VGA driver take
the hotplug event. The VGA driver can then search it's table and
figure out which driver to initialize.
What if I have two identical PCI video cards. Don't we need an
initialization file to say load DRM on the one in slot 1 and fbdev on
the one in slot 2?
--
Jon Smirl
[email protected]
It wasn't intended to stay in the PCI layer. Something needs to be
done about hotplugging bridges. There aren't callouts from the PCI
layer for that. A hotplugged bridge can be capable of VGA routing and
have VGA devices behind it. I just started off in the PCI layer while
I figured out what hooks were needed. If a VGA capable bridge is
hotplugged, the VGA driver needs to know about it since it has to
create sysfs attributes and directories for it.
Another solution would be to split it. VGA attributes for the bridges
would be handled by the PCI layer. The other stuff by the VGA driver.
The driver has to have a few capabilities:
1) Turn off all VGA devices in this "VGA space". This is needed
because resetting a card is going to turn on it's VGA mode and we
can't have more than one.
2) It can't rely on the kernel structures representing the VGA state
or bridge routing state. For example the reset program is going to
turn a VGA device on without telling the kernel. There are other
things like X that do VGA programming from user space. Instead of
using the structure you need to query the hardware.
3) Activate a new VGA device. The only safe way to do this is to turn
off all devices using function #1 first. User space may have turned a
device on with telling the kernel. Activating a new device need to
tell vgacon about new screen size/mode.
sysfs looks like this:
/class/vga
vga0
vga1 --- one for each "VGA space"
/class/vga/vga0/dev - causes hotplug to create /dev/vga0. I used the
major from DRM and started the minors at 512.
/class/vga/vga0/vga - setting this attribute to zero turns off all VGA
devices in this space
/class/vga/vga0/* - links to all of the VGA devices in this "VGA space"
/class/vga/vga0/0000:01:00.0/vga - set this to one to enable a
specific VGA device. As a side effect it will always disable all other
VGA device in this space.
Each PCI bridge device has a vga attribute indicating it's state of
VGA routing. These are readonly. The actual bridge routing state is
set as a function of activating a new VGA device.
The IA64 people want a file/ioctl interface on the /dev/vga0 devices
so that they can issue control calls to the active device in each "VGA
space"
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote:
> The IA64 people want a file/ioctl interface on the /dev/vga0 devices
> so that they can issue control calls to the active device in each "VGA
> space"
I think ppc and sparc want this too, we'll use it for issuing legacy in/out.
Thanks,
Jesse
How would any of these plans handle power management and ACPI events?
I'd like to be able to suspect my laptop with the DRI enabled, or have
the DDX (or whatever) handle acpi lid and button events or put the
chip into various power modes.
Alex
On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus Torvalds
<[email protected]> wrote:
>
>
> On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
> >
> > The overlay window is currently using part of what is being proposed by
> > "multiple drivers" proponents. It has to make engine queiscent so it can
> > write data directly to the video memory. It does *not* have to save the
> > state.
>
> It doesn't even really need to make the engine quiesce.
>
> If two subsystems are aware of the locking rules (and the helper driver
> obviously doesn't much care), they can just design their own handoff
> trivially. For example, it might make sense to make the "wait for the
> engine to stop" be the responsibility of the side that actually _needs_
> it, namely the PIO user.
>
> So if both users use the engine, not PIO, there's no need to ever stop the
> engine. In my example of how to use the locking, it looked something like
> this:
>
> if (get_lock(data->gfx.accelerator)) {
> /* Somebody else used the engine, need to re-load cached index */
> mydev->offset = readl(mydev->mmio + OFFSET_PORT);
> }
> OUT_RING(mydev, cmd);
> OUT_RING(mydev, arg);
> put_lock(data->gfx.accelerator);
>
> See? You can have two clients doing accelerator things, and they _never_
> wait for anything (well, obviously "OUT_RING()" needs to wait for the
> buffer to be empty enough ;).
>
> They still need to know whether there was a previous user, because
> efficient command filling does require that you don't read the "where is
> the command buffer end" thing all the time, so that's why you have to
> cache that one in real RAM instead of reading it from the card every op.
> And because you cache it, you have to update your cache if somebody else
> uses the engine.
>
> Now, a PIO writer would look different
>
> if (get_lock(data->gfx.accelerator)) {
> /* Somebody else used the engine, need to quiesce */
> wait_for_engine_idle(mydev);
> }
> outl(cmd, mydev->pio + OFFSET_CMD);
> ...
> put_lock(data->gfx.accelerator);
>
> and here if we switch back and forth between a client that uses
> synchronous commands (ie normally PIO) rather than the engine, then yes,
> we'd obviously halt the engine all the time. But hey, you can't avoid
> that: if you want good performance with most modern chips, you do all your
> work with the engine, not with synchronous commands.
>
> > So, as Jon rightly points out the "multiple drivers" scheme only makes
> > sense in the current usage patter - you either use X or framebuffer, never
> > both at the same time and you consider a few seconds per switch normal.
>
> I disagree. You can use a combination of X, framebuffer and "special
> clients", where the special client can be _exactly_ things like video
> overlays etc.
>
> Now, obviously we'd wish that X has support for video overlays directly,
> and thus you wouldn't even need to switch between clients at that level,
> but there are certainly cases where you may end up with an "external
> client". It might be some very card-specific thing that X or DRM just
> doesn't support yet, so you whip up a quick client for just that.
>
> For example (and this may be a horribly _bad_ example, for all I know),
> let's say that somebody decides that they want to do a DirectX library,
> and all the DRM people just throw their hands up in horror and say "over
> my dead body".
>
> In that case you have two choices: kill the DRM people and dance on their
> graves, or just say "ok, I'll make this other client that does the DirectX
> interfaces". And the thing is, it shouldn't fundamentally not work. As far
> as I can tell, with some rudimentary locking support like the above (the
> trivial part) and some memory management support (the _hard_ part), you
> should be able to have the two clients work together quite well.
>
> And yes, I realize that this is what DRM already does internally. I agree.
> I applaud it. I'm saying that if we moved that internal locking to be
> _external_, so that other clients can use it too, then fbcon and DRM and
> some random new subsystem could all live together in peace and harmony.
>
> Now, let's all sit around the fire and sing Kumbaya.
>
> Linus
>
>
>
>
>
Alex Deucher wrote:
>How would any of these plans handle power management and ACPI events?
>I'd like to be able to suspect my laptop with the DRI enabled, or have
>the DDX (or whatever) handle acpi lid and button events or put the
>chip into various power modes.
>
>Alex
>
>
Since I've been doing a little bit of ACPI hacking (and gained a bit of
understanding of it), I think I should probably speak on this one.
With the current ACPI infrastructure, you don't have the DDX or whatever
catching ACPI events -- acpid catches ACPI events, and does appropriate
things via scripts. So lid and button events can do things, but -- X
doesn't handle them. Scripts called by acpid do.
As to putting chips into various power modes -- wouldn't this be better
off in kernel, not in X? My impression is that this wouldn't be a large
amount of code. It could also abstract away some details of chip power
management -- it could (potentially) not matter if it's done via ACPI or
via a custom bit of code for a chip. And it could expose a file in sysfs
to adjust power settings for the graphics chip. Then the system that
exists for handling ACPI events can happily keep being how it is.
Yu, Luming has been doing a lot of work in the area of a generic ACPI
"video features" driver -- such a driver could do such things as change
which heads are enabled, set backlight power, and generally muck with
graphics state. I suspect some possible nasty interaction could happen,
since ACPI could affect graphics state in some pretty hairy ways. It
might be a good idea to get in contact with him before the user emails
show up...
David Bronaugh
ps: I kinda trimmed the CC: list on this
On Mon, 13 Sep 2004 13:42:19 -0700, David Bronaugh
<[email protected]> wrote:
> Alex Deucher wrote:
>
> >How would any of these plans handle power management and ACPI events?
> >I'd like to be able to suspect my laptop with the DRI enabled, or have
> >the DDX (or whatever) handle acpi lid and button events or put the
> >chip into various power modes.
> >
> >Alex
> >
> >
> Since I've been doing a little bit of ACPI hacking (and gained a bit of
> understanding of it), I think I should probably speak on this one.
>
> With the current ACPI infrastructure, you don't have the DDX or whatever
> catching ACPI events -- acpid catches ACPI events, and does appropriate
> things via scripts. So lid and button events can do things, but -- X
> doesn't handle them. Scripts called by acpid do.
>
> As to putting chips into various power modes -- wouldn't this be better
> off in kernel, not in X? My impression is that this wouldn't be a large
> amount of code. It could also abstract away some details of chip power
> management -- it could (potentially) not matter if it's done via ACPI or
> via a custom bit of code for a chip. And it could expose a file in sysfs
> to adjust power settings for the graphics chip. Then the system that
> exists for handling ACPI events can happily keep being how it is.
>
> Yu, Luming has been doing a lot of work in the area of a generic ACPI
> "video features" driver -- such a driver could do such things as change
> which heads are enabled, set backlight power, and generally muck with
> graphics state. I suspect some possible nasty interaction could happen,
> since ACPI could affect graphics state in some pretty hairy ways. It
> might be a good idea to get in contact with him before the user emails
> show up...
It seems to be that this kind of necessitates some sort of kernel mode
driver to handle everything (albeit perhaps with lots of userspace
libs). I can't see how a generic video acpi driver would play nice
with a userspace X, fbdev, and whever else my be using the hardware.
It's not that I don't like the idea of letting everyone play I just
want to use my hardware to its fully functionality wihtout a million
kludges everywhere. OTOH, maybe it'll all just work. I'm not too
familiar with the ins and outs of ACPI and what's need on the chip
side vs. generic vs. machine specific. Stuff like enabling outputs
and changine power states is chip specific though and it would need to
play nice.
Alex
>
> David Bronaugh
>
> ps: I kinda trimmed the CC: list on this
>
On Tuesday 14 September 2004 00:28, Jon Smirl wrote:
> Doesn't the base platform need to be designed to also treat individual
> heads as resources?
>
> fbdev only sets the mode on a single head. My cards have more that one
> head. When I tried adding mode setting to DRM so that I could handle
> my other heads there was a big uproar that fbdev owns mode setting and
> that code shouldn't be duplicated. Making fbdev support more than one
> head means that it's API has to be redesigned.
What do you mean?
Your driver has 2 heads, both of which have independent outputs and
separate framebuffers, then register your driver twice:
display0->fb0->framebuffer0-|
common par
display1->fb1->framebuffer1-|
Or outputs are interdependent with a common framebuffer, then register the
driver once:
par0
display0->fb0->framebuffer-|
par1
Or outputs are independent, but shares a common framebuffer, then register
driver twice, each info with the same pointer to framebuffer:
par0
display0->fb0-|
framebuffer
display1->fb1-|
par1
Tony
On Llu, 2004-09-13 at 18:50, Jon Smirl wrote:
> How's this going to work with hotplug? Hotplug works by associating a
> device with a driver by the PCI ID table contained in the driver. Both
> the fbdev and DRI drivers currently contain the same PCI IDs for the
> cards that the chipsets they support.
Insert card
pc layer calls hotplug
hotplug loads vga driver
pci layer calls vga driver
vga driver generates hotplug event
hotplug loads stuff (user policy)
vga driver calls hotplugged drivers
> I guess you need to build something into the VGA driver that gets the
> PCI ID tables out of the various fbdev/DRM drivers and combine them
> into a single table visible to hotplug. Then let the VGA driver take
> the hotplug event. The VGA driver can then search it's table and
> figure out which driver to initialize.
Thats what it does. The vga_device_register functions take a vga_driver
object which is a PCI driver lookalike with an extra field of "type" so
you can load DRM's, FB's etc
> What if I have two identical PCI video cards. Don't we need an
> initialization file to say load DRM on the one in slot 1 and fbdev on
> the one in slot 2?
Possibly, thats for hotplug user space policy.
Alan