Re: [patch drm] via unichrome improvements
Joris van Rantwijk wrote: Hello, I modified some things in the VIA DRM driver to get it working properly on my K8M800 Unichrome Pro chipset under Linux. I also got it working on a x86_64 kernel with a 32-bit usermode system. Could someone on this list please look through my patches and maybe commit some things? I hope my work can be useful to others. Below is a description of each patch. They are largely independent of eachother. All patches are against the current CVS. 01_via_unichrome_pro Trivial patch to make the VIA driver recognize my PCI id as a Unichrome Pro chipset. This makes IRQ handling work properly and avoids the kernel message irq 201: nobody cared (try booting with the irqpoll option) 02_via_verifier_bugfix Trivial fix to the VIA command verifier. The bug caused it to accept some invalid commands on i386 and reject valid commands on x86_64. 03_via_mm_cleanup Rework the FB and AGP memory management in the VIA driver so that it no longer blindly passes kernel pointers to and from userspace. This was a security issue on i386 and a fundamental problem with 32-bit compatibility on x86_64. 04_via_ioctl_security Enable privilege checking on those ioctls that seem to be intended for the X server only. Don't know if there was a particular reason why this wasn't done before. 05_via_futex_niceabort Avoid Oops and X server crash when something goes wrong during DRM initialization. 06_via_compat32 Compatibility wrappers around the VIA ioctls to make it work with a 32-bit usermode system on a x86_64 kernel. Thanks, Joris. Hi, Joris. Thanks for having done this! Some first comments: Patch 1: The K8M800/K8N800 is not a unichrome pro group A but rather a unichrome pro group B, and lacks most of the group A features both when it comes to IRQ capability and video DMA commands, so it is wrong to enable group A features. However, if this fixes the IRQ nobody cared problem it needs to be investigated further. I have the same problem on my K8M800/K8N800 computers, but when a stray interrupt occurs, nothing is seen in the Unichrome IRQ status register, and returning IRQ_HANDLED will make the unichrome issue about 30 interrupts per second. I've asked VIA about this and their first response is that the IRQ functionality was never verified on chipsets not having video capture functionality. Could you further investigate exactly why the patch fixes this error? Some looks into /proc/interrupts to determine IRQ frequency? Does it work also in 64 bit mode? Patch 2: Is correct and will be commited as soon as possible. Patch 3: I agree that there is checking needed for the returned index values, but can't this be solved using range checking on the kernel pointers, or perhaps store the pointers in a hash table, the content of which is verified before a memblock is freed? It seems very inefficient to loop through the block map (up to 5000 blocks) on each allocation. BTW How does the current solution interfere with x86-64? Here it works nicely except the kernel crashes when it tries to free unfreed memory blocks in final_context, but I haven't been able to track down the cause yet. Patch 4: An oversight in the initial code. It seems correct except for the DMA_INIT ioctl where the privilege checking is done within the IOCTL code. Patch 5: Correct. Will go in. Patch 6: Long awaited. Have to look a bit more into it. Regards Thomas --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
State of the SiS driver
I have some questions about the SiS driver: 1) The SiS driver looks different from the other drivers. It doesn't have a custom tnl_pipeline as all the other drivers except tdfx do. Was this some old style of writing drivers and all others have already been converted? 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? 3) Is there any documentation for the SiS 305. I mean, what did the people that wrote this driver use? Or is it just a 6326 with another texture unit added so the documentation for the 6326 was used? The wiki says there is no documentation except that two documents from UtahGLX which obviously aren't enough for writing a driver. Was this driver released by SiS or was the chip reverse-engineered? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch drm] via unichrome improvements
Hello Thomas,
Thanks for your positive feedback.
On Sun, Aug 14, 2005 at 09:38:45AM +0200, Thomas Hellstr?m wrote:
01_via_unichrome_pro
Trivial patch to make the VIA driver recognize my PCI id as
a Unichrome Pro chipset. This makes IRQ handling work properly
and avoids the kernel message
irq 201: nobody cared (try booting with the irqpoll option)
I have the same problem on my K8M800/K8N800 computers, but when a stray
interrupt occurs, nothing is seen in the Unichrome IRQ status register,
and returning IRQ_HANDLED will make the unichrome issue about 30
interrupts per second. I've asked VIA about this and their first
response is that the IRQ functionality was never verified on chipsets
not having video capture functionality.
I was not aware of this, and unfortunately you seem to be right. I am
getting 30 interrupts per second with this patch. Completely missed
that, although I did have the impression that my system was a bit
slow overall. Some of these interrupts are genuine VBLANKs, but I
can't figure out how to disable the spurious interrupts.
Patch 3: I agree that there is checking needed for the returned index
values, but can't this be solved using range checking on the kernel pointers,
or perhaps store the pointers in a hash table, the content of which is
verified before a memblock is freed?
It seems very inefficient to loop through the block map (up to 5000
blocks) on each allocation.
My solution is not less efficient than the old situation. The old mm code
can do fast mem_alloc() but will loop through all allocated blocks on
mem_free() (twice). My current solution will loop on mem_alloc() but has
a faster mem_free().
If you are concerned, I can use hashing to speed up mem_alloc(). I did
this originally but then thought it not worthwhile. A possible approach
is attached as 03a_via_mm_cleanup. This will of course turn slow again
when the number of allocated blocks passes a certain treshold.
BTW How does the current solution interfere with x86-64?
Here it works nicely except the kernel crashes when it tries to free
unfreed memory blocks in final_context, but I haven't been able to track
down the cause yet.
The old solution passes a kernel pointer to userspace as a unsigned long.
This should work in i386 as well as pure x86_64, but not in x86_64 with
32-bit compatibility. To be honest, I did not even test it; it simply
cannot work.
Patch 4: An oversight in the initial code. It seems correct except for
the DMA_INIT ioctl where the privilege checking is done within the IOCTL
code.
Right. I missed the check in the ioctl.
Bye,
Joris.
diff -urN -U 5 drm.prev/shared-core/via_mm.c drm/shared-core/via_mm.c
--- drm.prev/shared-core/via_mm.c 2005-08-14 11:10:23.0 +0200
+++ drm/shared-core/via_mm.c2005-08-14 11:19:24.0 +0200
@@ -23,52 +23,131 @@
*/
#include drmP.h
#include via_drm.h
#include via_drv.h
#include via_ds.h
-#include via_mm.h
#define MAX_CONTEXT 100
+#define MAX_MEMBLOCK_INDEX 5003
+
+/* Structure which maps indices to PMemBlock pointers.
+ index_base is used to make indices globally unique among
+ multiple mem_block_map_t structures, and to avoid ever using
+ the special value 0 as an index. */
+typedef struct {
+ unsigned int index_base;
+ PMemBlock m[MAX_MEMBLOCK_INDEX];
+} mem_block_map_t;
typedef struct {
int used;
int context;
- set_t *sets[2]; /* 0 for frame buffer, 1 for AGP , 2 for System
*/
+ mem_block_map_t *map[2]; /* 0 for frame buffer, 1 for AGP */
} via_context_t;
static via_context_t global_ppriv[MAX_CONTEXT];
static int via_agp_alloc(drm_via_mem_t * mem);
static int via_agp_free(drm_via_mem_t * mem);
static int via_fb_alloc(drm_via_mem_t * mem);
static int via_fb_free(drm_via_mem_t * mem);
-static int add_alloc_set(int context, int type, unsigned int val)
+/*
+ * Allocate a mem_block_map_t and initialize it to make all indices
+ * point to NULL. index_base must be non-zero
+ */
+static mem_block_map_t * via_mem_block_map_init(unsigned int index_base)
{
- int i, retval = 0;
+ mem_block_map_t *map;
+ int i;
- for (i = 0; i MAX_CONTEXT; i++) {
- if (global_ppriv[i].used global_ppriv[i].context == context)
{
- retval = via_setAdd(global_ppriv[i].sets[type], val);
- break;
- }
+ map = drm_alloc(sizeof(mem_block_map_t), DRM_MEM_DRIVER);
+ if (map) {
+ map-index_base = index_base;
+ for (i = 0; i MAX_MEMBLOCK_INDEX; i++)
+ map-m[i] = NULL;
}
-
- return retval;
+ return map;
}
-static int del_alloc_set(int context, int type, unsigned int val)
+/*
+ * Destroy a mem_block_map_t and release allocated memory.
+ */
+static void via_mem_block_map_destroy(mem_block_map_t *map)
{
- int i, retval = 0;
+ drm_free(map,
[Bug 4031] Mach64: Mesa does not compile. /usr/bin/ld: cannot find -lEGL
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4031 --- Additional Comments From [EMAIL PROTECTED] 2005-08-14 20:30 --- (In reply to comment #5) I forgot to say something: make clean does not delete the drivers in Mesa/lib and it is necessary to delete manually delete them before a new compilation. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Xegl on old hardware?
What are the minimum requirements of Xegl in terms of extensions supported? Which modifications to a driver are necessary for EGL? Wich parts of the driver (DRM, fb, DRI) have to be modified? Will Xegl run fast enough on old hardware like the RagePro 3D or the SiS 305 or Sis 6326? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture ARB_texture_env_combine Which modifications to a driver are necessary for EGL? Wich parts of the driver (DRM, fb, DRI) have to be modified? The drm/fb layer has to be smart enough to set video modes, and the DRI driver needs some new entrypoints to translate that functionality to the EGL_MESA_screen_surface extension. Will Xegl run fast enough on old hardware like the RagePro 3D or the SiS 305 or Sis 6326? Well no one has tried, so no one knows yet. mach64 will likely have correctness issues due to its craptastic alpha combiner. I would expect acceptable (for some value of acceptable) performance for cards at about the voodoo3 or rage128 level, and anything below that really depends on how clever the driver is and whether the hardware has useful features we can take advantage of. I'm hoping to get back to hacking on EGL stuff once 7.0 lands. - ajax pgpiDuwe3nzL1.pgp Description: PGP signature
Re: VIA DRM port to FreeBSD
Hi! Eric Anholt wrote: [EMAIL PROTECTED] sent me a port of the VIA DRM to FreeBSD. However, it left a couple of rough edges (most of them preexisting), which I tried to clean up. Attached is the diff against DRM CVS HEAD. I've compile-tested on Linux and FreeBSD, but I don't have any hardware. Could someone test the diff so I can commit? I've tested on Linux, and as far as I can see it doesn't break anything. Note however recent changes to the ioctl permissions, and I will be commiting the pci dma blit code soon and which is a bit linux specific and will end up in linux-core, but I'll hold off until your bsd code is commited. The client code using the PCI DMA stuff will not end up in the upcoming Xorg release, however. BTW Eric, If I remember correctly you had a completely new memory manager implementation for the SiS driver posted a year or so ago. Any plans to port that to via? Joris van Rantwijk has some security / x86-64 patches for the current implementation, but It would be good to clean it all up in one go, and possibly apply his changes on top of a new memory manager implementation. /Thomas --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
Adam Jackson schrieb: On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle This shouldn't be really necessary if one is willing to waste some texture memory. ARB_texture_border_clamp The r128 for example supports it, but it's not yet exposed in the free driver. ARB_multitexture OK. Everything except the SiS 6326 should supports it, though I don't know about mach64 (the driver has the extension, but I don't think the hardware has really more than one texture unit). ARB_texture_env_combine SiS 305 and 6326 don't support it. Neither do r128 or mach64. Maybe I'll see if I can get Xgl eunning on the r128 or some other older card. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Patch: r128 software features
Since the r128 has no hardware tcl and tcl has to be
done in software anyway I think it should have a
full-featured tcl. This patch enables some extensions:
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_EXT_cull_vertex
GL_EXT_multi_draw_arrays
GL_MESA_pack_invert
GL_NV_vertex_program
GL_NV_vertex_program1_1
The last two can be disabled using driconf if desired
for the same reasons I made them disabled by default
when I added vertex program support to the r200 driver
a year ago.
I tested with the programs in Mesa/progs/demos and
Mesa/progs/tests and everything seems to work fine
except vptest1 and vptest2. Since these two
don't work on my i915 either I suppose the problem is
with Mesa's program parsing and not r128-specific.
Philipp
? depend
? r128_software.patch
Index: r128_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_context.c,v
retrieving revision 1.19
diff --unified -r1.19 r128_context.c
--- r128_context.c 28 Jul 2005 00:29:52 - 1.19
+++ r128_context.c 14 Aug 2005 18:29:42 -
@@ -68,7 +68,12 @@
#define need_GL_ARB_multisample
#define need_GL_ARB_texture_compression
+#define need_GL_ARB_vertex_buffer_object
+#define need_GL_ARB_vertex_program
#define need_GL_EXT_blend_minmax
+#define need_GL_EXT_cull_vertex
+#define need_GL_EXT_multi_draw_arrays
+#define need_GL_NV_vertex_program
#include extension_helper.h
const struct dri_extension card_extensions[] =
@@ -78,14 +83,26 @@
{ GL_ARB_texture_compression,GL_ARB_texture_compression_functions },
{ GL_ARB_texture_env_add,NULL },
{ GL_ARB_texture_mirrored_repeat,NULL },
+{ GL_ARB_vertex_buffer_object, GL_ARB_vertex_buffer_object_functions },
+{ GL_ARB_vertex_program, GL_ARB_vertex_program_functions },
{ GL_EXT_blend_subtract, GL_EXT_blend_minmax_functions },
+{ GL_EXT_cull_vertex,GL_EXT_cull_vertex_functions },
+{ GL_EXT_multi_draw_arrays, GL_EXT_multi_draw_arrays_functions },
{ GL_EXT_texture_edge_clamp, NULL },
+{ GL_MESA_pack_invert, NULL },
{ GL_MESA_ycbcr_texture, NULL },
{ GL_NV_blend_square,NULL },
{ GL_SGIS_generate_mipmap, NULL },
{ NULL,NULL }
};
+const struct dri_extension NV_vp_extensions[] = {
+{ GL_NV_vertex_program, GL_NV_vertex_program_functions },
+{ GL_NV_vertex_program1_1, NULL },
+{ NULL,NULL }
+};
+
+
static const struct dri_debug_control debug_control[] =
{
{ ioctl, DEBUG_VERBOSE_IOCTL },
@@ -248,6 +265,8 @@
driInitExtensions( ctx, card_extensions, GL_TRUE );
if (sPriv-drmMinor = 4)
_mesa_enable_extension( ctx, GL_MESA_ycbcr_texture );
+ if(driQueryOptionb(rmesa-optionCache, nv_vertex_program))
+ driInitExtensions( ctx, NV_vp_extensions, GL_FALSE );
r128InitTriFuncs( ctx );
r128DDInitStateFuncs( ctx );
Index: r128_dd.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_dd.c,v
retrieving revision 1.5
diff --unified -r1.5 r128_dd.c
--- r128_dd.c 4 May 2005 20:11:38 - 1.5
+++ r128_dd.c 14 Aug 2005 18:29:42 -
@@ -44,7 +44,7 @@
#include utils.h
-#define DRIVER_DATE 20041026
+#define DRIVER_DATE 20050814
/* Return the width and height of the current color buffer.
Index: r128_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_screen.c,v
retrieving revision 1.21
diff --unified -r1.21 r128_screen.c
--- r128_screen.c 29 Jul 2005 00:19:36 - 1.21
+++ r128_screen.c 14 Aug 2005 18:29:43 -
@@ -68,11 +68,14 @@
DRI_CONF_PERFORMANCE_BOXES(false)
#endif
DRI_CONF_SECTION_END
+DRI_CONF_SECTION_SOFTWARE
+DRI_CONF_NV_VERTEX_PROGRAM(true)
+DRI_CONF_SECTION_END
DRI_CONF_END;
#if ENABLE_PERF_BOXES
-static const GLuint __driNConfigOptions = 4;
+static const GLuint __driNConfigOptions = 5;
#else
-static const GLuint __driNConfigOptions = 3;
+static const GLuint __driNConfigOptions = 4;
#endif
extern const struct dri_extension card_extensions[];
Re: State of the SiS driver
On 8/14/05, Philipp Klaus Krause [EMAIL PROTECTED] wrote: I have some questions about the SiS driver: 1) The SiS driver looks different from the other drivers. It doesn't have a custom tnl_pipeline as all the other drivers except tdfx do. Was this some old style of writing drivers and all others have already been converted? 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz 3) Is there any documentation for the SiS 305. I mean, what did the people that wrote this driver use? Or is it just a 6326 with another texture unit added so the documentation for the 6326 was used? The wiki says there is no documentation except that two documents from UtahGLX which obviously aren't enough for writing a driver. Was this driver released by SiS or was the chip reverse-engineered? The driver was initially written by SiS. Eric Anholt cleaned it up and ported it to the current mesa a year or two ago. As I recall SiS never released any databooks for the 3d engine on the 300 series chips. Alex Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
On Sunday 14 August 2005 14:15, Philipp Klaus Krause wrote: Adam Jackson schrieb: NV_texture_rectangle This shouldn't be really necessary if one is willing to waste some texture memory. In some cases, quite a lot of memory. A 513x513 texture wastes between 1.5 and 3M of memory depending on your color depth. You could offset this some by artificially lowering the maximum texture size. That's probably not a terrible idea for a tunable anyway, since a few older cards have fairly small texture caches and 512^2 textures will basically defeat them. ARB_multitexture OK. Everything except the SiS 6326 should supports it, though I don't know about mach64 (the driver has the extension, but I don't think the hardware has really more than one texture unit). There's a lot of cards that don't support this, just not many that we have drivers for. Pretty sure the virge and savage3d don't really support this, for example. Maybe I'll see if I can get Xgl eunning on the r128 or some other older card. Try the Xglx server first. In the steady state (not moving the Xglx window) your performance should be within a wild-assed guess of about 10-20% of what you might see from Xegl. To be accurate, Xegl relative to Xglx eliminates a few round trips for things like drawable and context creation, clip list updates, and buffer swaps. Those aren't often the bottleneck. Also you wouldn't have your classic DDX chewing up card memory for offscreen pixmaps, which you might be able to work around with suitable use of XAA options. This is not meant to discourage, we really do want to know where the cutoff point is for tolerable performance on older cards. But Xglx will give you a reasonable idea of what's possible. And it's the same driver for both GLX and EGL, so improvements to the one side help the other side too. - ajax pgpBpUamxQQsJ.pgp Description: PGP signature
Re: State of the SiS driver
Alex Deucher schrieb: 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz This only contains the DRI part. Does that mean it uses the same DRM as the 305? --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: State of the SiS driver
On 8/14/05, Philipp Klaus Krause [EMAIL PROTECTED] wrote: Alex Deucher schrieb: 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz This only contains the DRI part. Does that mean it uses the same DRM as the 305? As I recall, yes. Alex --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
On Sun, 2005-08-14 at 13:50 -0400, Adam Jackson wrote: On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture ARB_texture_env_combine Some kind of render-to-texture functionality (preferably framebuffer objects) will probably be crucial, at least for compositing. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: State of the SiS driver
On Sul, 2005-08-14 at 21:03 +0200, Philipp Klaus Krause wrote: not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz This only contains the DRI part. Does that mean it uses the same DRM as the 305? There is a small patch to the 2D driver needed and the 3D driver needs the PCI ids adding. As it stands the sis6326 driver bypasses the DRM most of the time at the moment for debugging and just whacks the hardware as root. I can dig out the other bits if you are interested but I would suggest a better idea would be to buy a real video card 8) --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
Adam Jackson wrote: On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture ARB_texture_env_combine Those are quite stiff requirements though. None of the old chips support all of that fully. Especially ARB_texture_env_combine (or even the EXT variant) could be tricky. I'm not sure what parts of it Xegl really needs, but on something like the plain rage 128 (can't even do normal GL_BLEND in all cases) you could probably easily end up with software fallbacks most of the time. Or, take a look at the voodoo3 driver, which has the most strange tex combine setup ever (confusing as hell, set up very unobvious, it's unclear to me though if the hardware capabilities are really exposed that strange, if the driver is written in an odd way or if glide acts as an obfuscation layer). It has fixed setups for BOTH texture environments combined! Hard to tell if it would support ARB_texture_env_combine somewhat reasonably, the driver at least certainly would need a rewrite in that area at least if it indeed does. And, of course, some otherwise not too bad chips like the g200 can't even do multitexturing :-(. Roland --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
