Re: [Dri-devel] Radeon: DMA buffer allocation leak
On Mon, 2 Dec 2002 00:59:34 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I reported a DMA buffer allocation problem earlier today with glean. It
terminated with Error: Could not get dma buffer ... exiting. I looked
into it a bit more now. I made a glean run with RADEON_DEBUG_DMA and
wrote a small TCL script to analyse the output. It revealed a leak of
DMA buffers. It might be a bug with my script, but I'm pretty sure it's
ok. It is obvious that towards the end of the log only a subset of the
available DMA buffers is used.
[snip]
I tracked it down to radeonDestroyContext. There radeonReleaseDmaRegion
is called but after that the CmdBuf is never flushed. So when the
context is destroyed any record of the last DMA buffer still being
allocated is lost in the client. As glean destroys and recreates
contexts quite often, all DMA buffers were lost like this. I think we
introduced this problem when we moved the RADEON_FIRE_VERTICES further
up in radeonDestroyContext. Before that RADEON_FIRE_VERTICES implicitly
flushed the CmdBuf.
Here is a patch that fixes the problem. I hope is doesn't introduce any
new ones ;-)
--- radeon_context.c.~1.27.~2002-11-26 02:57:38.0 +0100
+++ radeon_context.c2002-12-02 09:15:29.0 +0100
@@ -571,8 +571,10 @@
radeonDestroySwtcl( rmesa-glCtx );
radeonReleaseArrays( rmesa-glCtx, ~0 );
- if (rmesa-dma.current.buf)
+ if (rmesa-dma.current.buf) {
radeonReleaseDmaRegion( rmesa, rmesa-dma.current, __FUNCTION__ );
+radeonFlushCmdBuf( rmesa, __FUNCTION__ );
+ }
if (!rmesa-TclFallback RADEON_TCL_FALLBACK_TCL_DISABLE)
if (!getenv(RADEON_NO_VTXFMT))
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon: DMA buffer allocation leak
Am Montag, 2. Dezember 2002 09:30 schrieb Felix Kühling:
On Mon, 2 Dec 2002 00:59:34 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I reported a DMA buffer allocation problem earlier today with glean. It
terminated with Error: Could not get dma buffer ... exiting. I looked
into it a bit more now. I made a glean run with RADEON_DEBUG_DMA and
wrote a small TCL script to analyse the output. It revealed a leak of
DMA buffers. It might be a bug with my script, but I'm pretty sure it's
ok. It is obvious that towards the end of the log only a subset of the
available DMA buffers is used.
[snip]
I tracked it down to radeonDestroyContext. There radeonReleaseDmaRegion
is called but after that the CmdBuf is never flushed. So when the
context is destroyed any record of the last DMA buffer still being
allocated is lost in the client. As glean destroys and recreates
contexts quite often, all DMA buffers were lost like this. I think we
introduced this problem when we moved the RADEON_FIRE_VERTICES further
up in radeonDestroyContext. Before that RADEON_FIRE_VERTICES implicitly
flushed the CmdBuf.
Here is a patch that fixes the problem. I hope is doesn't introduce any
new ones ;-)
--- radeon_context.c.~1.27.~2002-11-26 02:57:38.0 +0100
+++ radeon_context.c2002-12-02 09:15:29.0 +0100
@@ -571,8 +571,10 @@
radeonDestroySwtcl( rmesa-glCtx );
radeonReleaseArrays( rmesa-glCtx, ~0 );
- if (rmesa-dma.current.buf)
+ if (rmesa-dma.current.buf) {
radeonReleaseDmaRegion( rmesa, rmesa-dma.current, __FUNCTION__
); +radeonFlushCmdBuf( rmesa, __FUNCTION__ );
+ }
if (!rmesa-TclFallback RADEON_TCL_FALLBACK_TCL_DISABLE)
if (!getenv(RADEON_NO_VTXFMT))
r200?
I'll try it by hand anyway ;-)
Thanks,
Dieter
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon: DMA buffer allocation leak
Felix Kühling wrote: On Mon, 2 Dec 2002 00:59:34 +0100 Felix Kühling [EMAIL PROTECTED] wrote: Hi, I reported a DMA buffer allocation problem earlier today with glean. It terminated with Error: Could not get dma buffer ... exiting. I looked into it a bit more now. I made a glean run with RADEON_DEBUG_DMA and wrote a small TCL script to analyse the output. It revealed a leak of DMA buffers. It might be a bug with my script, but I'm pretty sure it's ok. It is obvious that towards the end of the log only a subset of the available DMA buffers is used. [snip] I tracked it down to radeonDestroyContext. There radeonReleaseDmaRegion is called but after that the CmdBuf is never flushed. So when the context is destroyed any record of the last DMA buffer still being allocated is lost in the client. As glean destroys and recreates contexts quite often, all DMA buffers were lost like this. I think we introduced this problem when we moved the RADEON_FIRE_VERTICES further up in radeonDestroyContext. Before that RADEON_FIRE_VERTICES implicitly flushed the CmdBuf. Here is a patch that fixes the problem. I hope is doesn't introduce any new ones ;-) I've committed this... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon TCL global ambient problem solved
Felix Kühling wrote: Hi, my digging is starting to pay off ;) I had reported that weird problem, that the global ambient light is not correct using hardware TCL if I specify anything other than 1.0 as alpha component. Now I found out that the trigger for this problem is actually to specify the default of (0.2, 0.2, 0.2, 1.0). In that case Mesa is clever enough to not call the driver's LightModelfv functions as the value doesn't change. So the real error is that the global ambient is not set to the correct default value in the TCL state after turning on the ambient light. I fixed it by adding a call to update_global_ambient in radeonColorMaterial. Here is the one-line patch for completeness ;) --- radeon_state.c.~1.24.~ 2002-11-26 02:57:38.0 +0100 +++ radeon_state.c 2002-12-01 02:43:42.0 +0100 @@ -887,6 +887,7 @@ for (p = 0 ; p MAX_LIGHTS; p++) update_light_colors( ctx, p ); +update_global_ambient( ctx ); } } Committed this too. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
Felix Kühling wrote: Hi, I made two small modifications to the radeon driver to make OpenGL look much nicer with 16bpp. The first thing is to enable dithering, the second is to use 32bpp textures even in 16bpp mode, if the application requests them. A patch is attached. I've turned it on unilaterally, for 16 and 32 bit. This is consistent with the enable/disable code in radeon_state.c Maybe the texture color depth should be handled more intelligently in 16bpp mode, based on the amount of graphics memory or controlled by an environment variable? I think I'd want to see this sort of thing put in place, rather than the patch you posted which would increase the amount of texture memory required for some apps without giving the user a chance to counter that. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Amatör türk kýzlarý yuiwy
Title: dri-devel
Türk amatör
yapým filmlerden görüntüler ve TÜRK KIZLARI
DUDAKLAR.com
spkwc
áË ë^¨¥Ë)¢{(ç[É8bAzEÊÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
Re: [Dri-devel] radeonFlushVertices restores the neutral vtxfmt wrapper
Felix Kühling wrote: Hi, while I was trying to understand the vtxfmt mesa code and poking around with gdb I noticed that the neutral vtxfmt wrapper gets restored quite often. I tracked it to radeonFlushVertices where _mesa_install_exec_vtxfmt( ctx, rmesa-vb.vtxfmt ) is called if the FLUSH_UPDATE_CURRENT flag is set. _mesa_install_exec_vtxfmt in turn sets ctx-TnlModule.Current to the new exec vertex format and calls _mesa_restore_exec_vtxfmt( ctx ) which restores the neutral wrapper. Is this really what was intended here? The only place I could find where the FLUSH_UPDATE_CURRENT flag is set in the radeon driver is in radeon_vtxfmt_c.c and there the Exec dispatch table is modified directly. So there should be no need for reinstalling the vertex format. It is necessary to do that there. I can't bring an example off the top of my head, but feel free to remove the call play with the mesa demos. Something should break before too long... I guess I should have left a comment there to explain/remind myself why. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Recent broken locking in DRM code..
On Mon, 2002-12-02 at 03:00, Linus Torvalds wrote:
On 1 Dec 2002, Michel Dänzer wrote:
Does that also apply to kmalloc()/kfree(), or are they safe?
kfree() (or free_pages() or others of that type) is always safe.
kmalloc(x, GFP_ATOMIC) works, but has problems (ie being over-eager about
using it can easily result in a system that just dies from being out of
memory and not being able to do the required memory balancing and
swap-out to replenish it).
Luckily, we only need kfree() in the interrupt here, kmalloc() is done
in the ioctl. Thanks to you and Ben for explaining this.
The attached patch looked mostly ok, except this part:
- sema_init( dev-vbl_sem, 0 );
+ spin_lock_irqsave( dev-vbl_lock, flags );
..
should almost certainly have been a
spin_lock_init(dev-vbl_lock);
instead of locking and unlocking an uninitialized variable (from what I
could tell from just reading the diff).
Fixed, thanks. I'll commit the attached updated patch soon unless
someone sees another mistake. It works for me. Now I hope someone will
fill in the missing pieces and/or do the cleanup necessary for BSD.
Btw, from a testing standpoint it's then also worthwhile compiling with
CONFIG_DEBUG_SPINLOCK, which will verify that spinlocks are initialized
etc.
I hope to get around to that some time.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h,v
retrieving revision 1.53
diff -p -u -r1.53 drmP.h
--- programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h 30 Nov 2002 14:24:06 - 1.53
+++ programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h 2 Dec 2002 11:43:05 -
@@ -591,8 +600,7 @@ typedef struct drm_device {
#if __HAVE_VBL_IRQ
wait_queue_head_t vbl_queue;
atomic_t vbl_received;
- struct tq_struct vbl_tq;
- struct semaphore vbl_sem;
+ spinlock_tvbl_lock;
drm_vbl_sig_t vbl_sigs;
#endif
cycles_t ctx_start;
@@ -834,7 +845,7 @@ extern void DRM(driver_irq_unin
extern int DRM(wait_vblank)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int DRM(vblank_wait)(drm_device_t *dev, unsigned int *vbl_seq);
-extern void DRM(vbl_immediate_bh)( void *arg );
+extern void DRM(vbl_send_signals)( drm_device_t *dev );
#endif
#if __HAVE_DMA_IRQ_BH
extern void DRM(dma_immediate_bh)( void *dev );
Index: programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h,v
retrieving revision 1.8
diff -p -u -r1.8 drm_dma.h
--- programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h 30 Nov 2002 14:24:07 - 1.8
+++ programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h 2 Dec 2002 11:43:11 -
@@ -509,6 +509,9 @@ int DRM(dma_get_buffers)(drm_device_t *d
int DRM(irq_install)( drm_device_t *dev, int irq )
{
int ret;
+#if __HAVE_VBL_IRQ
+ unsigned long flags;
+#endif
if ( !irq )
return -EINVAL;
@@ -541,16 +544,9 @@ int DRM(irq_install)( drm_device_t *dev,
#if __HAVE_VBL_IRQ
init_waitqueue_head(dev-vbl_queue);
- sema_init( dev-vbl_sem, 0 );
+ spin_lock_init( dev-vbl_lock );
INIT_LIST_HEAD( dev-vbl_sigs.head );
-
- up( dev-vbl_sem );
-
- INIT_LIST_HEAD( dev-vbl_tq.list );
- dev-vbl_tq.sync = 0;
- dev-vbl_tq.routine = DRM(vbl_immediate_bh);
- dev-vbl_tq.data = dev;
#endif
/* Before installing handler */
@@ -642,6 +638,7 @@ int DRM(wait_vblank)( DRM_IOCTL_ARGS )
flags = vblwait.request.type _DRM_VBLANK_FLAGS_MASK;
if ( flags _DRM_VBLANK_SIGNAL ) {
+ unsigned long flags;
drm_vbl_sig_t *vbl_sig = DRM_MALLOC( sizeof( drm_vbl_sig_t ) );
if ( !vbl_sig )
@@ -656,11 +653,11 @@ int DRM(wait_vblank)( DRM_IOCTL_ARGS )
vblwait.reply.sequence = atomic_read( dev-vbl_received );
/* Hook signal entry into list */
- down( dev-vbl_sem );
+ spin_lock_irqsave( dev-vbl_lock, flags );
list_add_tail( (struct list_head *) vbl_sig, dev-vbl_sigs.head );
- up( dev-vbl_sem );
+ spin_unlock_irqrestore( dev-vbl_lock, flags );
} else {
ret = DRM(vblank_wait)( dev, vblwait.request.sequence );
@@ -675,14 +672,14 @@ int DRM(wait_vblank)( DRM_IOCTL_ARGS )
return ret;
}
-void DRM(vbl_immediate_bh)( void *arg )
+void DRM(vbl_send_signals)( drm_device_t *dev )
{
- drm_device_t *dev = (drm_device_t *) arg;
struct list_head *entry, *tmp;
drm_vbl_sig_t *vbl_sig;
unsigned int vbl_seq = atomic_read( dev-vbl_received );
+ unsigned long flags;
- down( dev-vbl_sem
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Mon, 02 Dec 2002 10:47:54 + Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: Hi, I made two small modifications to the radeon driver to make OpenGL look much nicer with 16bpp. The first thing is to enable dithering, the second is to use 32bpp textures even in 16bpp mode, if the application requests them. A patch is attached. I've turned it on unilaterally, for 16 and 32 bit. This is consistent with the enable/disable code in radeon_state.c Maybe the texture color depth should be handled more intelligently in 16bpp mode, based on the amount of graphics memory or controlled by an environment variable? I think I'd want to see this sort of thing put in place, rather than the patch you posted which would increase the amount of texture memory required for some apps without giving the user a chance to counter that. Exactly. I figured that there was probably a good reason to use 16bit textures. And I think it also affects the frame rate due to higher memory bandwidth demands. So if we agree on this, I would make this controlled by an environment variable. What should be the default setting? Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Fri, Nov 29, 2002 at 11:15:19AM +, José Fonseca wrote: The later is the approach taken e.g., in chromium http://chromium.sourceforge.net , but actually I don't know if for any application besides scientific visualization a pipeline handles so many primitives at a time. For applications such as games, state changes (like texture changes) seem to happen too often for that. The problem with that approach is that you have to do one of a) sort primitives in screen space and assign non-overlapping primitives to the different pipelines; b) keep multiple buffers and blend them together at some point. If you do a), you can have parallelism after the transformation stage or have a synchronization point in the middle of the pipelines. b) is horribly slow for a pipeline running completly in software. Stage parallelization is in this case a much better approach. Problem is the final stages of the pipeline are much more CPU intensive than the initial stages (think vertex processing vs. fragment processing), so you can't split pipeline stages equally across threads. -- Marcelo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100/R200 fix for glSecondaryColor3*EXT when secondary / specular color not used
On Thu, Nov 28, 2002 at 11:29:31PM +0100, Dieter Nützel wrote: Am Mittwoch, 27. November 2002 08:56 schrieb Ian Romanick: Also attached is a test program that could be bundled w/Mesa. :) Works for me on R200, dual Athlon MP. Only a little white window for some tenths of a second? Perfect. All it does is create a context, set state that doesn't use secondary / specular color, and try to set secondary color. If it works, the window will open and close. If it doesn't work, the window will open and the app will segfault. I will commit the fix today. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: texmem-0-0-1)
On Thu, Nov 28, 2002 at 12:57:52PM +, Keith Whitwell wrote:
Ian Romanick wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository: xc/xc/lib/GL/mesa/src/drv/r128/
Changes by: idr@sc8-pr-cvs1.02/11/27 12:47:44
Log message:
Initial pass at adding texmem support to Rage128 driver. These
changes have not yet been tested as I don't have access to Rage128
hardware. I will post to dri-devel to beg for help.
I fixed one trivial problem with turning on extensions (is that *strictly* a
texmem change, Ian?)
Now I've got this:
Program received signal SIGSEGV, Segmentation fault.
0x4047258c in driInitTextureObjects (ctx=0x8056b18, swapped=0x8054e00,
targets=3) at texmem.c:802
802 move_to_tail( swapped, (driTextureObject *) texObj-DriverData );
(gdb) print swapped
$1 = (driTextureObject *) 0x8054e00
(gdb) print *swapped
$2 = {next = 0x8054e00, prev = 0x8054e00, heap = 0x0, tObj = 0x0,
memBlock = 0x0, bound = 0, totalSize = 0, dirty_images = {0, 0, 0, 0, 0, 0}}
(gdb) print texObj-DriverData
$3 = (void *) 0x0
I seem to recall having a similar issue when I added texmem support to the
MGA driver. There was some subtle difference in the handling of the
DriverData pointer between the pre-radeon drivers and the post-radeon
drivers. This is at the top of my queue today...
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote: On Fri, 29 Nov 2002 11:15:19 + José Fonseca [EMAIL PROTECTED] wrote: On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote: First some high level considerations. Having each pipeline stage in a separate thread would lead to a large number of threads (e.g. 9 in the case of the radeon driver). Most of the pipeline stages take rather short time so that the extra overhead of multi threading and synchronization could have a significant impact. Alternatively one could use a fixed number N of threads and schedule pipeline stages on them, the main thread and N-1 free threads. If a free thread is available the next pipeline stage would be executed on that thread and the OpenGL client could continue on the main thread without waiting for all pipeline stages to complete. Note that on a non-SMP system there would be only the main thread which is equivalent to how the pipeline is currently executed. I think that one thing that must be thought is whether the parallelism should be in the pipeline stages or in the pipeline data, i.e., if we I am not sure I understand the difference. The idea of a pipeline is that you split the tasks performed on data into several stages. Mesa does this part already. Then while one package is in stage 1 another one can be processed in stage 2 at the same time. So I think I have parallelism both in pipeline data and the stages. The problem is two-fold in this case. First, most of the time not all of the stages are executed (i.e., the software rasterizer case is rarely executed). Second, most of the stages are very short. You'll spend most of your execution time synchronizing between the stages. I seem to recall the Carmack had a .plan update about that when he was adding SMP support to Quake3. I'll see if I can find it. Most research in parallelizing code points to doing whatever is possible to minimize synchronization costs. You might search through previous years SIGGRAPH papers to see what other people have done in this area. It's not a new field. I know that there are patents in this area (sigh) that go back at least 5 or 10 years. All assumptions have to be very well verified against all existing Mesa drivers, otherwise a discrete hack can cause havoc... All the hardware specific stages are drawing stages. So only one of them will be executed at a time. I don't see any problem here. One tricky part could be to find out, how much of the context actually has to be copied. Obviously, all data that is modified by the pipeline stages needs to be copied. Everything that is read only can be shared by all context copies. What about TCL stages? I think one problem that you'll run into is that, as more and more of the OpenGL pipeline gets moved into hardware, you'll see less and less benefit in doing this. :( What might be worth looking into is using left over CPU time to optimize data that is being sent to the card. That is, if the card is the rendering bottleneck, use some CPU cycles to optimize triangle strips that are being submitted, optimize out redundant state changes from the command stream, etc. The trick is in deciding when to enable the optimizer pass. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parallelizing MESA's pipeline?
On Fri, Nov 29, 2002 at 01:20:45PM +, José Fonseca wrote: On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote: On Fri, 29 Nov 2002 11:15:19 + José Fonseca [EMAIL PROTECTED] wrote: I think that one thing that must be thought is whether the parallelism should be in the pipeline stages or in the pipeline data, i.e., if we I am not sure I understand the difference. The idea of a pipeline is that you split the tasks performed on data into several stages. Mesa does this part already. Then while one package is in stage 1 another one can be processed in stage 2 at the same time. So I think I have parallelism both in pipeline data and the stages. Let'me ilustrate with an example. Image you have 1000 polygons to process (i.e., transform, clip, build vertex buffers, and render). If you have a SMP computer with 4 processors you can make use of parallelism in at least two ways: a) Have a processor do the transform of the 1000 polygons, another do the clipping, ... etc. b) Have a processor do the transform+clipping+... of 250 polygons, have another do the same for another 250 polygons, ... etc. One thing I forgot to mention in my other message is that the b option will make MUCH better use of the CPU caches. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA error: mga_get_buffer_ioctl: flush ret=-16
Serge Gavrilov wrote: On Mon, Dec 02, 2002 at 03:08:51AM +0300, Serge Gavrilov wrote: On Mon, Dec 02, 2002 at 02:58:17AM +0300, Serge Gavrilov wrote: Without framebuffer support it looks like that quake2 works fine. Sorry, I just detected this error also with 2.4.20 without framebuffer support and patched 2.4.19 (also withot frambuffer support). The important detail: I detect this on the new computer with Abit KX7-333 motherboard and Athlon XP 2000 processor. Hi I am also using the framebuffer for tv-out functionality with my G450 and I have not seen any problems since I made the patch. My system is: AMD Duron 1.2GHz VT82C686 [Apollo Super South] VT8363/8365 [KT133/KM133] Cheers Johnny --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Split AGP GART device lists.
[taking this to the lists, to keep anyone who cares about this in the loop] This conversation evolved out of my split-agpgart-device-list patch. Linus' proposal is to take this a step further and split each of the chipsets into a seperate module. I'm about to tackle this, but in case there's some hidden gotchas that myself and Linus have overlooked, I figured I'd give a 'heads up'. Any comments? Dave. On Mon, Dec 02, 2002 at 08:55:24AM -0800, Linus Torvalds wrote: I'm worrying about breaking existing behaviour. X loads /dev/agpgart, which pulls in agpgart.o, but what pulls in via.o, amd.o etc.. ? Done right, the regular PCI driver detection should load the thing automatically without X needing to do anything at all. With the AGP drivers showing up with the PCI entries they can drive, all the normal auto-loading should just work _without_ having any special cases. I really think this is worth doing _right_, without stupid (and incorrect) module dependencies. Even if it breaks something, it's worth doing: people who compile their own kernels can just compile the AGP driver statically, the way all sane people - me - do, and people who don't compile their own kernels obviously get them from distributions that can trivially make modprobe do the right thing. We get eth0 behaviour right without having to have some eth0 driver that knows about all the devices that might be networking devices. Similarly, we should get agp behaviour right without having to have some silly central thing. -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk and glaxium
On Mon, 2002-12-02 at 06:00, Bret Towe wrote: On Sun, 2002-12-01 at 20:23, Bret Towe wrote: On Sun, 2002-12-01 at 15:55, Michel Dänzer wrote: On Fre, 2002-11-29 at 18:37, Bret Towe wrote: last night i installed glaxium (0.5) for the first time and was playing it runs great however when i move the window it freezes x within a minute sometimes even less but as long as i dont move the window it plays fine Do you keep moving the window until it locks up, or do you move the window and then let it be, and it will lock up after a while? i move it once to the location that i wanted it then start to play (wait 3-15s) then freeze Also, can you log in remotely and see if killing glaxium restores normal operation? tried that looked like it had already died It as in glaxium or the machine? If the former, can you try fuser -k /dev/dri/card0 as normal user? That should kill any leftover processes using the DRM while keeping the X server alive. Although the information below kind of implies a 'real' lockup, not a 'soft' one. this is a radeon 7500 (built by ati card) pageflipping is enabled I don't expect this to make a difference, but can you still try without? will do will let know soon ok i disabled it and i forgot to move the window this time and it still froze So it doesn't seem to be related to moving the window after all. but i ran glaxium from a ssh shell so i could run gdb on it but glaxium didnt have debug symbols but however i did get an error radeonWaitIrq: drmRadeonIrqWait: -16 it appeared 2-3s after x froze Should be pretty much exactly 3 seconds. :) and after reading the thread that Linus started im wondering if this is related Hardly, this is just the current most prominent symptom of a lockup, as the chip obviously no longer generates interrupts when it's locked up. You can try RADEON_NO_IRQS=1 RADEON_NO_USLEEPS=1 for different symptoms. and this might make since due to the fact im using a joystick that is usb but i dont know if its related but the problem usally accors when i move the ship around really fast and that would make the joystick send more stuff at that time but this is just a guess Does playing with the keyboard make a difference? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Conclusions from the Parallelizing MESA's pipeline thread
Hello, First of all, thanks for all the comments I received in this thread. During the last few days I was also inspired to start more systematic reading of the MESA and Radeon driver source codes. In these 5 days I learned more than in 5 months before! As to the subject, there are three main conclusions I draw from this thread: - rendering parallelization has been done before with different approaches - implementing the parallel pipeline I had in mind would be a lot of work - with TCL hardware there would be little or no benefit Furthermore, the majority of DRI users have no SMP system and only SMP systems would benefit from a multi-threaded pipeline. And people who do use high-end hardware most likely have TCL hardware as well (or can afford it ;-) With all that in mind I think my enthusiasm would be better spent otherwise, especially considering that I have TCL hardware and no SMP system ;-) There are other projects within DRI which are interesting, too. I'm thinking of indirect accellerated rendering which was discussed previously a couple of times. For now there are a few bugs left in the Radeon driver to fix ... Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly dri-devel meeting reminder
This is just a friendly reminder that the weeking dri-devel IRC meeting will be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or 4:00PM EST or 1:00PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk and glaxium
On Mon, 2002-12-02 at 07:14, Michel Dänzer wrote: On Mon, 2002-12-02 at 06:00, Bret Towe wrote: On Sun, 2002-12-01 at 20:23, Bret Towe wrote: On Sun, 2002-12-01 at 15:55, Michel Dänzer wrote: On Fre, 2002-11-29 at 18:37, Bret Towe wrote: last night i installed glaxium (0.5) for the first time and was playing it runs great however when i move the window it freezes x within a minute sometimes even less but as long as i dont move the window it plays fine Do you keep moving the window until it locks up, or do you move the window and then let it be, and it will lock up after a while? i move it once to the location that i wanted it then start to play (wait 3-15s) then freeze Also, can you log in remotely and see if killing glaxium restores normal operation? tried that looked like it had already died It as in glaxium or the machine? If the former, can you try glaxium died i tried to recompile it with debuging symbols but no luck ill have to try again later did somehow get sound in glaxium now tho... go fig fuser -k /dev/dri/card0 i did try this with glaxium since it stays open now with sound continuing to play in background it freezes the server fully even the mouse wont move after that command as normal user? That should kill any leftover processes using the DRM while keeping the X server alive. Although the information below kind of implies a 'real' lockup, not a 'soft' one. this is a radeon 7500 (built by ati card) pageflipping is enabled I don't expect this to make a difference, but can you still try without? will do will let know soon ok i disabled it and i forgot to move the window this time and it still froze So it doesn't seem to be related to moving the window after all. seems not but i ran glaxium from a ssh shell so i could run gdb on it but glaxium didnt have debug symbols but however i did get an error radeonWaitIrq: drmRadeonIrqWait: -16 it appeared 2-3s after x froze Should be pretty much exactly 3 seconds. :) and after reading the thread that Linus started im wondering if this is related Hardly, this is just the current most prominent symptom of a lockup, as the chip obviously no longer generates interrupts when it's locked up. You can try RADEON_NO_IRQS=1 RADEON_NO_USLEEPS=1 for different symptoms. tried that didnt seem to make any diff and this might make since due to the fact im using a joystick that is usb but i dont know if its related but the problem usally accors when i move the ship around really fast and that would make the joystick send more stuff at that time but this is just a guess Does playing with the keyboard make a difference? doesnt seem to had same effects it would be nice right now if someone else with a 7500 try this out and see if get the same stuff cause this mobo isnt stable its starting to fail its possable it doesnt like somethin this game does but this would be a first for it usally it just doesnt like compiling (over heats or some damned thing) and what would be best way to get a backtrace? get glaxium with debugging symbols? or should i just run gdb on x? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk and glaxium
On Mon, 2002-12-02 at 22:04, Bret Towe wrote: On Mon, 2002-12-02 at 07:14, Michel Dänzer wrote: On Mon, 2002-12-02 at 06:00, Bret Towe wrote: but i ran glaxium from a ssh shell so i could run gdb on it but glaxium didnt have debug symbols but however i did get an error radeonWaitIrq: drmRadeonIrqWait: -16 it appeared 2-3s after x froze Should be pretty much exactly 3 seconds. :) and after reading the thread that Linus started im wondering if this is related Hardly, this is just the current most prominent symptom of a lockup, as the chip obviously no longer generates interrupts when it's locked up. You can try RADEON_NO_IRQS=1 RADEON_NO_USLEEPS=1 for different symptoms. tried that didnt seem to make any diff Well, you shouldn't get an drmRadeonIrqWait error with these, or something's very wrong. and this might make since due to the fact im using a joystick that is usb but i dont know if its related but the problem usally accors when i move the ship around really fast and that would make the joystick send more stuff at that time but this is just a guess Does playing with the keyboard make a difference? doesnt seem to had same effects Then it's probably unrelated to the joystick. and what would be best way to get a backtrace? get glaxium with debugging symbols? or should i just run gdb on x? You can't get a backtrace for a lockup, that's one of the bad things about them. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Conclusions from the Parallelizing MESA's pipeline thread
Felix, On Mon, Dec 02, 2002 at 06:45:15PM +0100, Felix Kühling wrote: Hello, First of all, thanks for all the comments I received in this thread. During the last few days I was also inspired to start more systematic reading of the MESA and Radeon driver source codes. In these 5 days I learned more than in 5 months before! I'm really surprised with your fast advances! As to the subject, there are three main conclusions I draw from this thread: - rendering parallelization has been done before with different approaches - implementing the parallel pipeline I had in mind would be a lot of work - with TCL hardware there would be little or no benefit Nevertheless it was good food for thought. There are other projects within DRI which are interesting, too. I'm thinking of indirect accellerated rendering which was discussed previously a couple of times. Yes, this is surely interesting, especially because IMHO it could open a door to a new driver paradigm, where the OpenGL state would be in X server space, rather than in the client, and therefore eliminating several security concerns. But this is another story... For now there are a few bugs left in the Radeon driver to fix ... Unfortunately I've been too busy lately for DRI development (not to mention the chronic amneasia regarding the IRC meetings...) I've been under pressure to have results for my PhD and this will likely endure until a conference next February. (I guess I'm paying for fooling around in the last year.) I've been using my little free time to take care of some unfinished businesses (my webpage, and some old projects). But I confess that I'm eager to start coding on DRI again.. (If I just had another pair of eyes and hands on my back! ;-) José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote: | So if we agree on this, I would make this | controlled by an environment variable. ... The intent of the spec is that drivers should support whichever texture internal formats they wish to support, and apps should choose between them (or use the default only if they truly don't care). Environment variables aren't very portable, and work around the intent of the spec. Is there some compelling reason to use them, rather than just having the driver do what was intended? Allen --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Sun, Dec 01, 2002 at 02:12:08PM -0500, Leif Delgass wrote: | According to section 4.1.8 of the OpenGL 1.4 spec: Initially, dithering | is enabled -- so that should always be the initial default. Right. Glean disables dithering in some cases (particularly when object identifiers are encoded in RGB values), but as long as the driver doesn't silently re-enable dithering, everything should work correctly. Allen --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] WORK FROM HOME!! TOP EARNING POTENTIAL!
Industry leader seeks entrepreneurs for national and international market expansion. We have an immediate need and are willing to train and develop even non- experienced individuals in local and international markets. Candidates must be self-motivated individuals with the entrepreneurial drive to run their own independent business. Here are some highlights: Huge compensation benefits program offered: Uncapped commissions and bonuses. 5 different ways to make money! Residual income from repeat business. Total Work from Home Flexibility: No commuting necessary! Work from home environment. P/T or F/T. Create your own schedule and hours. No sales experience expected or needed. Company Perks: National/International all expense paid vacations, business or pleasure. Car allowance available. Health Insurance benefits available. Our 12 year-old Inc 500 company has developed proprietary products to help people quickly and easily solve health problems in a multi-billion dollar market place! We offer the best company backing in the industry: Full Company Support: Each independently run business is backed with full company support. No territories to worry about. All orders are processed and shipped by the company. Full Training: Personal one-on-one training by top company leaders. Work with company leaders that are focused on your success. What we expect from you: Strong work ethic required. Honesty and integrity expected. Management / leadership skills helpful, but not necessary. Respond immediately to receive a FREE information pack on these amazing products and how you can MAKE MONEY FROM HOME! Click Here! To be removed from our mailing lists, please click here. 6181bqMu0-222WClp6884NHiD2-527aGpZ2700OqKI2-186ifOp4758pcno4-207MnJpl64 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] nForce and AGPGART
I think that I will resell my nforce 415d if I do not find the pilot for the agp it is not in the kernel 2.4.20... Le Lundi 2 Décembre 2002 07:38, Forge a écrit : While we're praying for nForce AGPGART, can I butt in with my lspci -v -xxx and pray for nForce2 AGPGART, as well? I'm pondering a 9700 Pro, but the AGPGART/drivers/NVidia documentation problem has me waiting. I knew their graphics cards were all proprietary and difficult, I never realized their motherboards are, too!! - Rich 'Forge' Mingin Cédric S. wrote: hi, i have the same proble that Rene Sepulveda : ati aiw 32Mo agp nidia nforce 415d, ide=ok, usb=ok, sound=ok, AGP=BAD ! the nvidia's driver agp work only with nforce 420 (nofrce415+igp) Alexander Stohr wrote: Can you please send the outputs of `lspci -v -xxx` to the list? --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Issue with Radeon VIVO FreeBSD 4.7-STABLE
I have been having experiencing some issues with FreeBSD 4.7 and the DRI tree as of lately This occurred awhile back in a change dated back around October in that month related to the radeon_dri.so I have a Radeon R100 VIVO, attached is my XFree86.0.log, a copy of my kernel configuration, and a attachment showing the gdb k of the kernel. So if someone could take a peak at this, and help a little My system specs are, AMD TBird 1.4Ghz, 512Meg of PC133 SDRAM CAS=2 ATI Radeon VIVO 64meg DDR BIOS Version 001.001.000.053, Part Number 11370702100, Dated, 2000/07/13 NTSC Bios. Tyan Trinity KT-A, KT133A Chipset, Creative SoundBlaster PCI 512, Adaptec 2940U2W, 4.5GB Quantum Viking II (UWSCSI3) Pioneer DVD-ROM (SCSI2) TDK VeloCD 12/10/32x And a Adaptec DuoConnect Firewire Adapter with USB 2.0 If anyone can please shed a little light, and actually look into this? Thanks. dmesg.out Description: a/octet-stream crash2 Description: a/octet-stream LIVID Description: a/octet-stream XFree86.0.log Description: a/octet-stream
