Re: radeon-pre-2
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 Dnzer | 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
--- 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 --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
--- 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 --- 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
[ dri-Bugs-1026326 ] MESA_ycbcr not working correctly with radeon (M9000)
Bugs item #1026326, was opened at 2004-09-11 13:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=1026326group_id=387 Category: None Group: None Status: Open Priority: 5 Submitted By: Stefan Brüns (stefanbr) Assigned to: Nobody/Anonymous (nobody) Summary: MESA_ycbcr not working correctly with radeon (M9000) Initial Comment: Trying to use YUV on Radeon Mobility 9000 results in the right texture with wrong colors. Seems like the color components dont get calculated correctly, the colors are the same as one would set Y=G;Cb=B;Cr=R. Or written in Matrix form: |R| | 0 0 1 | | Y | |G| = | 1 0 0 | * | Cb | |B| | 0 1 0 | | Cr | Correct Matrix would be | 1.00 0.00 1.40 | | 1.00 -.34 -.71 | | 1.00 1.77 0.00 | Seems to be a bug in the radeon driver, mga and mesasoft work. Tested with the MESA yuvrect and yuvsquare examples. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=1026326group_id=387 --- 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
Re: locate of drm.h
On Sad, 2004-09-11 at 00:25, Jon Smirl wrote: I need a major number for the VGA device. Use one of the experimental ones (see Documentation/devices.txt). As and if the driver becomes mainstream kernel material apply for one via LANANA. I don't know what the *BSD procedures are. --- 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
Re: New version of dyn-minor.patch
On Sad, 2004-09-11 at 00:36, Jon Smirl wrote: inter_module can't be removed until we move to the drm_core design with personality modules Of course it can go. You just fix up the DRI to start using try_module_get(). Actually when you have the video class driver layer it all comes for free anyway. The DRM(probe) macro is there for the same reason. Without the macro if you link two DRM drivers into the kernel you'll get symbol Then I don't see why you've suddenely made it required undoing cleanup that had been done ? Why does the minors patch suddenely introduce this specific requirement ? Alan --- 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
Re: locate of drm.h
On 11.09.2004, at 14:50, Alan Cox wrote: On Sad, 2004-09-11 at 00:25, Jon Smirl wrote: I need a major number for the VGA device. Use one of the experimental ones (see Documentation/devices.txt). As and if the driver becomes mainstream kernel material apply for one via LANANA. I don't know what the *BSD procedures are. different. i mean, within the BSDs :) just use one. i'd say somebody will fix it if the major is already used somewhere else. cheers simon -- /\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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
---
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
Re: UT2004 freeze when shooting with Shock Rifle
On Fri, 10 Sep 2004 19:52:55 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote: Hi all , I've posted for AA few days ago, and I'm here again :) Now the problem is with UT2004 . My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the lastest taken yesterday from CVS. I've downloaded the demo , and the game seemed to run fine at least until I tried to shoot with a Shock Rifle . Just after the laser beam started to run from my rifle to the target the system simply freezed . I've tried all the sort of workarounds , disable all effects, running at 640x480 at 16bit , disable TCL , disable Texture Units etc etc ... no way. I've enabled the NMI Watchdog and after that I can SSH into the system and try to reboot (the system doesn't reboot, but seem that the filesystems are umounted anyway) . It's a pity, because the game runs fine until the player or a BOT try to shoot with the Shock Rifle . Thanks for your work :) Bye Marcello Here my GLXINFO: [EMAIL PROTECTED]:~$ glxinfo -l name of display: :0.0 Mesa: software DXTn compression/decompression available display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20040906 AGP 1x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_S3_s3tc OpenGL limits: GL_MAX_ATTRIB_STACK_DEPTH = 16 GL_MAX_CLIENT_ATTRIB_STACK_DEPTH = 16 GL_MAX_CLIP_PLANES = 6 GL_MAX_COLOR_MATRIX_STACK_DEPTH = 4 GL_MAX_ELEMENTS_VERTICES = 3000 GL_MAX_ELEMENTS_INDICES = 3000 GL_MAX_EVAL_ORDER = 30 GL_MAX_LIGHTS = 8 GL_MAX_LIST_NESTING = 64 GL_MAX_MODELVIEW_STACK_DEPTH = 32 GL_MAX_NAME_STACK_DEPTH = 64 GL_MAX_PIXEL_MAP_TABLE = 256 GL_MAX_PROJECTION_STACK_DEPTH = 32 GL_MAX_TEXTURE_STACK_DEPTH = 10 GL_MAX_TEXTURE_SIZE = 1024 GL_MAX_3D_TEXTURE_SIZE = 64 GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 256 GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 1024 GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB = 7 GL_MAX_TEXTURE_UNITS_ARB = 6
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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) --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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). --- 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
Re: New version of dyn-minor.patch
On Sat, 11 Sep 2004 13:53:41 +0100, Alan Cox [EMAIL PROTECTED] wrote: On Sad, 2004-09-11 at 00:36, Jon Smirl wrote: inter_module can't be removed until we move to the drm_core design with personality modules Of course it can go. You just fix up the DRI to start using try_module_get(). Actually when you have the video class driver layer it all comes for free anyway. I haven't used try_mode_get(); not sure what the BSD impacts are. The inter_module stuff has been in DRM since it was originally written. I just moved the exisiting code around a little. The DRM(probe) macro is there for the same reason. Without the macro if you link two DRM drivers into the kernel you'll get symbol Then I don't see why you've suddenely made it required undoing cleanup that had been done ? Why does the minors patch suddenely introduce this specific requirement ? The probe function was static before. Now it is a different file and requires the DRM() macro. I did it that was to minimize the diffs, if I move the functions around I would triple the size of the diffs. Alan -- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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. --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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:
*/
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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 Dnzer | 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
Re: radeon-pre-2
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] --- 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
R300 progress/help wanted
Hi all, I have made some moderate progress in getting R300 3d to play nicely, you can see the results at http://volodya-project.sf.net/R300.php So people with Radeon R300 or later cards that want to experiment with their powerful GPUs can try out the code and mess with it at the level fairly close to hardware, but not so close as to require a register manual (which we don't have). In particular two tools are now available: glxtest - allows to exercise any 3d driver and dump contents of memory maps produced by 3d drawing commands. There is a small utility to pretty print Radeon command stream and autogenerate C code based on it. drmtest - paints a triangle and a square using RV350 GPU, In order to better understand what is going on it helps to go to Microsoft site and read up on DirectX 9.0 - these cards were meant to work with it and thus many formats (and calls) are accepted as is. In essense, description of DirectX 9.0 programmable shaders is a high-level description of the hardware - which is not that high, more like knee-level. Also you might find examining the sources (or, at least, register headers) of Radeon drivers (Xorg, DRI, DRM, etc) useful. have fun ! Vladimir Dergachev --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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 --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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 ;-) --- 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
Re: radeon-pre-2
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? --- 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
Re: radeon-pre-2
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] --- 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
Re: radeon-pre-2
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] --- 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
Re: UT2004 freeze when shooting with Shock Rifle
Marcello Maggioni wrote: My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the lastest taken yesterday from CVS. I've downloaded the demo , and the game seemed to run fine at least until I tried to shoot with a Shock Rifle . Just after the laser beam started to run from my rifle to the target the system simply freezed . No one has ideas or info about this? I think some time ago it was suggested to create a small, empty room and fire the shock rifle in that (and log the commands submitted to the gpu) to see what's going on. I'll might just do that if I find some time, though the fact that the lockup doesn't happen on anything else than real R200 and not the derivative chips doesn't really help (and it does not only not lockup on rv250, but actually looks correct too). Roland --- 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
Re: UT2004 freeze when shooting with Shock Rifle
On Sun, 12 Sep 2004 00:34:01 +0200, Roland Scheidegger [EMAIL PROTECTED] wrote: Marcello Maggioni wrote: My card is a 3D prophet Radeon 8500LE with R200 ,My drivers are the lastest taken yesterday from CVS. I've downloaded the demo , and the game seemed to run fine at least until I tried to shoot with a Shock Rifle . Just after the laser beam started to run from my rifle to the target the system simply freezed . No one has ideas or info about this? I think some time ago it was suggested to create a small, empty room and fire the shock rifle in that (and log the commands submitted to the gpu) to see what's going on. I'll might just do that if I find some time, though the fact that the lockup doesn't happen on anything else than real R200 and not the derivative chips doesn't really help (and it does not only not lockup on rv250, but actually looks correct too). Roland Hi . I've heard of this . I can do those test if you can tell me how to catch the commands submitted to the GPU into a file or in some other ways . Thanks for your work Marcello --- 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
Re: New version of dyn-minor.patch
On Sat, 11 Sep 2004 11:54:49 -0400, Jon Smirl [EMAIL PROTECTED] wrote: On Sat, 11 Sep 2004 13:53:41 +0100, Alan Cox [EMAIL PROTECTED] wrote: On Sad, 2004-09-11 at 00:36, Jon Smirl wrote: inter_module can't be removed until we move to the drm_core design with personality modules Of course it can go. You just fix up the DRI to start using try_module_get(). Actually when you have the video class driver layer it all comes for free anyway. I haven't used try_module_get(); not sure what the BSD impacts are. The inter_module stuff has been in DRM since it was originally written. I just moved the exisiting code around a little. I just looked at try_module_get(), it only works if you know what module you are trying to find. This would work for the drm_core case where each personality is trying to find the core. I don't see how it helps the current case where the personalities need to find each other and they can have arbitrary module names. We know how to remove the DRM() macros and inter_module stuff by switching to a drm_core library model. DaveA has already coded up a prototype. We aren't switching because people are objecting to the change. I'm not sure what the status of the objections is, Dave knows more about this. The objection is something along the lines of what if I have drm_core linked into my kernel and I want to update to drivers that use a different drm_core. -- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
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 --- 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
Re: radeon-pre-2
--- 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 --- 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
Re: New version of dyn-minor.patch
On 12.09.2004, at 01:58, Jon Smirl wrote: We know how to remove the DRM() macros and inter_module stuff by switching to a drm_core library model. DaveA has already coded up a prototype. We aren't switching because people are objecting to the change. I'm not sure what the status of the objections is, Dave knows more about this. The objection is something along the lines of what if I have drm_core linked into my kernel and I want to update to drivers that use a different drm_core. Is there a way to enforce both drm_core and personality (linked together, not exporting symbols maybe) to be in core or none (which would mean both being modules and thus no problem)? cheers simon -- /\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
