Do dual DRI devices work in the X Server?
I've been trying to figure out how come X wouldn't load when I have
two of the new drm-core type drivers loaded. Then if finally occurred
to me to load the old drivers and see what X does, it fails too.
I have an AGP radeon and PCI r128. modprobe in radeon and r128. I'll
attach my xconf.
Now start X. It won't start.
In programs/Xserver/GL/dri/dri.c
static int lockRefCount=0;
void
DRILock(ScreenPtr pScreen, int flags)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
if(!pDRIPriv) return;
if (!lockRefCount)
DRM_LOCK(pDRIPriv-drmFD, pDRIPriv-pSAREA, pDRIPriv-myContext, flags);
lockRefCount++;
}
How is this going to work with two DRI devices?
The error is that the first DRILock on the kernel context is never
set. Right before this DRM is not called with a request for a lock
when there should be one. I haven't got an X server put together for
debugging yet, but this sure looks like the likely culprit for why the
lock call isn't being made.
--
Jon Smirl
[EMAIL PROTECTED]
xorg.dual
Description: Binary data
[Bug 1495] r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 00:36 --- Argh. OK. That fixes it. It must have been loading the old DRI drivers. New bug with the DRI snapshot: the UT2004 menu screen has a comletely white background, unlike the non-dri one (there should be a few images there). Otherwise everything seems to work. Argh. Should I change to NOTABUG report the above separately? -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
winex: ARB_VBO and DirectX for r200 cards.
I was playing with winex, after paying for some games and a TransGaming subscription. In the cfg there are options to enable/disable the use of some OpenGL extensions, one being ARB_VBO. I saw that when using frglx there were some of these advertised by glxinfo, but not with SW/Mesa or R200/DRI. First I was wondering what it would take, as far as bribes, to get at least as far as the frglx drivers have with supporting this extension. Since I have to pay for winex... I also saw on this list that some R200 DMA memory layouts matched thoes used by DirectX and that to match the OpenGL ordering there was some swaping going on. I know the overhead is minimal, especialy with 32bit CPUs. However it would be a nice laught if OpenGL had some extentions for the CARDs idea of how things should be ordered. The idea being that any DirectX implementation for X(like winex) would not need to swap the bytes into OpenGLs prefered order when the CARD expects the data tobe in DirectX's order. __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: winex: ARB_VBO and DirectX for r200 cards.
Mike Mestnik schrieb: I was playing with winex, after paying for some games and a TransGaming subscription. In the cfg there are options to enable/disable the use of some OpenGL extensions, one being ARB_VBO. I saw that when using frglx there were some of these advertised by glxinfo, but not with SW/Mesa or R200/DRI. First I was wondering what it would take, as far as bribes, to get at least as far as the frglx drivers have with supporting this extension. Since I have to pay for winex... I also saw on this list that some R200 DMA memory layouts matched thoes used by DirectX and that to match the OpenGL ordering there was some swaping going on. I know the overhead is minimal, especialy with 32bit CPUs. However it would be a nice laught if OpenGL had some extentions for the CARDs idea of how things should be ordered. The idea being that any DirectX implementation for X(like winex) would not need to swap the bytes into OpenGLs prefered order when the CARD expects the data tobe in DirectX's order. It seems you are using outdated drivers. The current DRI drivers support about as much extensions as the nonfree ATI drivers. GL_ARB_vertex_buffer_object is in both software Mesa and the r200 driver. Recently a software emulation of GL_ARB_vertex_program has been added to the r200 driver, which has been in software Mesa for some time. The only important missing extension I'm aware of that is supported by the hardware is GL_ARB_texture_env_crossbar. You can add the patch for GL_S3_s3tc if you're living in a software-patent free area like Venezuela, Europe or Cuba. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: winex: ARB_VBO and DirectX for r200 cards.
Philipp Klaus Krause wrote: It seems you are using outdated drivers. The current DRI drivers support about as much extensions as the nonfree ATI drivers. GL_ARB_vertex_buffer_object is in both software Mesa and the r200 driver. It should be noted though that ARB_vbo is a fake extension in the r200 driver, you get none of the benefits for which this extension was written for - the driver is not capable of allocating vertex buffers in local video ram. True support for this extension might help ut2k3/ut2k4 performance probably quite a bit. Roland --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: G400 on AMD64
On Fr, 2004-09-24 at 14:49 +0200, Maurizio Monge wrote: Hello, it looks like that someone was able to use dri on AMD64 (with 64bits) on a G400 (http://www.x86-64.org/lists/discuss/msg05271.html) The message talks about G400 Max -- I don't know but maybe that's the difference !?!? I tried with kernel 2.6.7 and 2.6.9-rc2-mm1 (also copying exactly the .config), i tried with Xfree 4.4, Xorg 6.8.1 and dri-trunk, and i tried also disabling/enabling acpi/apm and removing /lib64/tls (bacause the driver may not like tls), but the only thing i get is to hang X. The last lines (i guess the only meaningful) of the verbose /var/log/Xorg.0.log are: (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Mouse1: ps2EnableDataReporting: succeeded SetClientVersion: 0 8 (EE) MGA(0): [dri] Idle timed out, resetting engine... (EE) MGA(0): [dri] Idle timed out, resetting engine... (EE) MGA(0): [dri] Idle timed out, resetting engine... ... etc... I already reported this bug some weeks ago. See http://freedesktop.org/bugzilla/show_bug.cgi?id=473. It's still in status NEW so i doubt that someone is working on it ... :( --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI and vt switching?
Hi! How is VT switching normally handled when a DRI client is active? Meaning, for example, switching from the X display to a virtual text console? Looking in the i810 driver, it seems like the ringbuffer is flushed and disabled until the X server calls EnterVT again, and AGP memory is unbound. How is the client generally notified about this? In the unichrome case, there seems to be a Z buffer problem, if not a crash when the X display is restored. XvMC clients mostly likely to hardlock the machine, or crash if they send their commands over AGP. I'd much appreciate some advice or points to documentation how to handle this. Regards Thomas --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
glxinfo: R200 VS FGLRX side by side...
I'm interested in switching back and fourth, if any one has some info on doing this better I'd like to know. Right now I'm symlinking libGL-fglrx.so.1.2 or libGL-dri.so.1.2 into libGL.so.1.2. I also have to unload and load kmods too, I do this by hand as well. I can go from DRI to fglrx fine, but to go back I have to reboot first. Here is a straigth diff, I didn't do a udiff since I think we all know the glxinfo output fairly well. I did make one change s/, $//g and s/, /\n /g. I'm also attaching the 'source'. 6a7 GLX_ARB_multisample 10,11c11,16 client glx vendor string: ATI client glx version string: 1.3 --- GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGIS_multisample GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.2 12a18,20 GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context 15c23,34 GLX_EXT_import_context --- GLX_MESA_allocate_memory GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group GLX extensions: 18,20c37 GLX_ATI_pixel_format_float GLX_ATI_render_texture GLX extensions: --- GLX_EXT_import_context 23,26c40,51 GLX_EXT_import_context OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: RADEON 8500 DDR Generic OpenGL version string: 1.3.4510 (X4.3.0-3.12.0) --- GLX_MESA_allocate_memory GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_OML_swap_method GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics Inc. OpenGL renderer string: Mesa DRI R200 20040906 AGP 4x TCL OpenGL version string: 1.3 Mesa 6.2 27a53,54 GL_ARB_imaging GL_ARB_multisample 29,33d55 GL_EXT_texture_env_add GL_EXT_compiled_vertex_array GL_S3_s3tc GL_ARB_occlusion_query GL_ARB_point_parameters 39d60 GL_ARB_texture_env_crossbar 41a63 GL_ARB_texture_rectangle 43d64 GL_ARB_vertex_blend 47,58d67 GL_ATI_element_array GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_map_object_buffer GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_attrib_array_object GL_ATI_vertex_streams GL_ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output_point_size 61a71 GL_EXT_blend_equation_separate 65a76,78 GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture 67,68c80 GL_EXT_fog_coord GL_EXT_multi_draw_arrays --- GL_EXT_histogram 70c82 GL_EXT_point_parameters --- GL_EXT_polygon_offset 75c87,88 GL_EXT_texgen_reflection --- GL_EXT_subtexture GL_EXT_texture 77,78d89 GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map 79a91 GL_EXT_texture_env_add 88,90c100,109 GL_EXT_vertex_shader GL_HP_occlusion_test GL_NV_texgen_reflection --- GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos 92c111,113 GL_NV_occlusion_query --- GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection 94c115,116 GL_SGIS_texture_edge_clamp --- GL_SGI_color_table GL_SGIS_generate_mipmap 95a118 GL_SGIS_texture_edge_clamp 97,98d119 GL_SGIS_generate_mipmap GL_SUN_multi_draw_arrays 107,126c128,143 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x28 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x2b 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2c 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 1 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x30 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 1 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 1 0 None 0x33 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 1 0 None 0x34 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0
Re: DRI and vt switching?
Thomas Hellström wrote: Hi! How is VT switching normally handled when a DRI client is active? Meaning, for example, switching from the X display to a virtual text console? Looking in the i810 driver, it seems like the ringbuffer is flushed and disabled until the X server calls EnterVT again, and AGP memory is unbound. How is the client generally notified about this? The server holds the hw lock until the VT comes back. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and vt switching?
Thomas Hellström wrote: Hi! How is VT switching normally handled when a DRI client is active? Meaning, for example, switching from the X display to a virtual text console? Looking in the i810 driver, it seems like the ringbuffer is flushed and disabled until the X server calls EnterVT again, and AGP memory is unbound. How is the client generally notified about this? The server holds the hw lock until the VT comes back. Thanks. Thought I tried that, which means there must be some locking / register restoration bugs around. /Thomas Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and vt switching?
On Iau, 2004-09-30 at 13:56, Keith Whitwell wrote: Looking in the i810 driver, it seems like the ringbuffer is flushed and disabled until the X server calls EnterVT again, and AGP memory is unbound. How is the client generally notified about this? The server holds the hw lock until the VT comes back. With the client still having access to the unbound AGP pages as AGP side addresses ? --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI and vt switching?
Alan Cox wrote: On Iau, 2004-09-30 at 13:56, Keith Whitwell wrote: Looking in the i810 driver, it seems like the ringbuffer is flushed and disabled until the X server calls EnterVT again, and AGP memory is unbound. How is the client generally notified about this? The server holds the hw lock until the VT comes back. With the client still having access to the unbound AGP pages as AGP side addresses ? Someone else will have to answer this one... But in general, I don't think that any of the mappings available to the client are revoked or in fact changed in any way on VT switch. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
On Thu, 2004-09-30 at 05:52, Mike Mestnik wrote: I'm interested in switching back and fourth, if any one has some info on doing this better I'd like to know. Right now I'm symlinking libGL-fglrx.so.1.2 or libGL-dri.so.1.2 into libGL.so.1.2. I also have to unload and load kmods too, I do this by hand as well. I can go from DRI to fglrx fine, but to go back I have to reboot first. Gentoo's opengl-update script works great for this, if you feel like moving a few files around on your system. You can grab the most recent version at http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/x11-base/opengl-update/files/opengl-update-1.8.1?rev=HEADcontent-type=text/plain -- Donnie Berkholz Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: winex: ARB_VBO and DirectX for r200 cards.
Mike Mestnik wrote: First I was wondering what it would take, as far as bribes, to get at least as far as the frglx drivers have with supporting this extension. Real support for VBOs is yet another thing blocked on my memory manager work. :( --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Patch removes DRM flush, poll, read functions. It leave the fops entry
null so that the OS default function will be used.
The fops table is converted to be one per driver instead of a global.
This fixes the module open ref count problem. It also simplifies
i810/830 by allow them to directly patch their mmap function into the
fops table.
I spent two days looking for a bug in DRM with multiple drivers under
X. I don't think DRM has problems. I see now that X also fails if two
older DRM drivers are loaded. The first problem seems to be the X's
DRM lock refcount varibale is a static. That won't work for two DRM
drivers.
--
Jon Smirl
[EMAIL PROTECTED]
= linux-core/drmP.h 1.2 vs edited =
--- 1.2/linux-core/drmP.h 2004-09-28 18:26:13 -04:00
+++ edited/linux-core/drmP.h 2004-09-30 13:34:40 -04:00
@@ -523,11 +523,6 @@
struct drm_device;
struct drm_driver_fn {
- u32 driver_features;
- int dev_priv_size;
- int permanent_maps;
- drm_ioctl_desc_t *ioctls;
- int num_ioctls;
int (*preinit)(struct drm_device *, unsigned long flags);
void (*prerelease)(struct drm_device *, struct file *filp);
void (*pretakedown)(struct drm_device *);
@@ -558,6 +553,13 @@
unsigned long (*get_reg_ofs)(struct drm_device *dev);
void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
int (*version)(drm_version_t *version);
+/* variables */
+ u32 driver_features;
+ int dev_priv_size;
+ int permanent_maps;
+ drm_ioctl_desc_t *ioctls;
+ int num_ioctls;
+ struct file_operations fops;
};
@@ -691,8 +693,6 @@
drm_sigdata_t sigdata; /** For block_all_signals */
sigset_t sigmask;
- struct file_operations *fops; /** file operations */
-
struct drm_driver_fn *fn_tbl;
drm_local_map_t *agp_buffer_map;
} drm_device_t;
@@ -757,13 +757,11 @@
extern int drm_fill_in_dev(drm_device_t *dev, struct pci_dev *pdev,
const struct pci_device_id *ent, struct drm_driver_fn *driver_fn);
extern int drm_fb_loaded;
-extern struct file_operations drm_fops;
/* Device support (drm_fops.h) */
extern int drm_open_helper(struct inode *inode, struct file *filp,
drm_device_t *dev);
-extern int drm_flush(struct file *filp);
-extern int drm_fasync(int fd, struct file *filp, int on);
+extern int drm_fasync(int fd, struct file *filp, int on);
/* Mapping support (drm_vm.h) */
extern void drm_vm_open(struct vm_area_struct *vma);
@@ -772,8 +770,6 @@
extern int drm_mmap_dma(struct file *filp,
struct vm_area_struct *vma);
extern int drm_mmap(struct file *filp, struct vm_area_struct *vma);
-extern unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait);
-extern ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off);
/* Memory management support (drm_memory.h) */
#include drm_memory.h
= linux-core/drm_drv.c 1.2 vs edited =
--- 1.2/linux-core/drm_drv.c 2004-09-28 18:26:13 -04:00
+++ edited/linux-core/drm_drv.c 2004-09-30 13:34:40 -04:00
@@ -76,18 +76,6 @@
int drm_fb_loaded = 0;
-struct file_operations drm_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .flush = drm_flush,
- .release = drm_release,
- .ioctl = drm_ioctl,
- .mmap = drm_mmap,
- .fasync = drm_fasync,
- .poll = drm_poll,
- .read = drm_read,
-};
-
/** Ioctl table */
drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = { drm_version, 0, 0 },
@@ -384,7 +372,6 @@
sema_init( dev-ctxlist_sem, 1 );
dev-name = DRIVER_NAME;
- dev-fops = drm_fops;
dev-pdev = pdev;
#ifdef __alpha__
@@ -630,7 +617,7 @@
minor = drm_minors[i];
dev = minor-dev;
DRM_DEBUG(fb loaded release minor %d\n, dev-minor);
- if ((minor-class == DRM_MINOR_PRIMARY) (dev-fops == drm_fops)) {
+ if (minor-class == DRM_MINOR_PRIMARY) {
/* release the pci driver */
if (dev-pdev)
pci_dev_put(dev-pdev);
= linux-core/drm_fops.c 1.1 vs edited =
--- 1.1/linux-core/drm_fops.c 2004-09-28 13:03:33 -04:00
+++ edited/linux-core/drm_fops.c 2004-09-30 13:56:18 -04:00
@@ -116,18 +116,6 @@
}
/** No-op. */
-int drm_flush(struct file *filp)
-{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
-
- DRM_DEBUG(pid = %d, device = 0x%lx, open_count = %d\n,
- current-pid, (long)old_encode_dev(dev-device), dev-open_count);
- return 0;
-}
-EXPORT_SYMBOL(drm_flush);
-
-/** No-op. */
int drm_fasync(int fd, struct file *filp, int on)
{
drm_file_t*priv = filp-private_data;
@@ -140,16 +128,3 @@
return 0;
}
EXPORT_SYMBOL(drm_fasync);
-
-/** No-op. */
-unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait)
-{
- return 0;
-}
-
-
-/** No-op. */
-ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off)
-{
- return 0;
-}
= linux-core/drm_stub.c 1.1 vs edited =
--- 1.1/linux-core/drm_stub.c 2004-09-28 13:03:33 -04:00
+++ edited/linux-core/drm_stub.c 2004-09-30 13:13:25 -04:00
Re: glxinfo: R200 VS FGLRX side by side...
Mike Mestnik wrote:
Here is a straigth diff, I didn't do a udiff since I think we all know the
glxinfo output fairly well. I did make one change s/, $//g and s/, /\n
/g. I'm also attaching the 'source'.
A better way to get meaningful diffs is to pipe the output of glxinfo
to grep GL_ | sed 's/, /\n/g' | sort -u. It's a bit more tricky for
GLX extensions because there are multiple listings for that (client,
server, and combined).
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate? Beyond that, there are basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
Crossbar, point parameters, and multi draw arrays should be easy enough
to add. I tried to add support for fog coord, but there's some bit of
documentation that we're missing. I just could not get it to work in
TCL mode. :( For occlusion query, we're missing a significant amount of
documentation.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1501] libGL causes double free.
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://freedesktop.org/bugzilla/show_bug.cgi?id=1501 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 11:53 --- Created an attachment (id=985) -- (https://freedesktop.org/bugzilla/attachment.cgi?id=985action=view) Trivial fix Please apply to lib/GL/glx/glxext.c -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1501] New: libGL causes double free.
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://freedesktop.org/bugzilla/show_bug.cgi?id=1501 Summary: libGL causes double free. Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: libGL AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Under certain circumstances (when /dev/dri/card* is not readable for a user) libGL may cause a double free. Some versions of glibc will catch this situation now. The attached patch will fix this problem. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
Ian Romanick schrieb:
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate?
ATI sometimes makes strage decicions about the features their drivers
support: Even though the r200 could support GL_ARB_vertex_shader just
as the r300 does, they only expose GL_ARB_vertex_program.
Beyond that, there are basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
I once tried simply enabling GL_EXT_multi_draw_arrays, but there was
a problem: When calling glMultiDrawElementsEXT while creating a display
list the r200 driver called a Mesa function which wasn't to be called
when creating display lists.
Philipp
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
Here is a straigth diff, I didn't do a udiff since I think we all know the
glxinfo output fairly well. I did make one change s/, $//g and s/, /\n
/g. I'm also attaching the 'source'.
A better way to get meaningful diffs is to pipe the output of glxinfo
to grep GL_ | sed 's/, /\n/g' | sort -u. It's a bit more tricky for
GLX extensions because there are multiple listings for that (client,
server, and combined).
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate? Beyond that, there are basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
Crossbar, point parameters, and multi draw arrays should be easy enough
to add. I tried to add support for fog coord, but there's some bit of
documentation that we're missing. I just could not get it to work in
TCL mode. :( For occlusion query, we're missing a significant amount of
documentation.
Vladimir's glxtest code may be helpful in figuring out the missing
bits if anyone is so inclined...
Alex
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
On Thu, 30 Sep 2004 21:21:43 +0200, Philipp Klaus Krause [EMAIL PROTECTED] wrote:
Ian Romanick schrieb:
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate?
ATI sometimes makes strage decicions about the features their drivers
support: Even though the r200 could support GL_ARB_vertex_shader just
as the r300 does, they only expose GL_ARB_vertex_program.
sure, to sell more new hardware... They also might have not felt it
was worth the time to re-architect the existing driver to add a new
feature to an old product, especially if it would have involved major
work.
Alex
Beyond that, there are basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
I once tried simply enabling GL_EXT_multi_draw_arrays, but there was
a problem: When calling glMultiDrawElementsEXT while creating a display
list the r200 driver called a Mesa function which wasn't to be called
when creating display lists.
Philipp
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1501] libGL causes double free.
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://freedesktop.org/bugzilla/show_bug.cgi?id=1501 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 14:37 --- applied, thanks. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
What to do about shared files and drm-core?
What do we want to do about drm-core vs the old build model? There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. If the choice is to declare 2.4 finished then there is a lot of cruft that can be removed from the 2.6 linux-core code. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On Thu, 2004-09-30 at 16:47, Jon Smirl wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/linux-core/ Changes by: [EMAIL PROTECTED] 04/09/30 16:47:45 Log message: Make the debug memory functions compile for the core model. Has anybody ever used the drm memory debug functions? I would be inclined to see them go away. Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
On Thu, 2004-09-30 at 16:52, Jon Smirl wrote: What do we want to do about drm-core vs the old build model? There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. If the choice is to declare 2.4 finished then there is a lot of cruft that can be removed from the 2.6 linux-core code. When I get some time, I'll probably move the BSD stuff to the core model. I'm not a huge fan of it, but it's ok. The one concern I had was unconditional dependency on AGP, but I've talked it over and we can do some reworking in the kernel that we've been saying was necessary anyway and avoid unconditionally requiring AGP. I would prefer to see the changes for the core live in shared/ like always and have the current directories disappear, but it's not a big deal. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
I would prefer to see the changes for the core live in shared/ like always and have the current directories disappear, but it's not a big deal. Merging the shared dirs is not a major undertaking, you could do it with some static inlines in the platform directories to deal with the lack of DRM() macros... I might get time later (I never tire of saying that...), am trying to track down why doublebuffering don't work in solo at the moment, I've tracked it down to the cliprects but my hangover is working against me not to mention my lack of knowledge of GLX... 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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Software emulation of shaders.. sw-shader
Hello! When browsing the web I found this: http://sw-shader.sf.net. It's full software implementation of DX9 for windows.. using SIMD/SSE/MMX. Could this help Mesa in any way? Mainly the shader optimizations.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Segfault on RTCW with Savage
A while back I mentioned on dri-devel that Savage cards will segfault RTCW
while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple fix
which eliminates the problem.
John Lightsey
--- xc/../Mesa/src/mesa/tnl/t_vertex.c.orig 2004-09-30 16:59:08.0 -0500
+++ xc/../Mesa/src/mesa/tnl/t_vertex.c 2004-09-30 16:59:58.0 -0500
@@ -741,9 +741,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
end -= start;
@@ -913,9 +915,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
vtx-emit = 0;
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 29 Sep 2004 13:37:59 +0100, Christoph Hellwig [EMAIL PROTECTED] wrote: Some ideas that would be nice improvements still (not that some may be inherited from the old drm code, I just looked at the CVS checkout): - once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full -probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. This would get rid of the -preinit and -postinit hooks. This has to stay the way it currently is because of the stealth mode code - isn't drm_order just a copy of get_order()? switched to get_order - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? doc people don't want to switch - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent ran most of it through Lindent. check out CVS for results. - care to use linux/lists.h instead of opencoded lists, e.g. in dev-file_last/dev-file_first or dev-vmalist There are about 20 open coded lists. I started to fix some of these but the code involved can be touchy and it's already well tested. It would be better to wait on these until someone is working on the code involved. I don't want to introduce bugs because I don't understand the code 100%. - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read Changed these to use kernel defaults. - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? That can probably be fixed. I believe it is because it is hiding a 2.4/2.6 change. - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c I started to do this to but I didn't want to disrupt know working code. These may get rewritten for sysfs. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
I haven't moved anything out of shared, it's all paralleled in shared-core. 90% of the changes are from DRM() macro removal. I did eliminate one header file for each device since I kept deleting things until they were empty. 2.4 is a bigger question to me. For example 2.6 is adding the idr_xxx support for dealing with dynamic minors. 2.6 also has a new system for /proc files. Another one is the cdev support for partially reserving minors. There are lot's of sysfs changes needed too. Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6 before it drifts too far from being able to run on 2.4. I suspect linux-core would compile on 2.4 right now with minor changes. Or is it better just to declare 2.4 finished as is? -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
