Re: IGP 340M textures?
- Original Message - From: Roland Scheidegger [EMAIL PROTECTED] To: Christer Backstrom [EMAIL PROTECTED] Subject: Re: IGP 340M textures? Date: Mon, 20 Dec 2004 00:32:28 +0100 Christer Backstrom wrote: Here, the lappy hangs hard when trying any 3D application on x.org-6.8.1, but while using XFree-4.4.0 I can get about 400fps with glxgears. Trying anything more advanced gives (kfountain.kss 3D screensaver): disabling TCL support drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) on the console. Furthermore I get: I don't think the bugs with xfree-4.4 and xorg you're seeing are related at all. afaik XFree86 4.4 does not support dri with IGPs properly, so I wouldn't worry about that (I'd suspect the other notebook wouldn't work with XFree86 4.4 neither). OK, should have written XFree86-4.4.0 patched with IGP drm patch (bug 314) http://bugs.xfree86.org/show_bug.cgi?id=314 My bad. But the AMD lappy actually works fine with the 314 patch. The dri driver has no separate code for igp 340/320/345 chipsets at all (except the pci ids), the 3d graphic core is 100% identical afaik (safe maybe from different clocks). Thats pretty much what I thought, but because the error message identified a R100 chip, I still wondered if there was a bug somewhere. Perhaps the error message should say R100/RS200 instead. Whatever. It looks to me like the lockups could be related to the dynamic clock code, though I'm no expert on that. This code is even asic revision dependant in some cases, so it's exactly the sort of issue you'd expect to show up with some igp but not another seemingly identical one. It should be fixed in xorg cvs and in xorg 6.8.2 branch. https://bugs.freedesktop.org/show_bug.cgi?id=1912 You're 100% right here. Sorry, I didn't get the connection there. I pathched up 6.8.1 and recompiled. Works fine now. Thanks a bunch! Still only got 400fps on glxgears, though, whereas I would have expected about 1000fps. On another note: anyone know why atitvout stopped working when I upgraded to x.org? Cheers, /Chris -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Looking for some answers.
This defenatly belongs on another Xrelated list. --- Austin Yuan [EMAIL PROTECTED] wrote: On Sat, Dec 18, 2004 at 04:54:20AM +0800, Alex Deucher wrote: On Fri, 17 Dec 2004 10:35:42 +, Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? maybe. they will probably co-exist for the forseeable future. regular multi-head allows you do have two independant X servers while mergedfb always creates one single logical desktop. I have a question about regular multi-head with one card,two screens. It allows we use two independant desktops. But from /etc/X11/xorg.conf,keyboard and mouse configuration are included into ServerLayout section,not Screen section. It seems that one Xserver can't use two independant keyboard and mouse. If I want to do a thing like this: one machine,1 video card with 2 CRTS,2 mice, 2 keyboard. The individual keyboard/mouse is intended to work with one CRT, so that 2 person can use one machine at the same time. But one Xserver cann't handle this circumstance. Miguel gave us a method on http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/g450.html. But it needs to hack Xserver, and start up two Xservers running on fbdev. Do you have some comment on this issue? I would quote the original document... I would love to see XFree86 supporting simultaneous layouts (without another instance). The X(7x) manpage has some info on how this should work under it's DISPLAY NAMES section. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2092] _radeon_texrect_stage looks broken
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=2092 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 05:02 --- It looks like texrect works with the old (==current), template based radeon_swtcl.c code. But it doesnt work with t_vertex based code. Your change seems to fix that. -- 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 email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP 340M textures?
On Mon, 20 Dec 2004 10:31:13 +, Christer Backstrom [EMAIL PROTECTED] wrote: - Original Message - From: Roland Scheidegger [EMAIL PROTECTED] To: Christer Backstrom [EMAIL PROTECTED] Subject: Re: IGP 340M textures? Date: Mon, 20 Dec 2004 00:32:28 +0100 Christer Backstrom wrote: Here, the lappy hangs hard when trying any 3D application on x.org-6.8.1, but while using XFree-4.4.0 I can get about 400fps with glxgears. Trying anything more advanced gives (kfountain.kss 3D screensaver): disabling TCL support drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) on the console. Furthermore I get: I don't think the bugs with xfree-4.4 and xorg you're seeing are related at all. afaik XFree86 4.4 does not support dri with IGPs properly, so I wouldn't worry about that (I'd suspect the other notebook wouldn't work with XFree86 4.4 neither). OK, should have written XFree86-4.4.0 patched with IGP drm patch (bug 314) http://bugs.xfree86.org/show_bug.cgi?id=314 My bad. But the AMD lappy actually works fine with the 314 patch. The dri driver has no separate code for igp 340/320/345 chipsets at all (except the pci ids), the 3d graphic core is 100% identical afaik (safe maybe from different clocks). Thats pretty much what I thought, but because the error message identified a R100 chip, I still wondered if there was a bug somewhere. Perhaps the error message should say R100/RS200 instead. Whatever. It looks to me like the lockups could be related to the dynamic clock code, though I'm no expert on that. This code is even asic revision dependant in some cases, so it's exactly the sort of issue you'd expect to show up with some igp but not another seemingly identical one. It should be fixed in xorg cvs and in xorg 6.8.2 branch. https://bugs.freedesktop.org/show_bug.cgi?id=1912 You're 100% right here. Sorry, I didn't get the connection there. I pathched up 6.8.1 and recompiled. Works fine now. Thanks a bunch! Still only got 400fps on glxgears, though, whereas I would have expected about 1000fps. On another note: anyone know why atitvout stopped working when I upgraded to x.org? There was code added to disable BIOS output toggling since the X server doesn't yet support acpi events so there's no way to validate modes for a new output device and the bios can potentially do things behind the driver's back. I added an option to xorg cvs to re-enable the old behavior, BIOSHotkeys. Alex Cheers, /Chris --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Looking for some answers.
On Mon, 20 Dec 2004 10:53:26 -0400, Austin Yuan [EMAIL PROTECTED] wrote: On Sat, Dec 18, 2004 at 04:54:20AM +0800, Alex Deucher wrote: On Fri, 17 Dec 2004 10:35:42 +, Ian Molton [EMAIL PROTECTED] wrote: Hi. Is MergedFB going to replace xinerama in the long run? maybe. they will probably co-exist for the forseeable future. regular multi-head allows you do have two independant X servers while mergedfb always creates one single logical desktop. I have a question about regular multi-head with one card,two screens. It allows we use two independant desktops. But from /etc/X11/xorg.conf,keyboard and mouse configuration are included into ServerLayout section,not Screen section. It seems that one Xserver can't use two independant keyboard and mouse. If I want to do a thing like this: one machine,1 video card with 2 CRTS,2 mice, 2 keyboard. The individual keyboard/mouse is intended to work with one CRT, so that 2 person can use one machine at the same time. But one Xserver cann't handle this circumstance. Miguel gave us a method on http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/g450.html. But it needs to hack Xserver, and start up two Xservers running on fbdev. Do you have some comment on this issue? The problem has to do with VT's and X's input system. There were some threads on dri-devel, xorg, and LKML a few months back (I think started by Jon Smirl) about this. There are several patches floating around to enable this functionality. I'm not sure when an official version will hit any offical trees. I think the details are still being sorted out. I'd like to see this kind of support as well. Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
On Gwe, 2004-12-17 at 20:55, Mike Werner wrote: [2/4] Run Lindent on generic.c Please don't mix reformatting with oither submissions, especially as Dave Jones is parallel working on and submitting patches for the various cache/tlb flush violations in the current code that will overlap such a reformatting. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Post-processing hook for vertex setup code
Felix Kühling wrote: Hi Keith, I'm attaching my current solution for the Savage driver. I'm going to commit this later today. It doesn't need any modifications of the common TNL code. It is probably not the most efficient solution though, since it requires an indirect function call for each emitted vertex. That said, I havn't noticed any performance regressions which may be because the Savage hardware is quite slow in relation to my CPU (mobile Athlon XP 2000+). Also see my comments below ... Am Sa, den 18.12.2004 schrieb Keith Whitwell um 0:37: Felix Kühling wrote: Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: [snip] Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Right. But that would have been broken with t_dd_vbtmp.h too. ;-) No, t_dd_vbtmp.h *does* undo the projection, look around line 534. Ok, sorry. I missed that detail. Though I do have a question about this code: rqdst = 1.0 / qdst; dst-v.u0 *= rqdst; dst-v.v0 *= rqdst; dst-v.w *= rqdst; Shouldn't the last line say: dst-v.w *= qdst; I don't claim to understand the math behind this completely, but that would be the analogue thing to the code around line 277. [ ... your other reply ... ] I can think of the i810 and mga which both have this projective texture issue *and* have the fast path (in i810render.c and mga_render.c respectively). It (used to be?) a worthwhile optimization. I didn't know about the i810 driver. But in the MGA driver the render stage is disabled. AFAICT it has been since the transition to Mesa 4. Anyway, my solution is very driver-specific. Whoever is going to port this to i810 will have to deal with the fallback case to the _tnl_render_stage. I'd like to implement a render stage for the Savage driver at some point. This way we could reduce the number of vertices emitted to the hardware by using triangle strips and fans where appropriate. It would also minimize the impact of indirect function calls per vertex. Hi Felix, Your patch looks good to me. If you're looking for ways to avoid the indirect function call, probably the way to do it is to somehow try and get onto the DO_FALLBACK path. This is difficult for PTEX vertices as there is no GL state to say 'OK, I'm going to do PTEX vertices now', it is just based on what comes down the pipe, and we don't have a very good set of triggers for that. But, if you could find a way to detect that you were expecting PTEX vertices, then the i915 driver (intel_tris.c, intel_atten_point()) might be a model for how to do this. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Post-processing hook for vertex setup code
Hi Keith,
I'm attaching my current solution for the Savage driver. I'm going to
commit this later today. It doesn't need any modifications of the common
TNL code. It is probably not the most efficient solution though, since
it requires an indirect function call for each emitted vertex. That
said, I havn't noticed any performance regressions which may be because
the Savage hardware is quite slow in relation to my CPU (mobile Athlon
XP 2000+).
Also see my comments below ...
Am Sa, den 18.12.2004 schrieb Keith Whitwell um 0:37:
Felix Kühling wrote:
Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59:
[snip]
Secondly, is the obvious counter-concern -- what happens with clipping?
The 'post processing' probably needs to be undone so that clipping can
proceed, then be re-done on the clipped vertices, right?
Right. But that would have been broken with t_dd_vbtmp.h too. ;-)
No, t_dd_vbtmp.h *does* undo the projection, look around line 534.
Ok, sorry. I missed that detail. Though I do have a question about this
code:
rqdst = 1.0 / qdst;
dst-v.u0 *= rqdst;
dst-v.v0 *= rqdst;
dst-v.w *= rqdst;
Shouldn't the last line say:
dst-v.w *= qdst;
I don't claim to understand the math behind this completely, but that
would be the analogue thing to the code around line 277.
[ ... your other reply ... ]
I can think of the i810 and mga which both have this projective texture
issue *and* have the fast path (in i810render.c and mga_render.c
respectively). It (used to be?) a worthwhile optimization.
I didn't know about the i810 driver. But in the MGA driver the render
stage is disabled. AFAICT it has been since the transition to Mesa 4.
Anyway, my solution is very driver-specific. Whoever is going to port
this to i810 will have to deal with the fallback case to the
_tnl_render_stage.
I'd like to implement a render stage for the Savage driver at some
point. This way we could reduce the number of vertices emitted to the
hardware by using triangle strips and fans where appropriate. It would
also minimize the impact of indirect function calls per vertex.
Keith
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./savagedma.c.~1.4.~ 2004-12-15 16:37:19.0 +0100
+++ ./savagedma.c 2004-12-17 21:35:56.0 +0100
@@ -312,8 +312,8 @@
};
void savageFakeVertices (savageContextPtr imesa, drmBufPtr buffer) {
-GLuint vertexStride = imesa-vertex_size; /* stride in dwords */
-GLuint vertexSize = imesa-vertex_size; /* the real vertex size in dwords */
+GLuint vertexStride = imesa-HwVertexSize; /* stride in dwords */
+GLuint vertexSize = imesa-HwVertexSize; /* the real vertex size in dwords */
GLuint nVertices = buffer-used / (vertexStride*4);
u_int32_t *data = (u_int32_t*)buffer-address;
u_int32_t vertexFormat = imesa-DrawPrimitiveCmd SAVAGE_HW_SKIPFLAGS;
--- ./savagecontext.h.~1.11.~ 2004-12-17 16:06:50.0 +0100
+++ ./savagecontext.h 2004-12-18 01:28:44.0 +0100
@@ -84,6 +84,8 @@
typedef void (*savage_line_func)( savageContextPtr,
savageVertex *, savageVertex * );
typedef void (*savage_point_func)( savageContextPtr, savageVertex * );
+typedef void (*savage_emit_vert_func)( u_int32_t *vb, GLuint vertex_size,
+ GLuint start, savageVertexPtr v );
/**
@@ -179,12 +181,14 @@
GLenum render_primitive;
GLuint DrawPrimitiveCmd;
+ GLuint HwVertexSize;
/* Fallback rasterization functions
*/
savage_point_func draw_point;
savage_line_func draw_line;
savage_tri_func draw_tri;
+ savage_emit_vert_func emit_vert;
/* Funny mesa mirrors
*/
--- ./savagetris.c.~1.16.~ 2004-12-17 16:34:52.0 +0100
+++ ./savagetris.c 2004-12-18 16:09:09.0 +0100
@@ -76,36 +76,82 @@
*Emit primitives *
***/
+#if 0
+
#if defined (USE_X86_ASM)
-#define EMIT_VERT( j, vb, vertex_size, start, v ) \
+#define EMIT_VERT( vb, vertex_size, start, v ) \
do { int __tmp; \
vb += start; \
__asm__ __volatile__( rep ; movsl \
- : =%c (j), =D (vb), =S (__tmp) \
- : 0 (vertex_size-start), \
+ : =D (vb), =S (__tmp) \
+ : c (vertex_size-start), \
D ((long)vb), \
S ((long)v-ui[start])); \
} while (0)
#else
-#define EMIT_VERT( j, vb, vertex_size, start, v ) \
+#define EMIT_VERT( vb, vertex_size, start, v ) \
do { \
+ GLuint j; \
for ( j = start ; j vertex_size ; j++ ) \
vb[j] = (v)-ui[j]; \
vb += vertex_size;\
} while (0)
#endif
+#else
+
+#define EMIT_VERT( vb, vertex_size, start, v ) \
+do { \
+ imesa-emit_vert( vb, vertex_size, start, v ); \
+
R300 register values error ?
Hi, Again me for a little error :) In r300_reg.h line 218 if i am not wrong this should be R300_GB_TILE_PIPE_COUNT_RV350 line 219 R300_GB_TILE_PIPE_COUNT_R300 Thus we got : #define R300_GB_TILE_PIPE_COUNT_R300 (01) #define R300_GB_TILE_PIPE_COUNT_RV300 (31) But i think (if r300_demo is right in r300_lib.c init_3d) we should have : #define R300_GB_TILE_PIPE_COUNT_RV350 (01) #define R300_GB_TILE_PIPE_COUNT_R300 (31) best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Post-processing hook for vertex setup code
On Mon, Dec 20, 2004 at 04:39:03PM +0100, Felix Kühling wrote: Hi Keith, I'm attaching my current solution for the Savage driver. I'm going to commit this later today. It doesn't need any modifications of the common TNL code. It is probably not the most efficient solution though, since it requires an indirect function call for each emitted vertex. That said, I havn't noticed any performance regressions which may be because the Savage hardware is quite slow in relation to my CPU (mobile Athlon XP 2000+). Also see my comments below ... Am Sa, den 18.12.2004 schrieb Keith Whitwell um 0:37: Felix Kühling wrote: Am Fr, den 17.12.2004 schrieb Keith Whitwell um 22:59: [snip] Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right? Right. But that would have been broken with t_dd_vbtmp.h too. ;-) No, t_dd_vbtmp.h *does* undo the projection, look around line 534. Ok, sorry. I missed that detail. Though I do have a question about this code: rqdst = 1.0 / qdst; dst-v.u0 *= rqdst; dst-v.v0 *= rqdst; dst-v.w *= rqdst; Shouldn't the last line say: dst-v.w *= qdst; I don't claim to understand the math behind this completely, but that would be the analogue thing to the code around line 277. [ ... your other reply ... ] I can think of the i810 and mga which both have this projective texture issue *and* have the fast path (in i810render.c and mga_render.c respectively). It (used to be?) a worthwhile optimization. I didn't know about the i810 driver. But in the MGA driver the render stage is disabled. AFAICT it has been since the transition to Mesa 4. I have the render stage working with the Mesa 5 code I use with DirectFBGL. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 register values error ?
I changed it to #define R300_GB_TILE_PIPE_COUNT_4(3 1) #define R300_GB_TILE_PIPE_COUNT_2(0 1) which is what it really means - the RV350 setting is also used on R400 cards which have the same number of pipes as RV350. best Vladimir Dergachev On Mon, 20 Dec 2004, Jerome Glisse wrote: Hi, Again me for a little error :) In r300_reg.h line 218 if i am not wrong this should be R300_GB_TILE_PIPE_COUNT_RV350 line 219 R300_GB_TILE_PIPE_COUNT_R300 Thus we got : #define R300_GB_TILE_PIPE_COUNT_R300 (01) #define R300_GB_TILE_PIPE_COUNT_RV300 (31) But i think (if r300_demo is right in r300_lib.c init_3d) we should have : #define R300_GB_TILE_PIPE_COUNT_RV350 (01) #define R300_GB_TILE_PIPE_COUNT_R300 (31) best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 hooks for flat color
Hi Jerome, I cleaned up r300_demo a little bit and I believe is ready to implement flat color in r300_driver. Would you know where should I hook it up ? The _render file looks empty.. It'd be nice to do it with minimal modifications to existing code (so I can add a file with flat drawing functions). best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2092] _radeon_texrect_stage looks broken
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=2092 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 10:06 --- btw., while experimenting with texrect I noticed some missing debugstrings in radeon_tcl.c Index: Mesa/src/mesa/drivers/dri/radeon/radeon_tcl.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_tcl.c,v retrieving revision 1.10 diff -u -r1.10 radeon_tcl.c --- Mesa/src/mesa/drivers/dri/radeon/radeon_tcl.c +++ Mesa/src/mesa/drivers/dri/radeon/radeon_tcl.c @@ -491,7 +491,10 @@ Texgen unit 0, Texgen unit 1, Texgen unit 2, - User disable + User disable, + texture rectangle unit 0, + texture rectangle unit 1, + texture rectangle unit 2 }; -- 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 email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 hooks for flat color
I am far too feel confortable with mesa structure. I will try to take a look at it in the next hours. If i understand anything i will tell you :) Anyway i think the key is in line 104 (r300_render.c) mga_render_tab_verts This table seems to hold the functions to call for each specific premitive. By the way did you update your cleaned version of r300_demo on the CVS ? I am in a such process too, cleaning my own copy of r300_demo after experimenting with it i added code everywhere and now i hardly find where are my change. Anyway i will add to the CVS my own cleaned version of r300_demo (with a different name) as soon as i get it working back. best, Jerome Glisse Vladimir Dergachev wrote: Hi Jerome, I cleaned up r300_demo a little bit and I believe is ready to implement flat color in r300_driver. Would you know where should I hook it up ? The _render file looks empty.. It'd be nice to do it with minimal modifications to existing code (so I can add a file with flat drawing functions). best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 hooks for flat color
On Mon, 20 Dec 2004, Jerome Glisse wrote: I am far too feel confortable with mesa structure. I will try to take a look at it in the next hours. If i understand anything i will tell you :) Anyway i think the key is in line 104 (r300_render.c) mga_render_tab_verts This table seems to hold the functions to call for each specific premitive. Thank you ! By the way did you update your cleaned version of r300_demo on the CVS ? Yes, absolutely - I commit often so it is easy to back out when anything breaks. I am in a such process too, cleaning my own copy of r300_demo after experimenting with it i added code everywhere and now i hardly find where are my change. Anyway Try cvs -z3 diff -u This will produce a diff against the version you started from. best Vladimir Dergachev i will add to the CVS my own cleaned version of r300_demo (with a different name) as soon as i get it working back. best, Jerome Glisse Vladimir Dergachev wrote: Hi Jerome, I cleaned up r300_demo a little bit and I believe is ready to implement flat color in r300_driver. Would you know where should I hook it up ? The _render file looks empty.. It'd be nice to do it with minimal modifications to existing code (so I can add a file with flat drawing functions). best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2119] New: via: insufficient security checks on DMA init IOCTL
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=2119 Summary: via: insufficient security checks on DMA init IOCTL Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P1 Component: DRM modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The DRM_IOCTL_VIA_DMA_INIT can be called as a normal user. This is of course easy to change, but Mesa 3D uses it to check whether AGP DMA has been initialized and if not, uses the PCI path. Either a separate user-callable IOCTL that checks wether AGP DMA has been initialized is needed or a check for caller privileges is needed for VIA_INIT_DMA and VIA_CLEANUP_DMA functions, whereas VIA_DMA_INITIALIZED should be allowed as normal user. Suggestions are appreciated. /Thomas -- 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 email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2118] via: Invalid DMA header command.
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=2118 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 15:05 --- This is caused by the verifier exiting to state_command after a single HC_COMMAND_FIRE, followed by a 0x00 command. Seems like a HC_HEADER2 should be inserted inbetween. The command regulator actually accepts this, whereas the PCI path (taken from the original via dri driver) does not, and hangs the machine. I suggest fixing up the Mesa driver not to issue this command sequence. /Thomas -- 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 email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 2.6.10-rc3 1/4] agpgart: allow multiple backends to be initialized
This version removes the agp_find_bridge function pointer as Christoph
requested.
drivers/char/agp/agp.h |3 +
drivers/char/agp/backend.c | 109
drivers/char/agp/frontend.c | 30 ++--
drivers/char/agp/generic.c | 73 +
include/linux/agp_backend.h | 31 +++-
5 files changed, 143 insertions(+), 103 deletions(-)
# This is a BitKeeper generated diff -Nru style patch.
#
# Allow multiple backends to be initialized
#
diff -Nru a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
--- a/drivers/char/agp/agp.h2004-12-20 15:45:16 -08:00
+++ b/drivers/char/agp/agp.h2004-12-20 15:45:16 -08:00
@@ -1,5 +1,6 @@
/*
* AGPGART
+ * Copyright (C) 2004 Silicon Graphics, Inc.
* Copyright (C) 2002-2004 Dave Jones
* Copyright (C) 1999 Jeff Hartmann
* Copyright (C) 1999 Precision Insight, Inc.
@@ -139,6 +140,7 @@
int capndx;
char major_version;
char minor_version;
+ struct list_head list;
};
#define OUTREG64(mmap, addr, val) __raw_writeq((val), (mmap)+(addr))
@@ -271,6 +273,7 @@
void global_cache_flush(void);
void get_agp_version(struct agp_bridge_data *bridge);
unsigned long agp_generic_mask_memory(unsigned long addr, int type);
+struct agp_bridge_data *agp_generic_find_bridge(struct pci_dev *pdev);
/* generic routines for agp=3 */
int agp3_generic_fetch_size(void);
diff -Nru a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
--- a/drivers/char/agp/backend.c2004-12-20 15:45:16 -08:00
+++ b/drivers/char/agp/backend.c2004-12-20 15:45:16 -08:00
@@ -1,5 +1,6 @@
/*
* AGPGART driver backend routines.
+ * Copyright (C) 2004 Silicon Graphics, Inc.
* Copyright (C) 2002-2003 Dave Jones.
* Copyright (C) 1999 Jeff Hartmann.
* Copyright (C) 1999 Precision Insight, Inc.
@@ -42,34 +43,35 @@
* fix some real stupidity. It's only by chance we can bump
* past 0.99 at all due to some boolean logic error. */
#define AGPGART_VERSION_MAJOR 0
-#define AGPGART_VERSION_MINOR 100
+#define AGPGART_VERSION_MINOR 101
static struct agp_version agp_current_version =
{
.major = AGPGART_VERSION_MAJOR,
.minor = AGPGART_VERSION_MINOR,
};
-static int agp_count=0;
-
-struct agp_bridge_data agp_bridge_dummy = { .type = NOT_SUPPORTED };
-struct agp_bridge_data *agp_bridge = agp_bridge_dummy;
+struct agp_bridge_data *agp_bridge;
+LIST_HEAD(agp_bridges);
EXPORT_SYMBOL(agp_bridge);
-
+EXPORT_SYMBOL(agp_bridges);
/**
- * agp_backend_acquire - attempt to acquire the agp backend.
+ * agp_backend_acquire - attempt to acquire an agp backend.
*
- * returns -EBUSY if agp is in use,
- * returns 0 if the caller owns the agp backend
*/
-int agp_backend_acquire(void)
+struct agp_bridge_data *agp_backend_acquire(struct pci_dev *pdev)
{
- if (agp_bridge-type == NOT_SUPPORTED)
- return -EINVAL;
- if (atomic_read(agp_bridge-agp_in_use))
- return -EBUSY;
- atomic_inc(agp_bridge-agp_in_use);
- return 0;
+ struct agp_bridge_data *bridge;
+
+ bridge = agp_generic_find_bridge(pdev);
+
+ if (!bridge)
+ return NULL;
+
+ if (atomic_read(bridge-agp_in_use))
+ return NULL;
+ atomic_inc(bridge-agp_in_use);
+ return bridge;
}
EXPORT_SYMBOL(agp_backend_acquire);
@@ -82,10 +84,11 @@
*
* (Ensure that all memory it bound is unbound.)
*/
-void agp_backend_release(void)
+void agp_backend_release(struct agp_bridge_data *bridge)
{
- if (agp_bridge-type != NOT_SUPPORTED)
- atomic_dec(agp_bridge-agp_in_use);
+
+ if (bridge)
+ atomic_dec(bridge-agp_in_use);
}
EXPORT_SYMBOL(agp_backend_release);
@@ -121,7 +124,6 @@
(maxes_table[index].agp - maxes_table[index - 1].agp)) /
(maxes_table[index].mem - maxes_table[index - 1].mem);
- printk(KERN_INFO PFX Maximum main memory to use for agp memory:
%ldM\n, result);
result = result (20 - PAGE_SHIFT);
return result;
}
@@ -178,9 +180,6 @@
goto err_out;
}
- printk(KERN_INFO PFX AGP aperture is %dM @ 0x%lx\n,
- size_value, bridge-gart_bus_addr);
-
return 0;
err_out:
@@ -225,16 +224,31 @@
agp_copy_info
};
-/* XXX Kludge alert: agpgart isn't ready for multiple bridges yet */
+/* When we remove the global variable agp_bridge from all drivers
+ * then agp_alloc_bridge and agp_generic_find_bridge need to be updated
+ */
+
struct agp_bridge_data *agp_alloc_bridge(void)
{
- return agp_bridge;
+ struct agp_bridge_data *bridge = kmalloc(sizeof(*bridge), GFP_KERNEL);
+
+ if (!bridge)
+ return NULL;
+
+ if (list_empty(agp_bridges))
+ agp_bridge = bridge;
+
+ return bridge;
}
EXPORT_SYMBOL(agp_alloc_bridge);
void agp_put_bridge(struct agp_bridge_data *bridge)
{
+
Doom3 Blood over everything, Depth problem?
http://train.is-a-geek.org/%7Echeako/DebthClear.tga The blood that should be one the floor is on the gun, doors, walls(around corners). Also some other things like logos(sings) ect show through. This could be a diffrent bug, but some times rounded walls seam to have a translucent property to them. __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
GLX_MESA_allocate_memory test code?
does anyone have a test for this? my initial attempts are going wrong and I just thought someone might have tested this once .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
