Re: [BUG] r200 dri driver deadlocks
--- Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 05 Sep 2004 20:14:43 -0400 Lee Revell [EMAIL PROTECTED] wrote: On Sun, 2004-09-05 at 16:18, Patrick McFarland wrote: [snip] That shouldn't matter, should it? The userland stuff should never lock the machine up. I'll test it anyhow, though. No, it shouldn't. Anything that directly accesses hardware belongs in the kernel. How to fix this is a pretty hot topic now. That's not the whole truth. There are just too many ways to lock up those 3D chips. For instance I fixed a lockup in the r100 driver where the order in which state changing commands were sent to the hardware would cause a lockup. Each individual state changing command is perfectly valid. Finding all permutations that trigger a lockup would have been too much of a hassle and may not even have been true for all supported hardware out there. So we made the user-space driver emit state changing commands in a fixed order, which seems to work everywhere. Dose the DRM varify that the cmds are in this order? Why not just have the DRM 'sort' the cmds? A simple bouble sort would have no more overhead then the check for correct order, but it would fix missordered cmd streams. Once this is done the statement holds true, userland stuff should never... Regars, Felix Lee | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
Most IMPORTANT is that some-one some-where there is a list of ALL of these. These are best in the form of code comments so the the respective places in the code can be changed. --- Dave Airlie [EMAIL PROTECTED] wrote: Dose the DRM varify that the cmds are in this order? Why not just have the DRM 'sort' the cmds? A simple bouble sort would have no more overhead then the check for correct order, but it would fix missordered cmd streams. Once this is done the statement holds true, userland stuff should never... Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also.. I'd love to, where do I start? The problem he is that I have no-idea... 1. What values I'd neet to test for and sort. 2. The order of the sorting(probly documented in DRI-client code). 3. Where in the DRM I can proform the needed test and sort. I would also love a list of ALL of these so I can fix them one by one. A good project for a new DRI developer, no. Dave. __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
Patrick McFarland wrote: On Mon, 06 Sep 2004 21:15:07 +0100, Alan Cox [EMAIL PROTECTED] wrote: In some cases yes. The DRM is happy with the idea of the kernel being a DRM client too. Thats actually a pretty cool idea. For us that need to use the vesa fbcon driver because there is no native driver, it would probably be faster and saner, and no more problems with dri drivers that don't play nice with fbcon drivers (is that even an issue anymore?) Yeah it is... Especially with (Dare I say it) closed source drivers such as ATI's firegl. H --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
Jon Smirl wrote: They have to be merged. Cards with two heads need the mode set on each head. fbdev only sets the mode on one head. If I teach fbdev how to set the mode of the other head fbdev needs to learn about memory management. The DRM memory management code is complex and is a big chunk of the driver. I would also like to fix things so that we can have two logged in users, one on each head. This isn't going to work if one them uses fbdev and keeps swithing the chip to 2D mode while the other user is in 3D mode. The chip needs to stay in 3D mode with the CP running. Yes! I use the ruby patch and have two users logged in on the two heads of a G550. It works fine - as long as no mode change is attempted. And only one user can use 3D (or even 2D), the other is stuck with a unaccelerated framebuffer. We're not going to get OOPS display while running X without merging. Something I would really like to have since I just had some and was force to hook up a serial console. Also nice to have. Helge Hafting --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
On Mon, 06 Sep 2004 14:12:08 -0400, Michel Dänzer [EMAIL PROTECTED] wrote: You can test the r200_dri.so from the snapshot with the DRM from the kernel... And drum roll please... The dri cvs snapshot works fine on both it's own kernel module, and the one that comes with 2.6.8.1. So now what? (And does this mean it isn't a kernel bug?) rant Also, what happens to r200 users who happen to use Debian? Using dri cvs snapshots obviously isn't an option for everyone (though I don't mind at all) and upgrading to Xorg (when Xorg gets this fix if it doesn't already) is even less of an option. The official word from the Debian X Strike Force is not to switch to Xorg until debriX (modular X) gets somewhere. /rant -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
On Tue, 7 Sep 2004 05:07:45 -0400, Patrick McFarland [EMAIL PROTECTED] wrote: Lots of badly formatted text. I do apologize for anyone who had to read that. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
Mike Mestnik wrote: Most IMPORTANT is that some-one some-where there is a list of ALL of these. These are best in the form of code comments so the the respective places in the code can be changed. --- Dave Airlie [EMAIL PROTECTED] wrote: Dose the DRM varify that the cmds are in this order? Why not just have the DRM 'sort' the cmds? A simple bouble sort would have no more overhead then the check for correct order, but it would fix missordered cmd streams. Once this is done the statement holds true, userland stuff should never... Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also.. I'd love to, where do I start? The problem he is that I have no-idea... 1. What values I'd neet to test for and sort. 2. The order of the sorting(probly documented in DRI-client code). 3. Where in the DRM I can proform the needed test and sort. I would also love a list of ALL of these so I can fix them one by one. A good project for a new DRI developer, no. I seriously doubt this is doable. Unless you put the whole driver in the kernel, which of course nobody wants. I frequently caused gpu lockups by experimental driver changes (for instance, wrong vertex setup). I think the consensus was that it's ok for the driver to lock up the gpu, but it should not lock up the kernel. It might be possible to prevent lockups by a watchdog, resetting the gpu if a lockup is detected. This is how ATI deals with lockups in windows (dubbed VPU Recover), and there is a patch floating around for DRI too (though it is not exactly for that, and doesn't always work). Roland --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs patch for r200 with configuration options
I've applied this ... Dave. On Mon, 6 Sep 2004, Philipp Klaus Krause wrote: This patch enables GL_ARB_vertex_program and GL_NV_vertex_program support in the r200 driver. Both extensions can be enabled via options, GL_ARB_vertex_program is on by default, GL_NV_vertex_program off. Option descriptions are in german, english and french. Apply with cat r200_vp.patch | patch -p1 in Mesa/src/mesa/drivers/dri Philipp Klaus Krause -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
On Maw, 2004-09-07 at 10:07, Patrick McFarland wrote: Also, what happens to r200 users who happen to use Debian? Using dri cvs snapshots If Debian is currently shipping a buggy driver then Debian needs to ship a working driver. Same as anyone else. You'll also need the newest dri driver for Radeon IGP (most ATI chipset laptops) and the newer R2xx hardware. Alan --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
On Mon, 6 Sep 2004 20:16:12 -0400 Jon Smirl [EMAIL PROTECTED] wrote: I decided my loop was too fancy so I just deleted it and replaced it with a simple flag. If the driver uses permanent maps the flag gets set and addmaps from user space have no effect. If the driver doesn't use permanent maps everything should work the old way. If this looks good I can check it in. How would this work with an old DDX that still tries to call AddMap? Especially in the case where the DDX makes multiple maps of the same type? Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
On Mon, 6 Sep 2004 19:56:49 -0400 Jon Smirl [EMAIL PROTECTED] wrote: AddMap has the loop to find the existing mapping and replace it. initmap doesn't have that loop so it allows multiple adds. I wanted to just make AddMap refuse a REG/FB map request but I was trying to be compatible while we changed the drivers over. Can we just switch the drivers over right now and I'll make AddMap ignore requests to change the mappings? It's only a couple of line of code in each driver, but the driver maintainers need to tell us which PCI resource numbers to map. I can switch radeon/r128 right now if we are ready. I'm not sure it's that simple. The way I know DRI policy WRT binary compatibility you'd have to make sure that the new DRM still works with old DDX drivers. So it's fine to generate the maps in the DRM driver if there is enough info. Old DDX drivers still calling AddMap must be returned the correct handles to the maps, even if they call AddMap multiple times with the same map type. The problem with savage was that it alway got the handle of the first frambuffer map. This got handed over to the 3D driver. When the 3D driver tried to map the second framebuffer mapping to its own address space the call to DRM(map) returned -EINVAL because the address range indicated by the 3D driver didn't match the size of the map. If not I can complicate the loop more to handle this case. I'd vote for making AddMap search for an identical map (same map type, size and offset). If none exists then a new one should be created. This is with my still very limited understanding of the DRM. I'm open to other suggestions. On Tue, 7 Sep 2004 00:45:53 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: But does the new code deal with multiple mappings.. the radeon doesn't do this at the moment they call multiple addmaps for the framebuffer, A permanently mapped framebuffer, shouldn't stop you adding another mapping for tiling/whatever... or should it.. Dave. On Mon, 6 Sep 2004, Jon Smirl wrote: The plan for the addMap changes is to get rid of the loop where the user space code asks the driver where the resources are and then sets those values back into the driver. Since the driver already knows these values it should just create the maps itself. This removes the possibility of the user space code changing those values before passing them back. This is the code radeon driver uses to create the permanent resource mappings. Adding the corresponding code the the savage driver will fix the problem. initmap won't stop you from making more than one mapping. I can look into fixing addmap, but if you switch to having the driver initmap for REGISTERS/ FRAME_BUFFER you won't need to addmap them from user space and it won't matter if the call fails. + + /* registers */ + /* PCI space is twice the real size, so that you can have a RW and RO mapping */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 2 ), + pci_resource_len( dev-pdev, 2 ) / 2, _DRM_REGISTERS, 0 ))) + return retcode; + + /* framebuffer */ + if( (retcode = DRM(initmap)( dev, pci_resource_start( dev-pdev, 0 ), + pci_resource_len( dev-pdev, 0 ), _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING ))) + return retcode; On Mon, 6 Sep 2004 23:23:27 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: Anyway, I suspect the behaviour of DRM(addmap) changed recently. The only addmap-related comment I could find on dri-patches is this: addmap-base-2 patch from Jon Smirl: sets up the DRM to have the ability to have permanent maps while the driver is loaded... Is it really necessary to limit drivers to a single framebuffer-type mapping? Just in case anyone is wondering this is why I can be a bit slow pushing to Linus, finding these issues takes time... this patch looked okay to me but I never knew what the savage was up to ... I don't think there is any reason to limit it to only one mapping, Hopefully Jon can think of a way around it, you should be able to back out that change on your system for now until Jon gets online.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___
Configuration design (was Re: vertex programs patch for r200 with configuration options -- corrected)
On Mon, 06 Sep 2004 23:09:34 +0100 Alan Cox [EMAIL PROTECTED] wrote: On Llu, 2004-09-06 at 22:50, Felix Kühling wrote: We want the description strings in all available languages to be compiled into the 3D drivers. All these macros result in a small XML-document which is looked up via dlopen/dlsym by the configuration tool (or xdriinfo as a helper for script based tools). This way information about available options and some human-readable documentation is always in sync with the drivers actually installed on the system. For more background on this design see The internationalisation system supported by all DRI supporting OS's already deals with this itself, and includes things you don't seem to be dealing with like character sets and the fact locales are multi-component (eg en_GB, en_US) and with fallbacks. I'm not sure which internationalization system you're referring to. The only one I'm aware of WRT translations is gettext. And that doesn't do what we want. Gettext stores translations in external files outside the application binary. Also usually gettext is used for translations of messages output by the program itself. Our case is a bit different. The driver contains the messages and their translations, but they are not actually used by the driver. They are presented to the user by an external configuration tool. We want all translations inside the driver shared object file. This way graphical config tools have exactly one place to look for the options and their descriptions. And these descriptions are always guaranteed to be up-to-date and in sync with the driver. Since we have everything in one file we need to use the same encoding for all languages. UTF-8 is used as such a universal encoding. The fact that it's ASCII-compatible makes it easy to include as string literal in the C source code. Multi-component locales could be dealt with if someone insisted in distinguishing between, say, en_US and en_BG. It's mainly a matter of the configuration tool to deal with such locale names or use e.g. en as a fallback if en_US is not available. It seems strange to be reinventing the wheel I don't think we did. Anyway, several revisions of the design were posted to dri-devel and discussed here. Noone suggested using gettext at that time. DRI developpers seem to be happy with the system as it is (someone correct me if I'm wrong) and the implementation effort was small enough to be handled by a single developper with limited time. So it doesn't seem to be such a bad thing after all. I'm not sure how much it was exposed to users (do any Xorg releases include the configuration infrastructure?). But as long as they get a nice tool that speaks their language I guess there is little incentive to change anything. Cheers, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Tue, 07 Sep 2004 10:43:17 +0200, Helge Hafting [EMAIL PROTECTED] wrote: Jon Smirl wrote: I would also like to fix things so that we can have two logged in users, one on each head. This isn't going to work if one them uses fbdev and keeps swithing the chip to 2D mode while the other user is in 3D mode. The chip needs to stay in 3D mode with the CP running. Yes! I use the ruby patch and have two users logged in on the two heads of a G550. It works fine - as long as no mode change is attempted. And only one user can use 3D (or even 2D), the other is stuck with a unaccelerated framebuffer. There is nothing in the hardware preventing both users from having 3D displays. This is a problem in the way fbdev and DRM are designed. I would like to work towards fixing this. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
Here's a new version that should be compatible with all of the cases:
1) multiple maps
2) old X doing AddMap
3) fixed X doing GetMap - X needs to switch to this after all the
drivers get fixed
4) drivers that have implemented permanent maps
4) drivers that have not implemented permanent maps
I have a fix for my editor now that strips trailing blanks so I'm
generating a few extra diffs but this will get rid of the trailing
blanks in CVS after a few check ins.
The reason for this change is to prevent X from moving the address of
the framebuffer in PCI space. That is an illegal thing for X to do on
Linux without also making the appropriate kernel calls. After all of
the DRM drivers implement permanent mapping, X will get an error if it
tried to move the framebuffer address.
= linux/drm_bufs.h 1.8 vs edited =
--- 1.8/linux/drm_bufs.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_bufs.h Tue Sep 7 11:31:45 2004
@@ -1,7 +1,7 @@
/**
- * \file drm_bufs.h
+ * \file drm_bufs.h
* Generic buffer template
- *
+ *
* \author Rickard E. (Rik) Faith [EMAIL PROTECTED]
* \author Gareth Hughes [EMAIL PROTECTED]
*/
@@ -39,7 +39,7 @@
/**
* Compute size order. Returns the exponent of the smaller power of two which
* is greater or equal to given number.
- *
+ *
* \param size size.
* \return order.
*
@@ -59,6 +59,7 @@
return order;
}
+static int permanent_maps = 0;
/**
* Adjusts the memory offset to its absolute value according to the mapping
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
@@ -80,7 +81,7 @@
if ( !(list = DRM(alloc)( sizeof(*list), DRM_MEM_MAPS )))
return -ENOMEM;
memset(list, 0, sizeof(*list));
-
+
if ( !(map = DRM(alloc)( sizeof(*map), DRM_MEM_MAPS ))) {
DRM(free)(list, sizeof(*list), DRM_MEM_MAPS);
return -ENOMEM;
@@ -98,7 +99,7 @@
DRM_DEBUG( initmap offset = 0x%08lx, size = 0x%08lx, type = %d\n,
map-offset, map-size, map-type );
-
+
#ifdef __alpha__
map-offset += dev-hose-mem_space-start;
#endif
@@ -116,7 +117,8 @@
down(dev-struct_sem);
list_add(list-head, dev-maplist-head);
up(dev-struct_sem);
-
+
+ permanent_maps = 1;
DRM_DEBUG(finished\n);
return 0;
@@ -175,19 +177,24 @@
switch ( map-type ) {
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER: {
- /* after all the drivers switch to permanent mapping this should just return an error */
struct list_head *_list;
- /* if map already exists, return the existing one instead of creating a new one */
- list_for_each( _list, dev-maplist-head ) {
- drm_map_list_t *_entry = list_entry( _list, drm_map_list_t, head );
- if ( _entry-map _entry-map-type == map-type ) {
-DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
-map = _entry-map;
-DRM_DEBUG( Found existing: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type );
-goto found_it;
+ /* If permanent maps are implemented, maps must match */
+ if (permanent_maps) {
+ list_for_each( _list, dev-maplist-head ) {
+drm_map_list_t *_entry = list_entry( _list, drm_map_list_t, head );
+if ( _entry-map _entry-map-type == map-type
+ _entry-map-offset == map-offset
+ _entry-map-size == map-size ) {
+ DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
+ map = _entry-map;
+ DRM_DEBUG( Found existing: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
+ map-offset, map-size, map-type );
+ goto found_it;
+}
}
+ /* addmap didn't match an existing permanent maps, that's an error */
+ return -EINVAL;
}
#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
if ( map-offset + map-size map-offset ||
@@ -309,7 +316,7 @@
sizeof(request))) {
return -EFAULT;
}
-
+
down(dev-struct_sem);
list = dev-maplist-head;
list_for_each(list, dev-maplist-head) {
@@ -328,7 +335,7 @@
return -EINVAL;
}
map = r_list-map;
-
+
/* Register and framebuffer maps are permanent */
if ((map-type == _DRM_REGISTERS) || (map-type == _DRM_FRAME_BUFFER)) {
up(dev-struct_sem);
@@ -412,7 +419,7 @@
* \param cmd command.
* \param arg pointer to a drm_buf_desc_t request.
* \return zero on success or a negative number on failure.
- *
+ *
* After some sanity checks creates a drm_buf structure for each buffer and
* reallocates the buffer list of the same size order to accommodate the new
* buffers.
@@ -837,7 +844,7 @@
drm_buf_t **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_SG)) return -EINVAL;
-
+
if ( !dma ) return -EINVAL;
if ( copy_from_user( request, argp, sizeof(request) ) )
@@ -1000,7 +1007,7 @@
drm_buf_desc_t request;
drm_file_t *priv = filp-private_data;
drm_device_t *dev = priv-dev;
-
+
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
return -EINVAL;
@@ -1160,14 +1167,14 @@
}
/**
- * Unreserve the buffers in list, previously reserved using drmDMA.
+ * Unreserve the buffers in list, previously reserved using drmDMA.
*
* \param
Re: Savage DRM problem: multiple framebuffer mappings
Jon Smirl wrote: Here's a new version that should be compatible with all of the cases: 1) multiple maps 2) old X doing AddMap 3) fixed X doing GetMap - X needs to switch to this after all the drivers get fixed 4) drivers that have implemented permanent maps 4) drivers that have not implemented permanent maps I have a fix for my editor now that strips trailing blanks so I'm generating a few extra diffs but this will get rid of the trailing blanks in CVS after a few check ins. Ugh. If we're going to do whitespace changes can we do them seperately to proper changes, please? Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
New version of same patch without the whitespace clean up
On Tue, 07 Sep 2004 16:59:09 +0100, Keith Whitwell
[EMAIL PROTECTED] wrote:
Ugh. If we're going to do whitespace changes can we do them seperately to
proper changes, please?
Keith
--
Jon Smirl
[EMAIL PROTECTED]
= linux/drm_bufs.h 1.8 vs edited =
--- 1.8/linux/drm_bufs.h Sun Sep 5 21:22:06 2004
+++ edited/linux/drm_bufs.h Tue Sep 7 12:07:58 2004
@@ -59,6 +59,7 @@
return order;
}
+static int permanent_maps = 0;
/**
* Adjusts the memory offset to its absolute value according to the mapping
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
@@ -117,6 +118,7 @@
list_add(list-head, dev-maplist-head);
up(dev-struct_sem);
+ permanent_maps = 1;
DRM_DEBUG(finished\n);
return 0;
@@ -178,16 +180,22 @@
/* after all the drivers switch to permanent mapping this should just return an error */
struct list_head *_list;
- /* if map already exists, return the existing one instead of creating a new one */
- list_for_each( _list, dev-maplist-head ) {
- drm_map_list_t *_entry = list_entry( _list, drm_map_list_t, head );
- if ( _entry-map _entry-map-type == map-type ) {
-DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
-map = _entry-map;
-DRM_DEBUG( Found existing: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type );
-goto found_it;
+ /* If permanent maps are implemented, maps must match */
+ if (permanent_maps) {
+ list_for_each( _list, dev-maplist-head ) {
+drm_map_list_t *_entry = list_entry( _list, drm_map_list_t, head );
+if ( _entry-map _entry-map-type == map-type
+ _entry-map-offset == map-offset
+ _entry-map-size == map-size ) {
+ DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
+ map = _entry-map;
+ DRM_DEBUG( Found existing: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
+ map-offset, map-size, map-type );
+ goto found_it;
+}
}
+ /* addmap didn't match an existing permanent maps, that's an error */
+ return -EINVAL;
}
#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
if ( map-offset + map-size map-offset ||
Re: vertex programs patch for r200 with configuration options -- corrected
r200_context.c shows the following: if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) _mesa_enable_extension( ctx, GL_ARB_vertex_program); if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) _mesa_enable_extension( ctx, GL_NV_VERTEX_PROGRAM); Should the nvidia extension be in all caps like that? I know that when I use glGetString(GL_EXTENSIONS) I check for the way they are normally done. If it should be in all caps, can someone give a logical reason for it? Maybe the wrong patch was applied? ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs patch for r200 with configuration options -- corrected
Michael Mazack schrieb: r200_context.c shows the following: if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) _mesa_enable_extension( ctx, GL_ARB_vertex_program); if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) _mesa_enable_extension( ctx, GL_NV_VERTEX_PROGRAM); Should the nvidia extension be in all caps like that? I know that when I use glGetString(GL_EXTENSIONS) I check for the way they are normally done. If it should be in all caps, can someone give a logical reason for it? Maybe the wrong patch was applied? It was the wrong patch that was applied. I already wrote to Dave Airlie, who applied the patch about that. Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs for r200 patch
Philipp Klaus Krause wrote: So I'll add driconf options for both GL_ARB_vertex_program (on by default) and GL_NV_vertex_program (off by default). Maybe we should add the 1.4 extensions and make an option for GL_ARB_depth_texture someday. That might be useful. Add driconf options for For all GL 1.3 ... 1.4 ... 1.5 extensions. They would, of course be disabled by default, but if someone wanted to run an app that required them, they could enable them. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
On 07.09.2004, at 18:54, Jon Smirl wrote: I used sed: sed -e 's/[ ]*$//' $TMP $1 to strip the trailing white space from all of the DRM files. Any objections to a check in? Kernel rules for patches are no trailing white space. while you're at doing whitespace commits: there is a bunch of structs, defines, comments, etc that use inconsistent indention. those could use a cleanup too, though the fix can't be done that automatic. cheers simon -- /\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News PGP.sig Description: This is a digitally signed message part
Re: New proposed DRM interface design
Christoph Hellwig wrote: On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote: Then drm_core would always be bundled with the OS. Is there any real advantage to spliting core/library and creating three interface compatibily problems? Yes we only have one binary interface, between the core and module, this interface is minimal, so AGP won't go in it... *ALL* the core does is deal with the addition/removal of modules, the idea being that the interface is very minor and new features won't change it... Umm, the Linux kernel isn't about minimizing interfaces. We don't link a copy of scsi helpers into each scsi driver either, or libata into each sata driver. Oh for crying out loud! I have posted a clear, concise explaination of why THIS WILL NEVER HAPPEN at least 10 times. Unless you are willing to take over all user support issues that this *WILL* create from now until the end of time on all DRI supported platforms, GO AWAY! Your endless squaking is doing nothing be waste developer time. For the DRI project, that is a very valuable commodity. P.S.: Welcome to my spam filter. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
Jon Smirl wrote: I'm a little concerned that we are doing a lot of work to support a few people (100) using DRM on BSD. I suspicious that it is a very small number since we get close to zero complaints about BSD even though we break it continuously. I think the difference may be that BSD users don't update out-of-tree kernel modules like Linux users do. Because of that, they never see the breakage. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
Thanks. This reenables 3D accel on the Savage. I havn't tested it on any other driver. But the patch looks good to me. Regards, Felix On Tue, 7 Sep 2004 11:39:59 -0400 Jon Smirl [EMAIL PROTECTED] wrote: Here's a new version that should be compatible with all of the cases: 1) multiple maps 2) old X doing AddMap 3) fixed X doing GetMap - X needs to switch to this after all the drivers get fixed 4) drivers that have implemented permanent maps 4) drivers that have not implemented permanent maps I have a fix for my editor now that strips trailing blanks so I'm generating a few extra diffs but this will get rid of the trailing blanks in CVS after a few check ins. The reason for this change is to prevent X from moving the address of the framebuffer in PCI space. That is an illegal thing for X to do on Linux without also making the appropriate kernel calls. After all of the DRM drivers implement permanent mapping, X will get an error if it tried to move the framebuffer address. | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRM problem: multiple framebuffer mappings
I'd be interested to know if you can get permanent maps working in the Savage driver. I sent the example of how the radeon does it. On Tue, 7 Sep 2004 23:08:00 +0200, Felix Kühling [EMAIL PROTECTED] wrote: Thanks. This reenables 3D accel on the Savage. I havn't tested it on any other driver. But the patch looks good to me. Regards, Felix On Tue, 7 Sep 2004 11:39:59 -0400 Jon Smirl [EMAIL PROTECTED] wrote: Here's a new version that should be compatible with all of the cases: 1) multiple maps 2) old X doing AddMap 3) fixed X doing GetMap - X needs to switch to this after all the drivers get fixed 4) drivers that have implemented permanent maps 4) drivers that have not implemented permanent maps I have a fix for my editor now that strips trailing blanks so I'm generating a few extra diffs but this will get rid of the trailing blanks in CVS after a few check ins. The reason for this change is to prevent X from moving the address of the framebuffer in PCI space. That is an illegal thing for X to do on Linux without also making the appropriate kernel calls. After all of the DRM drivers implement permanent mapping, X will get an error if it tried to move the framebuffer address. | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
When we get to a point that there are no big patches pending I'd like to run the whole thing through ident with the default kernel indent rules. But doing that will break any pending patches. Just stripping the white space off from the end shouldn't upset any development. On Tue, 7 Sep 2004 20:43:13 +0200, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: On 07.09.2004, at 18:54, Jon Smirl wrote: I used sed: sed -e 's/[ ]*$//' $TMP $1 to strip the trailing white space from all of the DRM files. Any objections to a check in? Kernel rules for patches are no trailing white space. while you're at doing whitespace commits: there is a bunch of structs, defines, comments, etc that use inconsistent indention. those could use a cleanup too, though the fix can't be done that automatic. cheers simon -- /\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
I just checked and we have trailing blanks all over the place in the kernel tree too. Instead of just fixing the trailing blanks maybe we should bite the bullet and run indent over everthing. There are about 1,500 lines with trailing white space. You don't lose the blame annotations, you just have to dig a little deeper to find them. If we go the ident route we can make it a requirement to run it before checking anything in. I'd prefer that route since it enforces style rules. There's an approved set of parameters for using ident on the kernel somewhere. On Wed, 8 Sep 2004 00:47:24 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: I used sed: sed -e 's/[ ]*$//' $TMP $1 to strip the trailing white space from all of the DRM files. Any objections to a check in? Kernel rules for patches are no trailing white space. Hold off for a while, the problem with this is generating diffs against the kernel gets messy, if we do it I think it needs to happen to both trees at once, there are a lot of whitespace issues in the DRM, one superpatch is waay more acceptable from a version control point of view.. (Larry says you should never do whitespace fixes using BK unless you happen to be working on the code in that area... as you lose blame annotations for pieces of code).. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
checking anything in. I'd prefer that route since it enforces style rules. There's an approved set of parameters for using ident on the kernel somewhere. scripts/Lindent, I used it on the i915.. Dave. On Wed, 8 Sep 2004 00:47:24 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: I used sed: sed -e 's/[ ]*$//' $TMP $1 to strip the trailing white space from all of the DRM files. Any objections to a check in? Kernel rules for patches are no trailing white space. Hold off for a while, the problem with this is generating diffs against the kernel gets messy, if we do it I think it needs to happen to both trees at once, there are a lot of whitespace issues in the DRM, one superpatch is waay more acceptable from a version control point of view.. (Larry says you should never do whitespace fixes using BK unless you happen to be working on the code in that area... as you lose blame annotations for pieces of code).. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
On Wed, 8 Sep 2004 02:34:24 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: scripts/Lindent, I used it on the i915.. You didn't check it in. I'm game if you want to run it over the whole project. Let's merge dyn-minor first so I don't have to rewrite it. Are you ok with perm.patch going in? -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: remove trailing white space from DRM directory
sorry its in the kernel tarball... I'm game if you want to run it over the whole project. Let's merge dyn-minor first so I don't have to rewrite it. Are you ok with perm.patch going in? If it fixes up the savage put it in, the real work is starting to impinge on my drm hacking at the moment, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG] r200 dri driver deadlocks
Sorry, I don't know why we are cross posting and including subscribers in CC. This belongs on the DRI list, as it is only with 3rd party DRI-client code that the problem exists. --- Dave Airlie [EMAIL PROTECTED] wrote: On Tue, 07 Sep 2004 09:07:11 +0200, Arjan van de Ven [EMAIL PROTECTED] wrote: On Tue, 2004-09-07 at 08:54, Dave Airlie wrote: Feel free to implement it and profile it, but there are so many ways to lock up a radeon chip it is scary, the above was just one example, some days if you look at it funny it can lockup :-), it is accepted that userland can crap out 3D chips, the Intel ones are fairly easy to hangup also.. hmmm.. I thought the entire reason for having part of DRM in the kernel was to be able to prevent such events from happening only one reason... http://dri.sourceforge.net/doc/drm_low_level.html But to be honest the chips are entirely capable of locking up on what the docs say are valid things, writing enough workarounds and test would bloat the drm considerably, at the moment we try and have it so a valid OpenGL application doesn't lock it up, but someone writing directly to the DRM would be able to lockup a fair few chips in many interesting ways Dave. --- Roland Scheidegger [EMAIL PROTECTED] wrote: I seriously doubt this is doable. Unless you put the whole driver in the kernel, which of course nobody wants. I frequently caused gpu lockups by experimental driver changes (for instance, wrong vertex setup). I think the consensus was that it's ok for the driver to lock up the gpu, but it should not lock up the kernel. It might be possible to prevent lockups by a watchdog, resetting the gpu if a lockup is detected. This is how ATI deals with lockups in windows (dubbed VPU Recover), and there is a patch floating around for DRI too (though it is not exactly for that, and doesn't always work). Roland It's a simple matter of enforcing 3rd party(this means every DRM user) clients to use DRI's *dialect or style*. If the DRM see activities that are not expected to be generated by pure DRI-clients, action should be taken to prevent a posible lockup. This means that even valid activities should be treated as invalid IF the DRM can clerly detect a deviation from pure DRI-client activities. For example, pure DRI-clients emit state changing commands is a vary specific order. The DRM could easily spot if these cmds where out of any knowen/used order or if any other cmds where also inserted into the expected order. This should be denied. Only DRI-clients(any client) using the DRI supplied order(the one used by pure DRI-clients) should be allowed to access the hardware. __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
