snapshot 20050610 [i810]
I'm not sure if this is a bug in the snapshot or due to my setup... I have a Samsung X20 with an Intel i915GM graphics chip running under Mandrake LE2005. The latter has a 2.6.11 kernel and Xorg 6.8.2. I have installed both the common-20050610 and i810-20050610 snapshots over the X.org distribution as provided by Mandrake. After that, the graphics card is recognised, and I can run X with the i810 driver. This wasn't possible with the original Mandrake setup. When running tuxracer, however, an (error) message saying Unrecognized deviceID 2592 (or similar; I'm typing this from memory) is issued. The graphics then is extremely slow, so I assume that the hardware acceleration doesn't work (?). I have found the same (hex) device ID at the end of drm_pciids.h, where it is part of the definition for i915_PCI_IDS. Where does the error message from, and what would I have to fix to get this going? Thank you very much, and kind regards, Christian. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: snapshot 20050610 [i810]
On Thu, Jun 16, 2005 at 11:21:52 +0100, Christian Marquardt wrote: I'm not sure if this is a bug in the snapshot or due to my setup... I have a Samsung X20 with an Intel i915GM graphics chip running under Mandrake LE2005. The latter has a 2.6.11 kernel and Xorg 6.8.2. I have installed both the common-20050610 and i810-20050610 snapshots You've picked the wrong snapshot for the i915GM chip. You need i915-20050610 instead of i810-20050610. Alan. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300-commit] r300_driver/r300 r300_reg.h,1.44,1.45 r300_state.c,1.112,1.113
On Thursday 16 June 2005 13:41, Aapo Tahkola wrote: Update of /cvsroot/r300/r300_driver/r300 In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6333 Modified Files: r300_reg.h r300_state.c Log Message: Use depth tiling. Will this work with software fallbacks? cu, Nicolai pgpV14VXQ7uoa.pgp Description: PGP signature
[Bug 3549] New: drm power management does not dereference sysdev correctly
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3549
Summary: drm power management does not dereference sysdev
correctly
Product: DRI
Version: DRI CVS
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DRM modules
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
In linux-core drm_pm.c, CVS version 1.1, the drm_pm_setup function registers
the drm device's sysdev field with the power manager, but when the drm_suspend
or drm_resume functions are called, the functions think that they have received
a drm_device ptr, and not a power management sys_device ptr, and perform an
incorrect typecast. They dereference the sys_device as if it were a drm_device,
get an invalid value for the drm driver field, and go off into the weeds.
Another issue is that Linux kernel 2.6.11 (?) has changed the argument that it
passes to power management functions from an unsigned int to a pm_message_t
struct.
The attached patch fixes this behavior using a union struct, and also makes
drm_pm.c and drmP.h compatible with the new style pm_message_t arguments.
Unfortunately it doesn't preserve backward compatibility with older kernels.
Index: drmP.h
===
RCS file: /cvs/dri/drm/linux-core/drmP.h,v
retrieving revision 1.147
diff -c -r1.147 drmP.h
*** drmP.h 4 Jun 2005 06:18:10 - 1.147
--- drmP.h 16 Jun 2005 13:09:59 -
***
*** 515,520
--- 515,534
struct task_struct *task;
} drm_vbl_sig_t;
+
+ /**
+ * union struct that can either be a PM sys_device or a drm_sys_device
+ */
+ typedef struct drm_sysdev {
+ struct sys_devicesysdev;
+ struct drm_device* dev;
+ } drm_sysdev_t;
+
+ union drm_sysdev_data {
+ struct sys_device sysdev;
+ struct drm_sysdev drmdev;
+ };
+
/**
* DRM driver structure. This structure represent the common code for
* a family of cards. There will one drm_device for each card present
***
*** 723,729
drm_local_map_t *agp_buffer_map;
drm_head_t primary; /** primary screen head */
! struct sys_device sysdev; /** Power Management device structure
*/
int sysdev_registered; /** Whether the device has been
registered */
} drm_device_t;
--- 737,743
drm_local_map_t *agp_buffer_map;
drm_head_t primary; /** primary screen head */
! union drm_sysdev_data sysdev; /** union PM structure */
int sysdev_registered; /** Whether the device has been
registered */
} drm_device_t;
Index: drm_pm.c
===
RCS file: /cvs/dri/drm/linux-core/drm_pm.c,v
retrieving revision 1.1
diff -c -r1.1 drm_pm.c
*** drm_pm.c28 May 2005 00:00:08 - 1.1
--- drm_pm.c16 Jun 2005 13:09:59 -
***
*** 36,56
#include linux/device.h
#include linux/sysdev.h
! static int drm_suspend(struct sys_device *sysdev, u32 state)
{
! drm_device_t *dev = (drm_device_t *)sysdev;
!
! DRM_DEBUG(%s state=%d\n, __FUNCTION__, state);
if (dev-driver-power)
! return dev-driver-power(dev, state);
else
return 0;
}
static int drm_resume(struct sys_device *sysdev)
{
! drm_device_t *dev = (drm_device_t *)sysdev;
DRM_DEBUG(%s\n, __FUNCTION__);
--- 36,60
#include linux/device.h
#include linux/sysdev.h
! static int drm_suspend(struct sys_device *sysdev, pm_message_t state)
{
!
! int event;
!
! drm_device_t *dev = ((drm_sysdev_t *) sysdev)-dev;
! event = state.event;
+ DRM_DEBUG(%s state=%d\n, __FUNCTION__, event);
+
if (dev-driver-power)
! return dev-driver-power(dev, event);
else
return 0;
}
static int drm_resume(struct sys_device *sysdev)
{
! drm_device_t *dev = ((drm_sysdev_t *) sysdev)-dev;
DRM_DEBUG(%s\n, __FUNCTION__);
***
*** 79,91
DRM_DEBUG(%s\n, __FUNCTION__);
! dev-sysdev.id = dev-primary.minor;
! dev-sysdev.cls = drm_sysdev_class;
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,4)
! error = sys_device_register(dev-sysdev);
#else
! error = sysdev_register(dev-sysdev);
#endif
if(!error)
dev-sysdev_registered = 1;
--- 83,96
DRM_DEBUG(%s\n,
[Bug 3549] drm power management does not dereference sysdev correctly
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3549 --- Additional Comments From [EMAIL PROTECTED] 2005-06-16 06:22 --- Created an attachment (id=2896) -- (https://bugs.freedesktop.org/attachment.cgi?id=2896action=view) Fix incorrect argument passing in pm callback -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 16 Jun 2005, Jon Smirl wrote: On 6/16/05, Keith Whitwell [EMAIL PROTECTED] wrote: But, if you implement your scheme, by the same logic you need another 512mb of system ram just to make things work. If you've got all that extra ram hanging around, you could implement the single copy scheme and when a suspend occurs, pull the vram back to that extra system ram (which you would have needed anyway), rather than going to disk. The only way to preserve the VRAM contents across suspend/VT swap is to copy it to system RAM. The fbdev drivers can do this, but they don't know what is important in VRAM and what can be regenerated so they just have to copy the whole 512MB (15 seconds). The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a Stupid question - why can't one add a call to fb to register additional suspend/resume hooks ? This should not be too controversial. best Vladimir Dergachev texture copy is kept in system RAM doesn't depend on the DRM driver having suspend/VT swap hooks since it is able to rebuild VRAM at any point. So, given the way things are now, we have to pick one of the first two choices. Doing anything else (like doing a minimal copy out of VRAM) requires the drivers to be linked. Too many people are opposed to merging DRM/fbdev for that to happen. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 16 Jun 2005, Jon Smirl wrote: On 6/16/05, Keith Whitwell [EMAIL PROTECTED] wrote: But, if you implement your scheme, by the same logic you need another 512mb of system ram just to make things work. If you've got all that extra ram hanging around, you could implement the single copy scheme and when a suspend occurs, pull the vram back to that extra system ram (which you would have needed anyway), rather than going to disk. The only way to preserve the VRAM contents across suspend/VT swap is to copy it to system RAM. The fbdev drivers can do this, but they don't know what is important in VRAM and what can be regenerated so they just have to copy the whole 512MB (15 seconds). The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a Stupid question - why can't one add a call to fb to register additional suspend/resume hooks ? This should not be too controversial. Because x86 users don't want fbdev loaded. They use VGA console instead. I had code in DRM that looked for fbdev, and then if fbdev wasn't loaded DRM would register it resources, hook to interrupts, suspend, etc. But the patches were rejected by the kernel people. Another proposal is to write a third stub driver. This driver would hook to the ints, suspend, etc. Then DRM and fbdev would register with it. This would work but nobody wants to fix 67 fbdev drivers to use it. There is also kickback from the BSD people. There is a bunch of code duplicated between fbdev and DRM. The copy in DRM can be removed and fbdev called, but BSD doesn't have fbdev. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Philip Armstrong [EMAIL PROTECTED] wrote: On Thu, Jun 16, 2005 at 11:49:41AM -0400, Jon Smirl wrote: Another proposal is to write a third stub driver. This driver would hook to the ints, suspend, etc. Then DRM and fbdev would register with it. This would work but nobody wants to fix 67 fbdev drivers to use it. If a new architecture gets buy-in from the assorted developers, then the conversion can be done incrementally (ie one driver at a time) can't it? There shouldn't be a need for a flag day. Please enlighten me if there's some reason why converting the radeon fbdev / drm drivers might depend on whether the rest of fbdev has been converted or not! There is also kickback from the BSD people. There is a bunch of code duplicated between fbdev and DRM. The copy in DRM can be removed and fbdev called, but BSD doesn't have fbdev. Can that code not be moved into the BSD-specific drm directory as part of the above refactoring? ISTR that you'd done some of this already Jon. Is that code actually available anywhere? There are no technical problems with doing any of this, it is just that nobody wants to do the work. We shouldn't change the fbdev architecture without at least having someone on the hook for changing all of the drivers. You don't want to convert ten and not the others, then we effectively have two fbdev systems to maintain. My opinion is to just leave fbdev alone and tap into the existing drivers. Splitting all those drivers on all those platforms just isn't going to happen. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3552] New: i810 DRM module does not initialize
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3552 Summary: i810 DRM module does not initialize Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] The i810 module from the 2005-05-30 DRI CVS snapshot does not initialise properly with these error messages: [drm] Initialized drm 1.0.0 20040925 [drm:fill_in_dev] *ERROR* Cannot initialize the agpgart module. DRM: Fill_in_dev failed. However, the intel-agp module was loaded previously and initialized successfully: agpgart: Detected an Intel i810 DC100 Chipset. agpgart: Maximum main memory to use for agp memory: 148M agpgart: detected 4MB dedicated video ram. agpgart: AGP aperture is 32M @ 0xe600 Looks like the problem is that the drm_device_is_agp() test fails, therefore DRM does not even attempt to initialize AGP. The builtin i810 graphics device does not advertize the AGP capability: :00:00.0 Host bridge: Intel Corporation 82810 DC-100 GMCH [Graphics Memory Controller Hub] (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 :00:01.0 VGA compatible controller: Intel Corporation 82810 DC-100 CGC [Chipset Graphics Controller] (rev 02) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e600 (32-bit, prefetchable) Region 1: Memory at e480 (32-bit, non-prefetchable) [size=512K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3552] i810 DRM module does not initialize
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3552 --- Additional Comments From [EMAIL PROTECTED] 2005-06-16 11:23 --- It never fails to amaze me how close-but-not-quite-there the Intel graphics hardware is. The i8XX / i9XX graphics chips are obviously AGP, but they don't have the AGP attribute set in their PCI information. The i810 (and almost certainly the deprecated i830) DRM will need a patch similar to what's in the i915 DRM. Search for i915_driver_device_is_agp in the i915 DRM and add something similar to the i810 (and i830?) driver. Do other integrated graphics chipsets have this problem? If nobody gets to it first, I should be able to whip up a patch in a couple days. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] radeon 9800 lockup : guilty reg list
Hi, After launching several times flgrx and dumping the reg and diffing against what was reg with r300 here is the list of reg that have always on my card (RV350NJ) the same value (for the same screen resolution). I think that one of the unknown reg maybe a group of them are the key one but anyway i wasn't able to write to most of this reg. They may are read only thus i tried writing random things in register near them but i only succeed to lockup the card and the reg i was interested in didn't change. Thus if anyone got any info on any of this reg, some must be in old radeon spec but i haven't this specs and don't understand from their name what they do (not all :)). Maybe dumping value that fglrx set in this reg on other card could be usefull For the know reg i have put their name either taken from xorg reg list of from fb radeon one. The second value is what fglrx set in them r300 value is different. 0x0030 0x5133a3a0 RADEON_BUS_CNTL 0x0044 0x00080007 RADEON_GEN_INT_STATUS 0x0148 0xf000 RADEON_MC_FB_LOCATION 0x014c 0xfdfffc00 RADEON_MC_AGP_LOCATION 0x0224 0x0a00 RADEON_CRTC_OFFSET 0x023c 0xf000 DISPLAY_BASE_ADDR (fb radeon) 0x0260 0x0050 RADEON_CUR_OFFSET 0x033c 0xf000 CRTC2_DISPLAY_BASE_ADDR (fb radeon) 0x03f8 0x0480 RADEON_CRTC2_GEN_CNTL 0x0700 0xf0001000 RADEON_CP_RB_BASE 0x0704 0x00080f11 RADEON_CP_RB_CNTL 0x0738 0x RADEON_CP_IB_BASE 0x078c 0x ?? (near SCRATCH_ADDR SCRATCH_UMSK fb radeon) 0x07d0 0x401f ?? 0x0f0c 0x0080ff04 RADEON_CACHE_LINE (PCI use setpci latency_timer) 0x1698 0x0019 ?? 0x16c8 0x00f0 RADEON_DP_MIX 0x16e0 0x143c RADEON_DEFAULT_OFFSET 0x1724 0x0003 RADEON_CACHE_CNTL 0x2080 0x00240455 ?? 0x3400 0x00f0 ?? HEAD 1 ? 0x3424 0x00f00d60 ?? HEAD 1 ? (near RB2D_DSTCACHE_MODE 0x3428 RB2D_DSTCACHE_CTLSTAT 0x342C fb radeon) 0x3448 0x0076848f ?? HEAD 1 ? 0x3600 0x00f0 ?? HEAD 2 ? 0x3624 0x00f00d60 ?? HEAD 2 ? 0x3648 0x0076848f ?? HEAD 2 ? Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3552] i810 DRM module does not initialize
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=3552 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-16 12:58 --- Fixed in the CVS as per the i915 patches. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
Three tiers is fine with me and I've never been against it. But we've only been talking about this for two years now and no one has stepped up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to wait another two years to build Xegl so I'm trying to come up with some way around the problems. You don't need to fix the 67 drivers, I dropped Alan Cox's idea of vga_class on its arse after I did a full investigation on it (I did a fair bit of work on it before I dismissed it...) I have on my PC somewhere attempt 2 (but I think I lost if in all my bitkeeper vs git trees), that uses a video_lowlayer.c module that doesn't bind to anything, but a lowlevel radeon driver links against it, and registers its handlers for everything (kinda like the DRM does now), then fbdev and DRM sit on top of it/lowlevel radeon, it looked like a good idea, but it still needs a bit more investigation.. we haven't been sitting on our hands on this, I just happen to have 0 time and benh is working on things which although aren't as cool are needed just as much (the VGA arbiter).. I'm also trying to prove architecture with respect to Intel chipsets if I can so at least it might have a hope of moving beyond radeon... (but a memory manager becomes more of an issue with Intel chipsets which share RAM via AGP...) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Dave Airlie [EMAIL PROTECTED] wrote: Three tiers is fine with me and I've never been against it. But we've only been talking about this for two years now and no one has stepped up to fix 67 fbdev drivers - I'm sure not going to it. I don't want to wait another two years to build Xegl so I'm trying to come up with some way around the problems. You don't need to fix the 67 drivers, I dropped Alan Cox's idea of vga_class on its arse after I did a full investigation on it (I did a fair bit of work on it before I dismissed it...) I have on my PC somewhere attempt 2 (but I think I lost if in all my bitkeeper vs git trees), that uses a video_lowlayer.c module that doesn't bind to anything, but a lowlevel radeon driver links against it, and registers its handlers for everything (kinda like the DRM does now), then fbdev and DRM sit on top of it/lowlevel radeon, it looked like a good idea, but it still needs a bit more investigation.. we haven't been sitting on our hands on this, I just happen to have 0 time and benh is working on things which although aren't as cool are needed just as much (the VGA arbiter).. I'm also trying to prove architecture with respect to Intel chipsets if I can so at least it might have a hope of moving beyond radeon... (but a memory manager becomes more of an issue with Intel chipsets which share RAM via AGP...) I just think this is a giant amount of work to save 70K of memory (by allowing a setup which avoids loading fbdev) on desktop x86 machines. It is much simpler to just treat fbdev as the bottom layer and have two tiers instead of three. Wouldn't it be easier to just debug the 12 fbdev drivers that have corresponding DRM drivers to load on the x86? We started doing that with radeon and found two bugs, one was fixed in 24hrs and the other there is insufficient info about the specific laptop model to know what is failing. It's not like the 12 fbdev drivers are chock full of bugs, they are used routinely on other platforms. Even if you move the suspend/resume code from fbdev down to a lower common layer, it's still going to need debugging. If memory is critical there are other ways to reduce it. I just removed 10K from fbdev by moving softcursor support into fbconsole since fbconsole was the only possible user of it. I'll bet there is at least 10K of duplicated code in radeon/radeonfb. Other than saving 70K of memory for x86 users who don't want fbdev, what does a three tier scheme get us? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
I just think this is a giant amount of work to save 70K of memory (by allowing a setup which avoids loading fbdev) on desktop x86 machines. It is much simpler to just treat fbdev as the bottom layer and have two tiers instead of three. Wouldn't it be easier to just debug the 12 fbdev drivers that have corresponding DRM drivers to load on the x86? We started doing that with radeon and found two bugs, one was fixed in 24hrs and the other there is insufficient info about the specific laptop model to know what is failing. It's not like the 12 fbdev drivers are chock full of bugs, they are used routinely on other platforms. You haven't seen intelfb then, it is a train wreck of code and I've no idea if it works on most chipsets, it certainly will blow up with wierd BIOS configs and funny screen, I won't load it on any platform as-is.. it mainly gives us a) some semblance of backwards compatibility for people who don't want their system to break when fbdev is loaded but do want a DRM.. b) a step by step path forward as opposed to big breakage path, 1. make radeon fbdev sit on top of stub driver do nothing with drm. - merge to kernel test it, make sure nothing breaks.. 2. start hooking radeon DRM into mix, but only small things, merge to kernel, prove nothing breaks.. 3. next step etc.. Us kernel people like to have a lots of merge to kernel points where we add no new functionality just scaffolding but make sure we don't remove any either... its like building anything, you can't call scaffolding a waste of time even though you might remove it all in the end... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
there is insufficient info about the specific laptop model to know what is failing. It's not like the 12 fbdev drivers are chock full of bugs, they are used routinely on other platforms. You haven't seen intelfb then, it is a train wreck of code and I've no idea if it works on most chipsets, it certainly will blow up with wierd BIOS configs and funny screen, I won't load it on any platform as-is.. Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). My impression was that fbdev is necessary only for non-intel folks (like powerpc or sparc owners). best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). Xegl people will need a kernel framebuffer driver (not necessarily running the console) but something loaded to take care of X when it starts ... also this memory manager has to go somewhere, and part of it will be in the kernel.. no point having a memory manager if someone else is going to write to your memory anyways.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). To use Xegl it will require you to load both fbdev and DRM drivers for your hardware. Xegl uses fbdev for things like mode setting. In X.org mode setting is done with user space XAA code. Since Xegl uses fbdev to set the mode (and other things) it doesn't need to set the registers from user space and thus doesn't need to run as root. My impression was that fbdev is necessary only for non-intel folks (like powerpc or sparc owners). best Vladimir Dergachev -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Dave Airlie [EMAIL PROTECTED] wrote: You haven't seen intelfb then, it is a train wreck of code and I've no idea if it works on most chipsets, it certainly will blow up with wierd BIOS configs and funny screen, I won't load it on any platform as-is.. it mainly gives us a) some semblance of backwards compatibility for people who don't want their system to break when fbdev is loaded but do want a DRM.. b) a step by step path forward as opposed to big breakage path, 1. make radeon fbdev sit on top of stub driver do nothing with drm. - merge to kernel test it, make sure nothing breaks.. 2. start hooking radeon DRM into mix, but only small things, merge to kernel, prove nothing breaks.. 3. next step etc.. Doesn't all this do is defer the day we load the 12 fbdev drivers on x86? Sooner or later we need to load and debug those fbdev drivers. I don't see that the scaffolding really buys us anything; the root problem is that the existing fbdev drivers need to get tested on the x86. The source of everyone's fear is loading these drivers, that's the problem that needs to be addressed. For people that don't want to participate in debugging the fbdev drivers on x86 leave the current DRM drivers in the tree. How about another approach that reverses the sequence, it doesn't involve any new code to being with... 1) appeal on LKML for everyone to load the 12 fbdev drivers on x86 and report bugs. 2) we fix all of those bugs. 3) next we minimally bind DRM and fbdev with a common symbol so that they can only be loaded together and put it in the mm build. This will shake out more bugs. 4) let the mm patch into the rc kernel series - more people, more testing 5) By now it should be safe to force loading of them both. 6) since they both safely load, now we can start adding hooks between them. If people have problems during this process the old DRM driver is left in the tree. They can revert back to it while the fbdev problem gets fixed. Us kernel people like to have a lots of merge to kernel points where we add no new functionality just scaffolding but make sure we don't remove any either... its like building anything, you can't call scaffolding a waste of time even though you might remove it all in the end... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
Why would layering the DRM on top of the fbdev driver break DirectFB? I (think I) understand the issues with actually merging the drivers, but the more I dig into, for example, MGA DRM, the more convenient it seems to have DRM on top of fbdev. It won't if you do it properly.. Jons was doing his well Xegl doesn't need this so we can rip it out method, which doesn't sit well with me or Benh. he wanted to put the card into a mode at bootup and not let it back out, and have user space consoles and Xegl all running in user space, which is a laudable goal, but things like DirectFB and X expect to be able to take full control, his methods were travelling down the road of preventing this using the justification that no-one will need to run X as Xegl will be king... I may be mis-representing exactly what the issues were but that was what I felt was happening... the basics are Linux fbdev model is horrid, we need to work with it for some sort of backwards compatiblity, we can't just dump it all for some currently prototype project... We'll get where Jon sees us going eventually but we are going to have to get there by a lot more circular method than just warping space/time and stepping through the gap... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Ian Romanick [EMAIL PROTECTED] wrote: Why would layering the DRM on top of the fbdev driver break DirectFB? I (think I) understand the issues with actually merging the drivers, but the more I dig into, for example, MGA DRM, the more convenient it seems to have DRM on top of fbdev. The rules of VT swap are that after swap you can reset the card and blank it's memory. Then when you swap back the first system has to recover. This implies that the merged DRM/fbdev driver has to either be able to recover from having it's hardware reset/blanked or the rules of VT swap need to change. Given the definition of VT swap, VT swap looks a lot like suspend/resume to me and I would like to have common code. Now the problems are: 1) The kernel suspend call goes into the fbdev driver. DRM does see it. 2) VT swap is a user space notification 3) previously fbdev had only a single client, the console. All consoles use the same hardware state - mode, framebuffer setup, etc. With Xegl fbdev now has two clients, console and Xegl. But fbdev only has one place to store the hardware settings. This didn't cause a problem before on VT swap since X keeps its version in user space. Now fbdev needs a new API for managing multiple copies of these settings. 4) It is legal to wipe VRAM on swap, all of VRAM needs to be saved. Instead of doing all that I've been attempting to change the rules of VT swap, but that is making people mad at me. In my changed system you need to stop Xegl, unload its drivers, then load DirectFB's drivers, instead of being able to hot key to it. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 2005-06-16 at 21:29 +0100, Dave Airlie wrote: The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a texture copy is kept in system RAM doesn't depend on the DRM driver having suspend/VT swap hooks since it is able to rebuild VRAM at any point. Take a look at the _pm code in current DRM CVS it uses sysdev to hook suspend/resume for DRM... I'm not too happy about this going into upstream yet, but I'm willing to give it a try... A sysdev is the wrong approach imho. These are very low level, run with interrupts off, and have ordering issues, I'd rather avoid them. Also, at the point your sysdev suspend is called, it's likely that the video card will already be in D3 state - no access to vram. So, given the way things are now, we have to pick one of the first two choices. Doing anything else (like doing a minimal copy out of VRAM) requires the drivers to be linked. Too many people are opposed to merging DRM/fbdev for that to happen. And to be honest this is bollocks I don't want to quote private mails here, but neither myself or benh said anything of the sort from my reading, we just a) didn't like your Xegl is the *ONLY* way forward approach and b) your approach stomped on any chance that older apps (and DirectFB) would continue working... we both stated we see a three-tier approach to merged drivers being the way forward, and I'm going to start adding hooks to CVS, just because we aren't willing to jump in and apply patches straight away might speak more about how we are maintainers and not break everything in sighters to add a new feature.. You also have a whole world is a radeon or at least ATI approach, this doesn't help design the architecture, I agree with your goals but saying the whole world is against you one more time isn't helping this any.. also can you stop a)stating MS are going to beat us, nobody cares, Apple already beat us so what. b) the list of goals you have, everyone is very aware of them at this stage, its just most people also have other ideas that don't appear on your list and want to keep the options open.. Dave. Awake way too early to read this stuff again... --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 2005-06-16 at 22:28 +0100, Dave Airlie wrote: Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). Xegl people will need a kernel framebuffer driver (not necessarily running the console) but something loaded to take care of X when it starts ... also this memory manager has to go somewhere, and part of it will be in the kernel.. no point having a memory manager if someone else is going to write to your memory anyways.. In fact, the framebuffer support/mode setting doesn't have to be in the kernel stricto-sensus. The only sane approach, from my perspective, is to create a separate library/daemon/whatever that becomes the primary mode setting ( desktop geometry) interface. Wether it lays on top of fbdev or some userland based binary blobs is almost irrelevant (at least it is to the client application). This also isolates us from the underlying kernel beeing linux, some BSD, OS X, whatever... What the kernel need to provide however is some slightly improved DRM that provides the basic services of mapping the card resources, dealing with interrupt, and beeing present as a PCI driver for the card kernel-wise. Wether that kernel part does the actual mode setting (and then the userland library can use it) or not is almost irrelevant. An easy way to prototype such a library however would be to build something on top of fbdev. There are at least 2 different issues also regarding the HW ownership that are more/less overlapping. One is the VGA arbitration, the other one is the basic HW ownership of a given card. fbdev provides absolutely no kind of arbitration/locking/whatever. All we have currently at the linux kernel level is this notion of 'taking control' of the VT subsystem by switching it to KD_GRAPHICS mode. What could be done here is to have our library/daemon be responsible for that. That is, modern clients (Xegl, others) would use the library for resource sharing and access arbitration. The library itself would switch the entire system to KD_GRAPHICS on the first client getting in. We need a mecanism to relinguish ownership as well, which includes eventually loss of HW context etc... and proper synchronisation with client programs, to deal with VT switches and system suspend/resume. This is all quite a bit of work, we have discussed various possibilities a while back on IRC and I think I even posted some bits of proposed API for the mode setting bits a long time ago, I've also have some VGA arbitration stuff half-done that I itend to finish for KS, but I lack time and I don't necessarily have perfect ideas on the kind of interfaces to provide for these things. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote: On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). To use Xegl it will require you to load both fbdev and DRM drivers for your hardware. Xegl uses fbdev for things like mode setting. Xegl should use ... EGL. Eventually some other library we define for mode setting on top of it. Xegl should not rely on fbdev directly. Wether the EGL implementation uses fbdev or somethign else on a given platform should be irrelevant to Xegl. In X.org mode setting is done with user space XAA code. Since Xegl uses fbdev to set the mode (and other things) it doesn't need to set the registers from user space and thus doesn't need to run as root. My impression was that fbdev is necessary only for non-intel folks (like powerpc or sparc owners). best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thu, 16 Jun 2005, Jon Smirl wrote: On 6/16/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2005-06-16 at 17:30 -0400, Jon Smirl wrote: On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Out of curiosity - who are the people that *need* intelfb ? (as opposed to *want*). To use Xegl it will require you to load both fbdev and DRM drivers for your hardware. Xegl uses fbdev for things like mode setting. Xegl should use ... EGL. Eventually some other library we define for mode setting on top of it. Xegl should not rely on fbdev directly. Wether the EGL implementation uses fbdev or somethign else on a given platform should be irrelevant to Xegl. Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? best Vladimir Dergachev There is also Xglx which is the Xgl server that runs inside X.org using GLX. Xwgl and Xagl will be the windows and apple versions of Xgl whenever they get written. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? EGL mode setting interface is very simple. The problem is not the complexity of the interface, more the complexity of the implementation. The interface can be quite simple if it's done right. Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Fri, 17 Jun 2005, Benjamin Herrenschmidt wrote: Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? EGL mode setting interface is very simple. The problem is not the complexity of the interface, more the complexity of the implementation. The interface can be quite simple if it's done right. I am worried not only about kernel-user interface, but also interface between separate parts within the kernel, for example between DRM and fbdev. best Vladimir Dergachev Ben. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: Xegl uses OpenGL/EGL, it's not defined to use anything else. It is the mesa implementation of OpenGL/EGL that uses fbdev. Nvidia/ATI will likely provide OpenGL/EGL's that don't use fbdev. One thing that bothers me about this whole discussion is the mounting level of interface complexity. It is not just bad as far as debugging is concerned but will also present a barrier to easy experimentation with the code. Will we have new developers in 5 or 10 years if the interface is so complex that it took several years just to create it ? We started off with dumb framebuffers. Next we added bitblt and things were still simple. But along came the GPU and that was the end of simple. The level of the driver API has to exceed the level of hardware capability or the hardware is useless. What good is a hardware convolution filter if the only driver interface is fbdev? OpenGL and DirectX are the drivers of GPU capability. So in order to make use of the all the hardware capability we need to pick an API that exceeds the hardware's capability. It's better if the API significantly exceeds the hardware capability because next gen hw is going to automate some of the things done in software today. We have several choices: 1) XAA, hardware integration already far exceeds it 2) DirectX, MS patent problems 3) OpenGL, open well documented 4) write our own, we do all the work I picked #3 since I think it is the best fit for Linux since we already had DRI/mesa. Other groups are making other choices. Writing drivers for the #3 model isn't that bad considering what you get for the effort. No matter which model you pick you have to write all of the functions to expose your hardware. But we have large pre-existing common libraries. I took the existing code in fbdev, mesa, Xegl and had a framebuffer EGL driver going in a couple of days. That's the general background. Now things get messy. Linux has VT swap. With VT swap you hit a magic key and another device driver gets to take over the hardware. This driver is free to reset the hardware and wipe it's VRAM. Hit another key and control is returned to you, now you have to recover. Linux also has three major device drivers all trying to control the same piece of hardware: fbdev, DRM, XAA. There are another twenty minor ones. Development between the groups writing these drivers is often uncoordinated. Now throw in things like suspend/resume on laptops. Plus 512MB of VRAM that can go poof on VT swap And don't left me forget that GPUs have hundreds of commands and run as asynchronous processors fed by DMA queues. All of this makes the environment for writing graphics drivers on Linux extremely complex. A lot of this is historical complexity. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On Thursday 16 June 2005 20:06, Jon Smirl wrote: On 6/16/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: In fact, the framebuffer support/mode setting doesn't have to be in the kernel stricto-sensus. In the model I'm working with, things like mode setting always have to go through a kernel call gate to provide the user to root privilege escalation. Once you are in the driver, the driver is free to set the mode in the kernel or do something like call_userhelper() for a user space implementation. call_userhelper() runs the helper as root so it can get to the registers. I would strongly suggest that we use usermode helpers as much as possible even on linux, since we have the code already written in X and it'll increase the similarity with other platforms. Write it once. Other platforms without an fbdev layer will run the server as root and just fork the modesetter. This would be nice to do even for the classic server if possible. - ajax pgphj4yfirR3c.pgp Description: PGP signature
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/16/05, Adam Jackson [EMAIL PROTECTED] wrote: I would strongly suggest that we use usermode helpers as much as possible even on linux, since we have the code already written in X and it'll increase the similarity with other platforms. Write it once. Other platforms without an fbdev layer will run the server as root and just fork the modesetter. This would be nice to do even for the classic server if possible. User mode helpers have their own set of problems. It is really hard to build them so that the system doesn't deadlock in low memory situations. The OOM process killer can also kill them if it gets desperate for memory. Trying to run them can trigger swap storms, etc. Several groups are building systems like that on Linux right now - FUSE, iSCSI, others. Their success is varied and no one has had complete success. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM IRQ handling
On Wed, 2005-06-08 at 00:01 -0400, Jon Smirl wrote: On 6/7/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2005-06-07 at 15:48 -0400, Jon Smirl wrote: Am I right in this interpretation? First I need to get the bus/device/func of the card, then I need to tell this to the driver (which must already know this info). I then get back the IRQ number, which I then pass back to the driver (which already know this) and tell it to turn interrupts on. While we are at it, why the hell did we split up the PCI ID in bus,dev,fn like that ? We really want either a single structure containing the PCI ID to be passed around or a C string. The current scheme can't be made to work properly with PCI domains. There is no need to fix the call parameters, the calls themselves aren't really needed. User space shouldn't need to pass the PCI slot id back into a driver it already has a handle for. The driver should know this info without being told. These call messes are a result of fbdev and DRM not being linked. This prevents DRM from using the kernel PCI ID mechanism for binding to hardware. We can't add PCI ID binding to DRM since that prevents fbdev from loading. The only solution is to link fbdev and DRM. I don't think framebuffer devices were a consideration (let alone a factor either way) at all back in the days when this code was written... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
