[Dri-devel] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
sorry, I'm still waiting for someone to tell me exactly how I do what is described here, to stop getting the rainbow stuff. Do i disable this in XF86Config or something? --- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 10 Mar 2004 13:18:20 +0100 Subject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems) On Wed, 2004-03-10 at 12:24, Felix Kühling wrote:br On Mon, 8 Mar 2004 15:19:32 -0500 (EST)br John H. [EMAIL PROTECTED] wrote:br br well, your suggestion at least makes the speed ok with 800x600(which isn't that great)br br however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that?br br I just remembered that I saw a similar problem on my Radeon 7500 thatbr seemed to be related to AGP texturing. With a normal radeon thebr workaround is to disable AGP textures using an environment variable.brbrNamely RADEON_GARTTEXTURING_FORCE_DISABLE.brbr However, with an IGP chip you don't have that choice.brbrYes, you do. Framebuffer and GART are still separate, even if both liebrin system RAM.brbrbr-- brEarthling Michel Dänzer | Debian (powerpc), X and DRI developerbrLibre software enthusiast| http://svcs.affero.net/rm.php?r=daenzerbrbr ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI-/Mesa-CVS is totally broken after Mesa update
On Fri, 2004-03-12 at 20:34, Ian Romanick wrote: Jon Smirl wrote: Sorry I broke the DRI build, now I see what the problem is. When the Mesa is included in the DRI tree is it is using the DRM driver in the DRI tree. I didn't know that the DRI build would alter the Mesa include paths. Ugh. In the future, if people are going to do something that will alter build processes, the ramifications need to be discussed and agreed upon by other developers. Silence != approval. Stuff like this makes good topics for the weekly IRC meetings. :) Indeed. I have pile of changes ready that require simultaneous changes in mesa and the drm driver. For me it would be much simpler to have the DRM driver and mesa in the same tree. I'm targeting this work to go into xserver, not xfree. I don't see how that matters; same DRM. (BTW, the DRM in the DRI tree isn't 'a copy', it's The Original(TM) :) But other people want to keep the DRM in the DRI tree. Doing this means I have to be careful about doing parallel check-ins to both trees. Which is a good thing, because it should help keep the interface clean. It also forces me to work in the DRI tree, a tree that I'm not using. I don't think anyone *really* wants to keep it in the DRI tree. I think most folks want it in its own tree. Yes. Once the userspace drivers have moved to the Mesa and X trees, there won't be much more left anyway. :) Perhaps now would be a good time to forge ahead on that front as well. Dunno. The sooner the better IMHO. Any takers? -- 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: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Three proposed new generic DRM IOCTLs
On Sat, 2004-03-13 at 04:54, Jon Smirl wrote: The code for the proposed IOCTLs is written and tested. They would be added one at a time. Do you have a patch for us to look at? 3) BLANK - simple call to allow Vesa power management to blank the display. A fourth call will be a driver specific call for setting the video mode. I am implementing this by completely computing the register values needed to set the mode in user space. I then pass these as a struct to the IOCTL and the driver sets the mode. Doing it this way moves about 100K of code (in the radeon case vs framebuffer) out of the kernel and into user space. Is the verification of the input data really that much smaller? I still don't quite see the point of duplicating framebuffer device functionality in the DRM... -- 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: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
On Fri, Mar 12, 2004 at 01:40:30PM -0800, Ian Romanick wrote: I want to initially support this by just disabling AGP texturing. I looked in the DRI driver, and it looks like this can be done with some trivial changes in mga_xmesa.c. Basically, the code just needs to handle the case where serverInfo-agpTextureSize is 0. The DDX driver needs to be modified to detect PCI cards and do something smart there. I think the chip detection for the DRI driver should be in the DRM. I have this in my local Mesa 5 tree. I just added a new getparam ioctl that returns the PCI id. But since G450 PCI doesn't have a unique PCI id we'd need something slightly different. I don't want to exclude the possability of sourcing vertex data from on-card memory in the future. The cards can't do this. MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit because I don't intend to (initially) support PCIGART. Even when PCIGART is supported, not all chips in the MGA family support it. Is the PCI G450 the only one? I think so. G200 was the last chip to have a real PCI variant but none of the chips can do scatter gather. I've never heard of PCI G400 or G550. Of course even AGP chips can use PCI transfers but that might only make sense for something like video capture. Currently the DMA buffers are 64 kB but if we would reduce them to PAGE_SIZE we could perhaps support all PCI cards. The only problem is the primary buffer since it's 1 MB currently. And switching to PAGE_SIZE buffers might require even more space in the primary buffer. I haven't actually measured how full the buffers are typically... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PCI MGA support (was Re: [Dri-devel] mga cvs changes)
On Fri, Mar 12, 2004 at 03:39:50PM -0800, Alex Deucher wrote: As I recall the G450-PCI cards were just AGP chips with an agp to pci bridge. Perhaps you need to hack up an agpgart driver for the bridge? Also, for the pci g450, matrox only supported 3D on motherboards with intel chipsets for whatever reason. If possible, I'd like to leave that until later. Esp. since I don't have any docs for that. :( You do now! looks like PLX owns HiNT now and they have the databooks on their website. according to this thread: http://marc.theaimsgroup.com/?l=dri-develm=102373024625910w=2 the pci g540 uses the Hint HB1-SE33 bridge. PLX bought HiNT and changes a few names: http://www.plxtech.com/products/hint/naming.htm but makes the specs available here: http://www.plxtech.com/products/hint/6152.asp I just had a look at the docs and didn't see any mention of an address translation table :( Is the bridge only used because they needed to connect a 66Mhz AGP device to a 33MHz PCI bus? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Three proposed new generic DRM IOCTLs
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2004-03-13 at 04:54, Jon Smirl wrote: The code for the proposed IOCTLs is written and tested. They would be added one at a time. Do you have a patch for us to look at? I'll start sending the patches out if everyone is ok with the general concept. 3) BLANK - simple call to allow Vesa power management to blank the display. A fourth call will be a driver specific call for setting the video mode. I am implementing this by completely computing the register values needed to set the mode in user space. I then pass these as a struct to the IOCTL and the driver sets the mode. Doing it this way moves about 100K of code (in the radeon case vs framebuffer) out of the kernel and into user space. Is the verification of the input data really that much smaller? Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to user space. It only took a couple of days. Mode setting code is seldom used as compared to an interrupt handler, this gives the space back for more important things and eliminates the need to security audit the code. It's also much easier to debug. current radeonfb + fb + radeon is about 300Kb code I still don't quite see the point of duplicating framebuffer device functionality in the DRM... I'm not really duplicating framebuffer. I took the framebuffer code and the DRM code and merged them into a single driver. Then I'm moving everything I can out of the kernel and into user space. The goal is to provide an OpenGL stack which is capable of being the only interface to the hardware. Doing this builds the graphics API at a very high level. A high level API will let the hardware change transparent to the software. For example SGI hardware does not have access to the framebuffer; PC hardware with a similar architecture is coming soon. It also makes it easy for ATI/Nvidia to provide monolithic driver stacks. It's a path to providing more controlled access to the graphics hardware. Right now we have a free for all when every app and device driver can just do what it wants to the hardware. What if I am running X/DRI in one VT and another app that does direct 3D drawing via the hardware on another VT. Does framebuffer preserve the complete state of the hardware at VT switch? Although I haven't written the code yet, I intend to add a output-only console driver entry point to DRM. Since mode setting is now tracked through the DRM driver it will be possible to display a kernel oops that occurs while running xserver. This is something framebuffer can't currently do. The state of graphics on Linux needs to move forward. Microsoft Longhorn is going to ensure that every PC built in the future has capable graphic coprocessor support. Don't think of this as 3D vs 2D, think of it as a switch from dumb to intelligent hardware. There is a lot of complicated code to be designed and written and we've got a year to do it if we're going to beat Microsoft. Let's all work together to achieve this transition in Linux. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Binary incompatibility breaks snapshots
Ian Romanick wrote: [...] Here an extract from my logfile: (==) RADEON(0): Write-combining range (0xe000,0x200) (II) RADEON(0): Wrote: rd=6, fd=58, pd=2 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf296a000 (II) RADEON(0): [drm] mapped SAREA 0xf296a000 to 0x4227a000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000217 [AGP 0x8086/0x3340; Card 0x1002/0x4c57] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xd000 (II) RADEON(0): [agp] Ring mapped at 0x4227c000 (II) RADEON(0): [agp] ring read ptr handle = 0xd0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x4237d000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4237e000 (II) RADEON(0): [agp] GART texture map handle = 0xd0302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x4257e000 (II) RADEON(0): [drm] register handle = 0xc010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1024,8191) (II) RADEON(0): Reserved area from (0,768) to (1024,770) (II) RADEON(0): Largest offscreen area available: 1024 x 7421 (II) RADEON(0): Will use back buffer at offset 0x60 (II) RADEON(0): Will use depth buffer at offset 0x78 (II) RADEON(0): Will use 23552 kb for textures at offset 0x90 (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 770) (II) RADEON(0): Largest offscreen area available: 1024 x 7413 (**) Option dpms (**) RADEON(0): DPMS enabled (II) RADEON(0): X context handle = 0x0001 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 11 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 (II) RADEON(0): Direct rendering enabled I can`t find somethin like: (II) RADEON(0): [drm] Could not create dummy context here is the output from glxinfo:libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x25 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x29 libGL warning: 3D driver claims to not support visual 0x2a libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2d libGL warning: 3D driver claims to not support visual 0x2e libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 libGL warning: 3D driver claims to not support visual 0x31 libGL warning: 3D driver claims to not support visual 0x32 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x1e2 Serial number of failed request: 28 Current serial number in output stream: 28 [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x25 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support
Re: [Dri-devel] Re: Three proposed new generic DRM IOCTLs
On Sad, 2004-03-13 at 16:35, Jon Smirl wrote: Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to user space. It only took a couple of days. Mode setting code is seldom used as compared to an interrupt handler, this gives the space back for more important things and eliminates the need to security audit the code. It's also much easier to debug. It does not remove the need to security audit the code. It makes the mess slightly smaller if you get it wrong. You probably also want a minimal set of mode setup code in the kernel so you can get back to a known text mode configuration when a GUI server goes kaboom, or when the user hits SAK (and SAK is mandatory for many secure configurations). software. For example SGI hardware does not have access to the framebuffer; PC hardware with a similar architecture is coming soon. It also makes it easy for ATI/Nvidia to provide monolithic driver stacks. In graphics modes PC hardware with this property for SVGA modes goes back as far as the IBM PS/2 - the 8514 was like this for example. wants to the hardware. What if I am running X/DRI in one VT and another app that does direct 3D drawing via the hardware on another VT. Does framebuffer preserve the complete state of the hardware at VT switch? It needs to yes. Although it doesn't neccessarily need to do it all in kernel mode. Although I haven't written the code yet, I intend to add a output-only console driver entry point to DRM. Since mode setting is now tracked through the DRM driver it will be possible to display a kernel oops that occurs while running xserver. This is something framebuffer can't currently do. That makes sense, although because of the way the console layer works if you have output you also have input - good news for kernel debugging tools too. The state of graphics on Linux needs to move forward. Microsoft Longhorn is going to ensure that every PC built in the future has capable graphic coprocessor support. Don't think of this as 3D vs 2D, think of it as a switch from dumb to intelligent hardware. There is a lot of complicated code to be Think of it as a repeat of the dumb 2D - smart 2D - oversmart 2D - fairly dumb 2D/dump 3D ... continuing life cycle. The dumb-intelligent thing is a cycle. The day the CPU is fast enough or parallel enough to do fast 3D it'll eat the low end 3D video card market. designed and written and we've got a year to do it if we're going to beat Microsoft. Let's all work together to achieve this transition in Linux. For high end hardware maybe. For the low end I actually expect we'll see something different, probably from Intel first (since Intel is continually trying to leverage die size for new features) which is on CPU operations to do texture walk and basic effects. In other words using the CPU to do the grunt work in the tight inner loops of the 3d library. This makes a lot of sense in a low price environment where you already have the framebuffer in CPU memory not over a PCI bus. Also don't lose sight of the fact large numbers of Linux systems, and probably a growing percentage over time will be phones, dvd players, pda's, post PC systems and the like. I don't think anything in your design is problematic here at all. It works fine for single mode, dumb 2D devices. Alan --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Three proposed new generic DRM IOCTLs
On Sat, 2004-03-13 at 17:35, Jon Smirl wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: On Sat, 2004-03-13 at 04:54, Jon Smirl wrote: A fourth call will be a driver specific call for setting the video mode. I am implementing this by completely computing the register values needed to set the mode in user space. I then pass these as a struct to the IOCTL and the driver sets the mode. Doing it this way moves about 100K of code (in the radeon case vs framebuffer) out of the kernel and into user space. Is the verification of the input data really that much smaller? Yes. Big chunks of Benh's driver and the mode parts of fb can easily be moved to user space. It only took a couple of days. Mode setting code is seldom used as compared to an interrupt handler, this gives the space back for more important things and eliminates the need to security audit the code. The security audit still needs to happen somewhere. Does the DRM code validate the user data? It's also much easier to debug. That I can imagine. It's a path to providing more controlled access to the graphics hardware. Right now we have a free for all when every app and device driver can just do what it wants to the hardware. I don't see what prevents that in your scheme. Although I haven't written the code yet, I intend to add a output-only console driver entry point to DRM. Since mode setting is now tracked through the DRM driver it will be possible to display a kernel oops that occurs while running xserver. This is something framebuffer can't currently do. Actually it can, or at least it did at some point, been a while since I've experienced a panic. :) -- 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: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Three concepts for changing the way video works in Linux
Here's three more ideas I'm thinking about but I haven't written any code for... First some terminology. We really have two consoles. There is the kernel console that gets the printk output. Second is a user console that you can log into. Right now the fbconsole system maps these to the same place but they don't have to be. The kernel console can go out a serial port, network, etc. 1) Use SysReq to get to kernel console. In this model the kernel console is always active, it's just hidden. Hit SysReq and it appears. Hit an oops or panic and it will appear too. The video driver has enough state information to make this console appear no matter what mode the video hardware is in. Hit SysReq again and it will disappear and your display will be back where you left it. Extra points if you can get something like kdbg running on it. 2) Move the code implementing user console to user space. User console would work via ptmx/pts like X terminals. There would be a process listening to the pts device which would implement the terminal emulator, VT, etc and draw on the video device. The process would always be running and be started from init. The main purpose to this is that it becomes very easy to plug in multiple graphics cards and build a multi-user box. 3) Turn multi-headed cards into two DRI devices that can be used independently. Using item #2 a separate user could be logged into each head. If you own both the primary and secondary device you could set a special mode on the primary that would trigger merged fb and disable the secondary device. These are just concepts right now. If you've got ideas on how to improve on these let me know. A fourth concept which has already been heavily discussed is making OpenGL the primary graphics API. OpenGL can be quite small, OpenGL-ES is already shipping on some phones. Just to recap OpenGL/xserver is a response to Windows Longhorn. It is also a high level API that allows graphics hardware to grow more intelligent without disrupting the top level API. --- Alan Cox [EMAIL PROTECTED] wrote: It does not remove the need to security audit the code. It makes the mess slightly smaller if you get it wrong. You probably also want a minimal set of mode setup code in the kernel so you can get back to a known text mode configuration when a GUI server goes kaboom, or when the user hits SAK (and SAK is mandatory for many secure configurations). Are these needs addressed by the concepts above? wants to the hardware. What if I am running X/DRI in one VT and another app that does direct 3D drawing via the hardware on another VT. Does framebuffer preserve the complete state of the hardware at VT switch? It needs to yes. Although it doesn't necessarily need to do it all in kernel mode. There is another solution. By using DRM/OpenGL as the core API and single driver there is no need to save the hardware state at VT switch. The only reason ww have the state saving problem on VT switch is because we are trying to multitask two device drivers and some user apps all trying to directly use the hardware. Moving to a single device driver and blocking user space access to the hardware will allow the hardware state to be managed. The other choice is like VMware where we create a virtual Radeon device. For high end hardware maybe. For the low end I actually expect we'll see something different, probably from Intel first (since Intel is continually trying to leverage die size for new features) which is on CPU operations to do texture walk and basic effects. In other words using the CPU to do the grunt work in the tight inner loops of the 3d library. This makes a lot of sense in a low price environment where you already have the framebuffer in CPU memory not over a PCI bus. Also don't lose sight of the fact large numbers of Linux systems, and probably a growing percentage over time will be phones, dvd players, pda's, post PC systems and the like. I don't think anything in your design is problematic here at all. It works fine for single mode, dumb 2D devices. This is true. Software Mesa can completely emulate everything and just use a dumb framebuffer for output. The DRM driver for a dumb framebuffer is pretty simple to write. For the smallest possible system restrict yourself to OpenGL-ES, statically link to the software Mesa version of it and use a dumb frame buffer driver. You'll end up with an app the same size as if you used SVGAlib. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___
[Dri-devel] drm:i830_wait_ring
I have been able to reproduce several x server crashes by killing a process from tty 1,2 or 3 that is running on tty5 this crash occurs after killing a variety of process such as evolution and mozilla and then attempting to switch to tty5 from tty 1,2 or 3. I am running XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) on Linux version 2.4.24(gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) The errors printed to the terminal are below. [drm:i830_wait_ring] *ERROR* space: 131048 wanted 131064 [drm:i830_wait_ring] *ERROR* lockup Thank you Patrick --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Three concepts for changing the way video works in Linux
Around 18 o'clock on Mar 13, Jon Smirl wrote: This is true. Software Mesa can completely emulate everything and just use a dumb framebuffer for output. The DRM driver for a dumb framebuffer is pretty simple to write. For the smallest possible system restrict yourself to OpenGL-ES, statically link to the software Mesa version of it and use a dumb frame buffer driver. You'll end up with an app the same size as if you used SVGAlib. Everything above sounded like a really cool plan, but I'm not sure about this part. For devices which don't really want to support GL (think Tivo), I suggest that we don't want to layer graphics atop this inappropriate API. While real computers move to 3D-only graphics hardware, I imagine the low end will continue to be populated by nasty little 2D accelerators, and I'm sure some of those will end up running X (or other existing 2D environments). I suspect we'll need a primitive 2D API that can be used by your user-mode console program and a primitive X server, and then permit graphics driver writers to extend that in whatever weird way they want to get their video overlays or cell-phone UI running. -keith pgp0.pgp Description: PGP signature
Re: [Dri-devel] Re: Three proposed new generic DRM IOCTLs
This is a first pass at the three new IOCTL patch. It is against the DRM copy in the Mesa tree. Building DRM from mesa works fine. It includes the radeon mode setting IOCTL. 1) It is 2.6 only since it has sysfs and hotplug support. I will need to add ifdef's to remove these on 2.4. 2) It uses the kernel to bind the DRM driver to the video device. This will make it conflict with framebuffer. You will have to uninstall framebuffer before it can be loaded. The kernel does not allow two device drivers to bind to the same device. (DRM currently functions by accessing the device without telling the kernel it is going to do so). Next pass I will add ifdef's on the kernel device binding. If you turn off kernel device binding you will also lose sysfs support and hotplug reset support. Since there is no sysfs support you won't get EDID in sysfs and mode setting won't work. To test hotplug reset add a link in /etc/hotplug.d/dri called video-reset.hotplug to the video-reset program in the mesa tree. It is smart enough to only reset an adapter if it needs to be reset. I've only checked this with radeons but it should work with other secondary cards. The video-reset program will use the GET_VBIOS and VGA_ENABLE ioctls. You need the eeprom module modprobed in to see the edid data. I have user space routines that read the data from sysfs and compute the right register values to send to the ioctl but it's not checked in yet. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com patch.bz2 Description: patch.bz2
