Re: [Dri-devel] r200 / radeon blend trouble
Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that the radeon and r200 driver
announce GL_EXT_blend_color (because it's part of the imaging subset),
but neither one implements it at all. Unsurprisingly, it doesn't work
(seems to use some sort of a default color, though not the Open GL
default color for this extension).
I've looked throgh the r200_reg.h and radeon_reg.h but couldn't find an
obvious register to store the constant blend color. In fact, ATI says
GL_EXT_blend_color isn't available on the R100, so maybe this needs a
different approach. Any ideas?
Are you sure? It looks like the code is all there in r200_state.c:
void r200BlendFuncSeparate( ... )
{
...
case GL_CONSTANT_COLOR:
b |= R200_SRC_BLEND_GL_CONST_COLOR;
break;
case GL_ONE_MINUS_CONSTANT_COLOR:
b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_COLOR;
break;
case GL_CONSTANT_ALPHA:
b |= R200_SRC_BLEND_GL_CONST_ALPHA;
break;
case GL_ONE_MINUS_CONSTANT_ALPHA:
b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_ALPHA;
break;
}
Am I missing something -- isn't this setting the appropriate blend modes? Is
the constant color not getting updated correctly?
Keith
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
Dave Airlie wrote: So should we just work on getting everything running on newtree then and not worry about the security issues for now? Sounds good to me, I'll look into disabling DMA by default, if we have the option we are okay, my only issue is though should there be something in the DRM that it affects? I can't see how XF86Config could make it safe, if I have a DRM that allows it I can access it from userspace process without DRI or XFree86... XF86Config should only be modifiable by root, so if root decides to be insecure, that's root's business. BTW, if you're working with vertices, you should definitely be using the new t_vertex.c code (see the i830 driver) if at all possible. It can be extended to cover some more scenarios if necessary -- perhaps we need to allow driver extensions to that code. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 and new tree
On Fri, Feb 13, 2004 at 01:31:59AM +, Dave Airlie wrote: > > > > So should we just work on getting everything running on newtree then and not > > worry about the security issues for now? > > > > Sounds good to me, I'll look into disabling DMA by default, if we have the > option we are okay, my only issue is though should there be something in > the DRM that it affects? I can't see how XF86Config could make it safe, if The thing with normal DMA in Mach64 is that the DMA buffers can have not only geometry, textures, but also bus mastering commands which almost give access of the system full physical memory to the client. But the current DRM has a pseudo-DMA mode which from the client POV works just like the normal DMS, except that is syncronous. That pseudo-DMA mode was original written as a debugging aiding tool to help transition for the full DMA. It sends the commands to the card one by one using MMIO. If we add a simple sanity/security check to the mach64_do_dispatch_pseudo_dma() in mach64_dma.c then client no longer can issue naughty commands. > I have a DRM that allows it I can access it from userspace process without > DRI or XFree86... That's not correct. Many DRM IOCTLs can only be used by root (such as the one to enable/disable DMA). [...] > > And Jose if you have any work done on the DRM interface change in any > state or any ideas, could you drop it somewhere so I can start looking at > it maybe.. I don't care if it does anything I'm more trying to get the > ideas you were proposing than a working DRM ... I'm afraid I have many ideas but not work in the same proportion... There is a newdrm-0-0-1-branch which has some of the necessary infrastuture (especially the DMA pool mangament code is complete). Unfortunately at the time I got carried away and also tried to make the DRM common code in a true library (replacing DRM_* macros by functions like a mania) and eventually didn't finish either task. I'll see if I have any uncommited code in my hard-drive and generate the doxygen documentation for you this weekend. But to avoid past mistakes I strongly advise you to take this slowly, with one little step at a time. Having Mach64 on the trunk seems a step big enough, without any prejudice to your goals. Jose Fonseca --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [vendor-sec] Minimal fix for the R128 drivers
Hi,
one of our developers mentioned that depth->n can be negative.
I didn't checked the whole code but even if depth->n is unsigned,
count is signed and can be negative by using a depth->n > INT_MAX.
Is this a real problem or do we just hunt ghosts here?
On Wed, 14 Jan 2004, Alan Cox wrote:
> I think this is about the minimal fix needed. I'm not entirely happy
> with the limits picked, especially for spans, but maybe someone with
> an R128 can verify it is ok, or change the code to loop each chunk
> of pixels/span data.
>
> I've not yet looked at the new SiS allocator problems in detail. The
> 6326 really wants a different allocator anyway.
>
> Alan
>
>
> [ Part 2: "Attached Text" ]
>
> [ The following text is in the "UTF-8" character set. ]
> [ Your display is set for the "iso-8859-1" character set. ]
> [ Some characters may be displayed incorrectly. ]
>
> --- drivers/char/drm/r128_state.c~2004-01-14 13:42:38.0 +
> +++ drivers/char/drm/r128_state.c 2004-01-14 13:46:27.0 +
> @@ -23,8 +23,20 @@
> * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> * DEALINGS IN THE SOFTWARE.
> *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * RED HAT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * THIS SOFTWARE IS NOT INTENDED FOR USE IN SAFETY CRITICAL SYSTEMS
> + *
> * Authors:
> *Gareth Hughes <[EMAIL PROTECTED]>
> + *
> + * Memory allocation size checks added 14/01/2003, Alan Cox <[EMAIL PROTECTED]>
> */
>
> #include "r128.h"
> @@ -901,6 +913,9 @@
> DRM_DEBUG( "%s\n", __FUNCTION__ );
>
> count = depth->n;
> +
> + if( count > 4096 )
> + return -EMSGSIZE;
> if ( copy_from_user( &x, depth->x, sizeof(x) ) ) {
> return -EFAULT;
> }
> @@ -994,6 +1009,9 @@
> DRM_DEBUG( "%s\n", __FUNCTION__ );
>
> count = depth->n;
> +
> + if( count > 4096 )
> + return -EMSGSIZE;
>
> x = kmalloc( count * sizeof(*x), GFP_KERNEL );
> if ( x == NULL ) {
> @@ -1109,6 +1127,9 @@
> DRM_DEBUG( "%s\n", __FUNCTION__ );
>
> count = depth->n;
> +
> + if ( count > 4096 )
> + return -EMSGSIZE;
> if ( copy_from_user( &x, depth->x, sizeof(x) ) ) {
> return -EFAULT;
> }
>
Bye,
Thomas
--
Thomas Biege <[EMAIL PROTECTED]>, SUSE LINUX AG, Security Support & Auditing
--
# If you have the "driftnet" program installed, webcollage can display a
# collage of images sniffed off your local ethernet, instead of pulled out
# of search engines: in that way, your screensaver can display the images
# that your co-workers are downloading!
-- xscreensaver source-code
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-7 branch illness and snapshots..
Okay I wasn't as complete as I thought, the Mesa and the DRM I was using were from the branch but I never updated my 2d driver, it was still the old branch... so then I noticed something else which might cause problems with the snapshots When I updated and using the XFree86 from the snapshot directory, I was missing an I2C symbol, the ati driver in DRI CVS seems to need a newer version of libi2c.a, mine was from Fedora Core 1... The 2d driver builds now but 3d seems to crap it out .. it'll be a day or two until I figure it out .. I might need to get a serial console together.. (or a network).. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Keith Whitwell wrote:
Roland Scheidegger wrote:
When I was playing around with texenv (I'm trying to implement
GL_EXT_blend_func_separate and GL_EXT_blend_equation_separate for the
R200, though my attempts to modify texenv to make it a useful test for
that were unsuccesful), I've noticed that the radeon and r200 driver
announce GL_EXT_blend_color (because it's part of the imaging subset),
but neither one implements it at all. Unsurprisingly, it doesn't work
(seems to use some sort of a default color, though not the Open GL
default color for this extension).
I've looked throgh the r200_reg.h and radeon_reg.h but couldn't find
an obvious register to store the constant blend color. In fact, ATI
says GL_EXT_blend_color isn't available on the R100, so maybe this
needs a different approach. Any ideas?
Are you sure? It looks like the code is all there in r200_state.c:
void r200BlendFuncSeparate( ... )
{
...
case GL_CONSTANT_COLOR:
b |= R200_SRC_BLEND_GL_CONST_COLOR;
break;
case GL_ONE_MINUS_CONSTANT_COLOR:
b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_COLOR;
break;
case GL_CONSTANT_ALPHA:
b |= R200_SRC_BLEND_GL_CONST_ALPHA;
break;
case GL_ONE_MINUS_CONSTANT_ALPHA:
b |= R200_SRC_BLEND_GL_ONE_MINUS_CONST_ALPHA;
break;
}
Am I missing something -- isn't this setting the appropriate blend
modes? Is the constant color not getting updated correctly?
Yes, exactly, the constant color isn't updated at all (so the color is
_really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to inform
the driver of the changed color, but neither R200 nor Radeon implement it.
Roland
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage kernel module howto
Just to be sure, did you check out the savage-2-0-0-branch of DRI cvs? do you see any files that start with 'savage' in xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel? Alex hi, at first i just pulled the head revision and extracted the tarball with the 2d driver into it (and the 2d driver was built ok). then i updated the kernel directory to the new branch too, so i got the savage.o drm module, which also works ok. but in order to get savage_dri.so, i updated the whole xc/ directory to savage-2-0-0-branch, and now it won't even build. in the very beginning of Make World, it complains about missing accum.c needed for accum.c or something like this. could you put together some sort of howto for this savage beast, since i'm out of luck with it now. or maybe if you plan to move the whole thing into head soon, i could just wait. xv is more important than 3d anyway... regards, georgi
Re: [Dri-devel] Fwd: [Dri-users] glPushAttrib()
El Viernes, 13 de Febrero de 2004 01:29, Ville Syrjälä escribió: > mga? The poster said it was observed on ATI cards. That's right. That's why I asked in the dri lists. I previously posted a similar mail in debian-powerpc and Michel Dänzer suggested that the problem could be DRI specific. I also have a nVidia card and everything works well there. As Brian says, glPushAttrib() seems to bring OpenGL to an undefined state. For instance, I have some lights in the scene which are positioned after camera movement so if I move the camera the lights remain pointing to the ground; then I have some objects pushing the GL_LIGHTING_BIT which causes the lights to be displaced as the camera moves, weird. If I don't use glPushAttrib() the scene renders properly. The GL_CURRENT_BIT doesn't work either, color is not well restored after glPopAttrib(). Well, I guess the explanation is not quite clear. I could write a sample program to test glPushAttrib() if you want. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fwd: [Dri-users] glPushAttrib()
Domingo Fiesta Segura (by way of Domingo Fiesta Segura ) wrote: El Viernes, 13 de Febrero de 2004 01:29, Ville Syrjälä escribió: mga? The poster said it was observed on ATI cards. That's right. That's why I asked in the dri lists. I previously posted a similar mail in debian-powerpc and Michel Dänzer suggested that the problem could be DRI specific. I also have a nVidia card and everything works well there. As Brian says, glPushAttrib() seems to bring OpenGL to an undefined state. No, not glPushAttrib(). glPopAttrib() is where the problem probably occurs. For instance, I have some lights in the scene which are positioned after camera movement so if I move the camera the lights remain pointing to the ground; then I have some objects pushing the GL_LIGHTING_BIT which causes the lights to be displaced as the camera moves, weird. If I don't use glPushAttrib() the scene renders properly. The GL_CURRENT_BIT doesn't work either, color is not well restored after glPopAttrib(). Well, I guess the explanation is not quite clear. I could write a sample program to test glPushAttrib() if you want. Great. -Brian --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage kernel module howto
--- Georgi Hristov <[EMAIL PROTECTED]> wrote:
> >
> >
> >Just to be sure, did you check out the savage-2-0-0-branch of DRI
> cvs?
> >do you see any files that start with 'savage' in
> >xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel?
> >
> >Alex
> >
> >
> >
> hi,
>
> at first i just pulled the head revision and extracted the tarball
> with
> the 2d driver into it (and the 2d driver was built ok). then i
> updated
> the kernel directory to the new branch too, so i got the savage.o drm
>
> module, which also works ok.
> but in order to get savage_dri.so, i updated the whole xc/ directory
> to
> savage-2-0-0-branch, and now it won't even build. in the very
> beginning
> of Make World, it complains about missing accum.c needed for accum.c
> or
> something like this.
> could you put together some sort of howto for this savage beast,
> since
> i'm out of luck with it now. or maybe if you plan to move the whole
> thing into head soon, i could just wait.
> xv is more important than 3d anyway...
>
If all you need is Xv, your best bet is just to use the stock xfree86
savage driver. If you want to play with 3D, all you need to do is
download a fresh copy of the savage-2-0-0-branch. you don't need a
copy of head. just download a fresh copy of the branch ('cvs -z3
-d:pserver:[EMAIL PROTECTED]:/cvs/dri co
-rsavage-2-0-0-branch xc') and at the top of the tree run 'make World'.
once it's built you can either install the whole thing over your
current xfree86 installation ('make install') or just copy the
savage_dri.so (from xc/xc/lib/GL/mesa/src/drv/savage), savage_drv.o
(from xc/xc/programs/Xserver/hw/xfree86/drivers/savage), and savage.o
to the approprate places in your file system.
the savage.o kernel module must be built like before:
Change to the
xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel directory
in the DRI cvs tree.
to compile the DRM run:
make -f Makefile.linux
or:
make -f Makefile.linux LINUXDIR=/path/to/kernel/source
if the previous command could not find your kernel source tree or if
you want to build against another kernel.
copy the resulting *.ko (2.6.x kernel) or *.o (2.4.x kernel) modules
into the kernel module tree, usually:
/lib/modules/kernel version/kernel/drivers/char/drm
where 'kernel version' is the kernel you built against, then run
'depmod -a'.
Make sure you have run at least 'make dep' on your kernel tree or the
build will fail.
Alex
> regards,
> georgi
>
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach 64 DRM patch
I needed this patch to get the kernel module to insert properly.
Mostly it adds an irq handler for mach64, which I based on the rage128 one.
This patch was made from the xc/xc/programs/Xserver/hw/xfree86/os-support
directory.
Dave, I'll try your new 2D driver tonight. With the one before, I could
compile, but X segfaulted while loading the ati_misc driver.
-James
Index: linux/drm/kernel/mach64_drv.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.c,v
retrieving revision 1.1.12.1
diff -u -r1.1.12.1 mach64_drv.c
--- linux/drm/kernel/mach64_drv.c 9 Feb 2004 00:08:59 - 1.1.12.1
+++ linux/drm/kernel/mach64_drv.c 13 Feb 2004 16:25:39 -
@@ -47,7 +47,6 @@
#include "drm_ioctl.h"
#include "drm_lock.h"
#include "drm_memory.h"
-#include "drm_pci.h"
#include "drm_proc.h"
#include "drm_vm.h"
#include "drm_stub.h"
Index: shared/drm/kernel/mach64_dma.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/Attic/mach64_dma.c,v
retrieving revision 1.1.4.1
diff -u -r1.1.4.1 mach64_dma.c
--- shared/drm/kernel/mach64_dma.c 9 Feb 2004 00:09:39 - 1.1.4.1
+++ shared/drm/kernel/mach64_dma.c 13 Feb 2004 16:26:33 -
@@ -34,6 +34,7 @@
#include "mach64.h"
#include "drmP.h"
#include "drm.h"
+#include "drm_pci.h"
#include "mach64_drm.h"
#include "mach64_drv.h"
Index: shared/drm/kernel/mach64_drv.h
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.4.1
diff -u -r1.1.4.1 mach64_drv.h
--- shared/drm/kernel/mach64_drv.h 9 Feb 2004 00:09:39 - 1.1.4.1
+++ shared/drm/kernel/mach64_drv.h 13 Feb 2004 16:26:35 -
@@ -369,6 +369,7 @@
# define MACH64_CRTC_VBLANK (1 << 0)
# define MACH64_CRTC_VBLANK_INT_EN (1 << 1)
# define MACH64_CRTC_VBLANK_INT (1 << 2)
+# define MACH64_CRTC_VBLANK_INT_AK (1 << 2)
# define MACH64_CRTC_VLINE_INT_EN (1 << 3)
# define MACH64_CRTC_VLINE_INT (1 << 4)
# define MACH64_CRTC_VLINE_SYNC (1 << 5) /* 0=even, 1=odd */
Index: shared/drm/kernel/mach64_irq.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/Attic/mach64_irq.c,v
retrieving revision 1.1.4.1
diff -u -r1.1.4.1 mach64_irq.c
--- shared/drm/kernel/mach64_irq.c 9 Feb 2004 00:09:39 - 1.1.4.1
+++ shared/drm/kernel/mach64_irq.c 13 Feb 2004 16:26:36 -
@@ -76,6 +76,30 @@
#endif
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,1)
+void DRM(irq_handler)( DRM_IRQ_ARGS )
+#else
+irqreturn_t DRM(irq_handler)( DRM_IRQ_ARGS )
+#endif
+{
+ drm_device_t *dev = (drm_device_t *)arg;
+ drm_mach64_private_t *dev_priv =
+ (drm_mach64_private_t *)dev->dev_private;
+ int status;
+
+ status = MACH64_READ( MACH64_CRTC_INT_CNTL );
+
+ /* VBLANK interrupt */
+ if ( status & MACH64_CRTC_VBLANK_INT ) {
+ MACH64_WRITE( MACH64_CRTC_INT_CNTL, MACH64_CRTC_VBLANK_INT_AK );
+ atomic_inc(&dev->vbl_received);
+ DRM_WAKEUP(&dev->vbl_queue);
+ DRM(vbl_send_signals)(dev);
+ return IRQ_HANDLED;
+ }
+ return IRQ_NONE;
+}
+
int DRM(vblank_wait)(drm_device_t *dev, unsigned int *sequence)
{
unsigned int cur_vblank;
Re: [Dri-devel] r200 / radeon blend trouble
Am I missing something -- isn't this setting the appropriate blend modes? Is the constant color not getting updated correctly? Yes, exactly, the constant color isn't updated at all (so the color is _really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to inform the driver of the changed color, but neither R200 nor Radeon implement it. Wow. OK, the r200 register is RB3D_BLENDCOLOR: 0x3218, it holds an ARGB color. I can't find the r100 equivalent, but it'd be worth trying the same address. I'll let you know if I manage to dig it up. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: about Xfree86 with DRI and Mesa
On Tue, 10 Feb 2004 22:38:58 + Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: [snip] > Well looking at rubik cube screen saver, we have (I think) one bug that > I think I know this bug from mesa code in same source, so update the > Mesa code may could be a good idea, that I am able to do it, but I like > to know the answer of the question, first . BTW, could you be more specific what's wrong with the rubik cube demo? I don't see any errors with it. > > The bug is in some depths of the image for example in queens screen > saver, some queens in the back overlaps the queens in front. It sounds like a depth buffer problem. But I can't reproduce it here. Which hardware are you using? Could you post the output from lspci and lspci -n? > [snip] Felix --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Keith Whitwell wrote: Am I missing something -- isn't this setting the appropriate blend modes? Is the constant color not getting updated correctly? Yes, exactly, the constant color isn't updated at all (so the color is _really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to inform the driver of the changed color, but neither R200 nor Radeon implement it. Wow. OK, the r200 register is RB3D_BLENDCOLOR: 0x3218, it holds an ARGB color. ok, I'll try to implement it. This register is just before the ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately requires a drm change, and unfortunately though I think it needs a new state atom (since appending to the ctx atom won't work, as it wouldn't be compatible at all to old drm modules). It's a pity that appending to the ctx atom won't work, as this would have avoided some strange problem (ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or CBLENDCNTL or both, not sure yet since I still lack a test application. That's a problem since the ctx atom gets emitted a lot, and thus the previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom get always overwritten. Maybe I'll figure out how the registers interact to avoid just always resubmitting ABLENDCNTL and CBLENDCNTL...). For only the blend_color extension this isn't a problem though. I can't find the r100 equivalent, but it'd be worth trying the same address. I'll let you know if I manage to dig it up. This address would be quite a bit higher than everything else in the R100 driver though. Might be worth a shot, but maybe the R100 just doesn't support it - at least the pdf from ati listing all available extensions suggests that. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: New DRI driver interface (Re: CVS Update: xc (branch: driinterface-0-0-3-branch))
Ian Romanick wrote: > Anyone know of any good, simple pbuffers tests? :) The ATI fglrx linux driver contains source code (the rpm installs it under /usr/src/ATI) for an enhanced glxgears that renders glxgears to a rotating cube using pbuffers, along with some documentation on using pbuffers in general. -- -Torgeir --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Roland Scheidegger wrote: Keith Whitwell wrote: Am I missing something -- isn't this setting the appropriate blend modes? Is the constant color not getting updated correctly? Yes, exactly, the constant color isn't updated at all (so the color is _really_ constant ;-)). Mesa would call ctx->Driver.BlendColor to inform the driver of the changed color, but neither R200 nor Radeon implement it. Wow. OK, the r200 register is RB3D_BLENDCOLOR: 0x3218, it holds an ARGB color. ok, I'll try to implement it. This register is just before the ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately requires a drm change, and unfortunately though I think it needs a new state atom (since appending to the ctx atom won't work, as it wouldn't be compatible at all to old drm modules). It's a pity that appending to the ctx atom won't work, as this would have avoided some strange problem (ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or CBLENDCNTL or both, not sure yet since I still lack a test application. That's a problem since the ctx atom gets emitted a lot, and thus the previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom get always overwritten. Maybe I'll figure out how the registers interact to avoid just always resubmitting ABLENDCNTL and CBLENDCNTL...). For only the blend_color extension this isn't a problem though. You could create two new state atoms and just leave the old ctx atom for legacy. Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Keith Whitwell wrote: ok, I'll try to implement it. This register is just before the ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately requires a drm change, and unfortunately though I think it needs a new state atom (since appending to the ctx atom won't work, as it wouldn't be compatible at all to old drm modules). It's a pity that appending to the ctx atom won't work, as this would have avoided some strange problem (ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or CBLENDCNTL or both, not sure yet since I still lack a test application. That's a problem since the ctx atom gets emitted a lot, and thus the previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom get always overwritten. Maybe I'll figure out how the registers interact to avoid just always resubmitting ABLENDCNTL and CBLENDCNTL...). For only the blend_color extension this isn't a problem though. You could create two new state atoms and just leave the old ctx atom for legacy. As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fwd: [Dri-users] glPushAttrib()
El Viernes, 13 de Febrero de 2004 16:22, Brian Paul escribió:
> No, not glPushAttrib(). glPopAttrib() is where the problem probably
> occurs.
Sorry, my mistake O:-)
> Great.
I attach a very stupid program. It draws two cubes (one big blue, and
another red small). Press 'r' to rotate both. I use
glPushAttrib(GL_CURRENT_BIT)/glPopAttrib() to save/restore the current
color. I've successfully tested it with nvidia drivers (the big cube
remains being blue). When I try on my ATI Radeon Mobility (iBook 2.2) the
big cube starts blue, but once you rotate goes red (and it shouldn't).
I just hope it helps.
/* glPushAttrib(), glPopAttrib() tiny test */
#include
GLfloat angle = 0.0;
int win_w, win_h;
void keyboard(unsigned char, int, int);
void reshape(int, int);
void display(void);
int main(int argc, char **argv)
{
/* libglut stuff */
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize(500, 500);
glutInitWindowPosition(70, 70);
glutCreateWindow("Tiny test");
glutKeyboardFunc(keyboard);
glutReshapeFunc(reshape);
glutDisplayFunc(display);
/* Minimal Enables */
glEnable(GL_DEPTH_TEST);
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glEnable(GL_COLOR_MATERIAL);
glColorMaterial(GL_FRONT, GL_AMBIENT_AND_DIFFUSE);
glClearColor(1.0, 1.0, 1.0, 1.0);
/* Initial color is blue */
glColor3f(0.0, 0.0, 1.0);
/* Set up projection matrix */
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-5.0, 5.0, -5.0, 5.0, -5.0, 5.0);
glMatrixMode(GL_MODELVIEW);
glutMainLoop();
return 0;
}
void keyboard(unsigned char key, int x, int y)
{
switch (key) {
case 'r': /* Rotate cubes */
angle += 3.0;
if (angle > 360.0)
angle -= 360.0;
break;
case 27:
exit(0);
}
glutPostRedisplay();
}
void reshape(int w, int h)
{
win_w = w;
win_h = h;
}
void display(void)
{
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
/* Set viewport for blue cube */
glViewport(0, 0, win_w, win_h);
glLoadIdentity();
glRotatef(angle, 1.0, 1.0, 1.0);
glutSolidCube(3.5);
/* Set smaller viewport for red cube */
glViewport(0, 0, win_w/5, win_h/5);
glLoadIdentity();
glRotatef(angle, -1.0, 1.0, 1.0);
glPushAttrib(GL_CURRENT_BIT); /* Save blue color */
glColor3f(1.0, 0.0, 0.0);
glutSolidCube(3.5);
glPopAttrib(); /* Restore blue color */
glFlush();
glutSwapBuffers();
}
Re: [Dri-devel] r200 / radeon blend trouble
Roland Scheidegger wrote: Keith Whitwell wrote: ok, I'll try to implement it. This register is just before the ABLENDCNTL and CBLENDCNTL, so that makes it easier to support these (for the GL_EXT_blend_xx_separate extensions) at the same time. Unfortunately requires a drm change, and unfortunately though I think it needs a new state atom (since appending to the ctx atom won't work, as it wouldn't be compatible at all to old drm modules). It's a pity that appending to the ctx atom won't work, as this would have avoided some strange problem (ABLENDCNTL and CBLENDCNTL are not sompletely separate registers from BLENDCNTL, i.e. writing to BLENDCNTL will affect either ABLENDCNTL or CBLENDCNTL or both, not sure yet since I still lack a test application. That's a problem since the ctx atom gets emitted a lot, and thus the previous updates to ABLENDCNTL and CBLENDCNTL in a different state atom get always overwritten. Maybe I'll figure out how the registers interact to avoid just always resubmitting ABLENDCNTL and CBLENDCNTL...). For only the blend_color extension this isn't a problem though. You could create two new state atoms and just leave the old ctx atom for legacy. As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact. I don't see why -- in userspace, just up the required drm minor number. In kernel space just define two new atoms (which happen to overlap the old one). What's the problem? Keith --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fwd: [Dri-users] glPushAttrib()
Domingo Fiesta Segura wrote: El Viernes, 13 de Febrero de 2004 16:22, Brian Paul escribió: No, not glPushAttrib(). glPopAttrib() is where the problem probably occurs. Sorry, my mistake O:-) Great. I attach a very stupid program. It draws two cubes (one big blue, and another red small). Press 'r' to rotate both. I use glPushAttrib(GL_CURRENT_BIT)/glPopAttrib() to save/restore the current color. I've successfully tested it with nvidia drivers (the big cube remains being blue). When I try on my ATI Radeon Mobility (iBook 2.2) the big cube starts blue, but once you rotate goes red (and it shouldn't). I just hope it helps. /* glPushAttrib(), glPopAttrib() tiny test */ I've just tested this demo here (r200 driver) and it works fine (the big cube remains blue, the red remains red). I'm not sure, but until very recently (5 days or so ago) there were some bugs in both the radeon and r200 driver with respects to materials and lights not always being updated correctly. Maybe this was the reason for this problem. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Keith Whitwell wrote: As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact. I don't see why -- in userspace, just up the required drm minor number. In kernel space just define two new atoms (which happen to overlap the old one). What's the problem? It seems to me a rather drastic solution to make the driver incompatible to the current drm just because of some new extensions (there are already extensions which only work if a certain drm version is present, but the driver works just fine if the drm is a bit older). And that blend_color is broken doesn't seem to be a serious enough problem that the driver would absolutely require a new drm version to run IMHO. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Fwd: [Dri-users] glPushAttrib()
El Viernes, 13 de Febrero de 2004 22:59, Roland Scheidegger escribió: > I've just tested this demo here (r200 driver) and it works fine (the big > cube remains blue, the red remains red). Which snapshot of DRI are you using ? I've got one from 2003-10-05... , too old :-/ > I'm not sure, but until very recently (5 days or so ago) there were some > bugs in both the radeon and r200 driver with respects to materials and > lights not always being updated correctly. Maybe this was the reason for > this problem. It could be, now that I realize I have a DRI version bC. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Roland Scheidegger wrote: Keith Whitwell wrote: As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact. I don't see why -- in userspace, just up the required drm minor number. In kernel space just define two new atoms (which happen to overlap the old one). What's the problem? It seems to me a rather drastic solution to make the driver incompatible to the current drm just because of some new extensions (there are already extensions which only work if a certain drm version is present, but the driver works just fine if the drm is a bit older). And that blend_color is broken doesn't seem to be a serious enough problem that the driver would absolutely require a new drm version to run IMHO. In other cases I would probably agree with you, but in this particular case I diagree. We're a looong time from this driver appearing in an XFree86 release, so the only people who are going to get it will be people manually installing driver updates. The alternative is, as you pointed out, some really ugly code. Not only that, we should be able to get these DRM changes into a kernel release pretty quick. One other alternative, which isn't very nice either, is to conditionally compile in support for either the old or the new state atoms. Then we could have binary snapshots built either way. That way users wouldn't necessarilly be forced into a DRM upgrade as well. I don't know if I like this idea at all, but I thought it was at least worth mentioning. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")
Just tried ut2003 on R100 with current DRI+MESA cvs HEAD. Now with the "MULT-code" in radeon_state.c radeon_state_init.c (change lighting to use MULT instead of PREMULT ...) the shading/lighting of warriors changed a little bit in tcl-mode. It's been buggy before in tcl-mode, but differently. Now it is better visible at startup, when the warrior jumps through the logo. And it is visible for example when spectating some bot. This looks OK in non-tcl-mode. best regards, Andreas --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")
Andreas Stenglein wrote: Just tried ut2003 on R100 with current DRI+MESA cvs HEAD. Now with the "MULT-code" in radeon_state.c radeon_state_init.c (change lighting to use MULT instead of PREMULT ...) the shading/lighting of warriors changed a little bit in tcl-mode. It's been buggy before in tcl-mode, but differently. Now it is better visible at startup, when the warrior jumps through the logo. And it is visible for example when spectating some bot. This looks OK in non-tcl-mode. What exactly does it look like? Does it flicker or so? Just the other day, I've noticed not even the good old tuxracer runs correct on the R100 on my 2nd PC - the ice areas flickered a lot, but it runs fine on R200. The lighting changes didn't make a difference at all though in that game. I just hope UT2004 doesn't run even worse, I was too afraid to download the demo yet ;-). Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: about Xfree86 with DRI and Mesa
#lspci -n 00:00.0 Class 0600: 1106:0305 (rev 80) 00:01.0 Class 0604: 1106:8305 00:07.0 Class 0601: 1106:0686 (rev 42) 00:07.1 Class 0101: 1106:0571 (rev 06) 00:07.2 Class 0c03: 1106:3038 (rev 1a) 00:07.4 Class 0680: 1106:3057 (rev 40) 00:07.5 Class 0401: 1106:3058 (rev 50) 00:09.0 Class 0780: 14f1:2f00 (rev 01) 00:0a.0 Class 0607: 104c:ac50 (rev 01) 00:0b.0 Class 0200: 10ec:8139 (rev 10) 01:00.0 Class 0300: 5333:8d02 (rev 01) On Fri, 2004-02-13 at 17:43, Felix Kühling wrote: > On Tue, 10 Feb 2004 22:38:58 + > Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: > > [snip] > > Well looking at rubik cube screen saver, we have (I think) one bug that > > I think I know this bug from mesa code in same source, so update the > > Mesa code may could be a good idea, that I am able to do it, but I like > > to know the answer of the question, first . > > BTW, could you be more specific what's wrong with the rubik cube demo? I > don't see any errors with it. > > > > > The bug is in some depths of the image for example in queens screen > > saver, some queens in the back overlaps the queens in front. > > It sounds like a depth buffer problem. yes > But I can't reproduce it here. > Which hardware are you using? Could you post the output from lspci and > lspci -n? > > > > [snip] > > Felix -- Sérgio M. B. <>
Re: [Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")
On Fri, Feb 13, 2004 at 11:52:05PM +0100, Andreas Stenglein wrote: > Just tried ut2003 on R100 with current DRI+MESA cvs HEAD. I just tried it on my Radeon 9100 and Athlon XP 1800+. OpenGL renderer string: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.1 Performance is terrible, much worse than in Enemy Territory (just tried too). And I set everything to "low". This is strange, because graphics is not really advanced (IMHO ET looks better). -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: about Xfree86 with DRI and Mesa
Am Samstag, 14. Februar 2004 00:13 schrieb Sérgio Monteiro Basto: > #lspci -n > 00:00.0 Class 0600: 1106:0305 (rev 80) > 00:01.0 Class 0604: 1106:8305 > 00:07.0 Class 0601: 1106:0686 (rev 42) > 00:07.1 Class 0101: 1106:0571 (rev 06) > 00:07.2 Class 0c03: 1106:3038 (rev 1a) > 00:07.4 Class 0680: 1106:3057 (rev 40) > 00:07.5 Class 0401: 1106:3058 (rev 50) > 00:09.0 Class 0780: 14f1:2f00 (rev 01) > 00:0a.0 Class 0607: 104c:ac50 (rev 01) > 00:0b.0 Class 0200: 10ec:8139 (rev 10) > 01:00.0 Class 0300: 5333:8d02 (rev 01) > > On Fri, 2004-02-13 at 17:43, Felix Kühling wrote: > > On Tue, 10 Feb 2004 22:38:58 + > > Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: > > > > [snip] > > > > > Well looking at rubik cube screen saver, we have (I think) one bug that > > > I think I know this bug from mesa code in same source, so update the > > > Mesa code may could be a good idea, that I am able to do it, but I like > > > to know the answer of the question, first . > > > > BTW, could you be more specific what's wrong with the rubik cube demo? I > > don't see any errors with it. > > > > > The bug is in some depths of the image for example in queens screen > > > saver, some queens in the back overlaps the queens in front. > > > > It sounds like a depth buffer problem. > > yes No problems at all on r200. But buffering problems with den "KDE 3.2" (kdeartwork3-xscreensaver-3.2.0-10) screensavers. Depends on xscreensaver-4.12-62. The later are fine alone. So I think KDE do not request double buffering. It seems to be page flipping related. => Only the objects flicker. -Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach 64 DRM patch
> I needed this patch to get the kernel module to insert properly. > > Mostly it adds an irq handler for mach64, which I based on the rage128 one. you sure you were running top of tree? I fixed this a while back in http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/Attic/mach64_irq.c?only_with_tag=mach64-0-0-7-branch I've tested the module loads/compiles on 2.4 and 2.6 and runs on 2.4.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
> When I updated and using the XFree86 from the snapshot directory, I was > missing an I2C symbol, the ati driver in DRI CVS seems to need a newer > version of libi2c.a, mine was from Fedora Core 1... > > The 2d driver builds now but 3d seems to crap it out .. it'll be a day or > two until I figure it out .. I might need to get a serial console > together.. (or a network).. Okay the 2D driver is now in a lot better state and should work fine ... the libi2c.a issue is still there I think.. Dave. > > Dave. > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 / radeon blend trouble
Ian Romanick wrote: Roland Scheidegger wrote: Keith Whitwell wrote: As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact. I don't see why -- in userspace, just up the required drm minor number. In kernel space just define two new atoms (which happen to overlap the old one). What's the problem? It seems to me a rather drastic solution to make the driver incompatible to the current drm just because of some new extensions (there are already extensions which only work if a certain drm version is present, but the driver works just fine if the drm is a bit older). And that blend_color is broken doesn't seem to be a serious enough problem that the driver would absolutely require a new drm version to run IMHO. In other cases I would probably agree with you, but in this particular case I diagree. We're a looong time from this driver appearing in an XFree86 release, so the only people who are going to get it will be people manually installing driver updates. The alternative is, as you pointed out, some really ugly code. Not only that, we should be able to get these DRM changes into a kernel release pretty quick. Ok then. Though as said, depending on the interaction between the xBLENDCNTL registers, it might not really be needed. The blendcolor fix alone is really easy enough to add with a new state atom and a drm version check, without too many "ifs". One other alternative, which isn't very nice either, is to conditionally compile in support for either the old or the new state atoms. Then we could have binary snapshots built either way. That way users wouldn't necessarilly be forced into a DRM upgrade as well. I don't know if I like this idea at all, but I thought it was at least worth mentioning. I don't think I like this neither. Sounds a bit too ugly IMHO. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")
On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote: > > Just the other day, I've noticed not even the good old tuxracer runs > correct on the R100 on my 2nd PC - the ice areas flickered a lot, That's a long standing tuxracer bug, Z fighting between several passes. > but it runs fine on R200. Sure? Environment mapping is broken with HW TCL here, so the ice doesn't look correct either. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [vendor-sec] Minimal fix for the R128 drivers
On Gwe, 2004-02-13 at 11:31, Thomas Biege wrote: > Hi, > one of our developers mentioned that depth->n can be negative. > > I didn't checked the whole code but even if depth->n is unsigned, > count is signed and can be negative by using a depth->n > INT_MAX. > > Is this a real problem or do we just hunt ghosts here? I can't see how to exploit it offhand but its certainly soemthing that wants a better fix rolling into the next updates. I'm embarrassed I missed something so obvious --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: about Xfree86 with DRI and Mesa
On Sat, 2004-02-14 at 00:04, Dieter Nützel wrote: > > > > > > BTW, could you be more specific what's wrong with the rubik cube demo? I > > > don't see any errors with it. > > > > > > > The bug is in some depths of the image for example in queens screen > > > > saver, some queens in the back overlaps the queens in front. > > > > > > It sounds like a depth buffer problem. > > > > yes > > No problems at all on r200. > But buffering problems with den "KDE 3.2" (kdeartwork3-xscreensaver-3.2.0-10) > screensavers. Depends on xscreensaver-4.12-62. > The later are fine alone. > So I think KDE do not request double buffering. > It seems to be page flipping related. => Only the objects flicker. > > -Dieter oops... is the problem is with kde, in gnome screen-savers works correctly, I have kde-3.1.4 and xscreensaver-4.14-2 what can I do to correct kde ? I am sorry for the false alarm and thanks -- Sérgio M. B. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 tcl and ut2003_demo, (since "using MULT instead of PREMULT...")
Michel DÃnzer wrote: On Sat, 2004-02-14 at 00:11, Roland Scheidegger wrote: Just the other day, I've noticed not even the good old tuxracer runs correct on the R100 on my 2nd PC - the ice areas flickered a lot, That's a long standing tuxracer bug, Z fighting between several passes. but it runs fine on R200. Sure? Environment mapping is broken with HW TCL here, so the ice doesn't look correct either. You're right, it's not correct. However, it doesn't flicker like it does on the R100, and I just missed the more subtle issues ;-). What I didn't miss though but simply completely forgot to mention is that the trace tux leaves behind is missing on the R200 (with hw tcl). Sometimes it shows up but at the wrong place. IIRC this did work on R100. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach 64 DRM patch
> you sure you were running top of tree? Yeah, I did this patch with cvs diff -u in my mach64-0-0-7-branch check out. That should work right? I fixed this a while back in > http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xf >ree86/os-support/shared/drm/kernel/Attic/mach64_irq.c?only_with_tag=mach64-0 >-0-7-branch Yeah, I did an update to get your 2D driver fixes and it picked up your interupt handler. Looks like I got out of sync some how. Weird. No big deal though, it was only a few minutes work :-D > I've tested the module loads/compiles on 2.4 and 2.6 and runs on 2.4.. > > Dave. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 branch illness and snapshots..
Dave, Here's a test report: -X starts up fine now, window manager comes up, etc. -xvinfo reports xv working, playing mpeg with mplayer confirms this. -glxinfo reports correct info -glxgears locks up. Rest of X is locked, but mouse can be moved around. I can ssh in, but can't seem to kill the X server. A reboot is required to get the screen working again. Looks good so far :-) -James On Friday 13 February 2004 04:23 pm, Dave Airlie wrote: > > When I updated and using the XFree86 from the snapshot directory, I was > > missing an I2C symbol, the ati driver in DRI CVS seems to need a newer > > version of libi2c.a, mine was from Fedora Core 1... > > > > The 2d driver builds now but 3d seems to crap it out .. it'll be a day or > > two until I figure it out .. I might need to get a serial console > > together.. (or a network).. > > Okay the 2D driver is now in a lot better state and should work fine ... > the libi2c.a issue is still there I think.. > > Dave. > > > Dave. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GATOS and DRI merge attempts
I just caught on to something - the "Gatos 3D driver" that's been referred to as the cause of my woes. While reading the documentation (http://dri.sourceforge.net/cgi-bin/moin.cgi/DriverFiles) I realized that the "3D driver" is under "xc/lib/GL/mesa/src/drv". The Gatos folks distribute that as a patch changing three lines in radeon_span.c I haven't been using that patch. Never was. If that's the aforementioned compensation change to the 3D driver, then it's time to start looking for another cause. I did try the patch, of course, and it didn't help matters. Caused a lockup on X startup if memory serves. There aren't any changes to the 2D radeon_dri.? and radeon_sarea.? files either. All of the experimenting I've done points to the idea that memory setup problems cause either X locks or instant reboots. With Gatos unmodified, and the DRI DRM left alone except for the version minor number, and everything else as Gentoo xfree-4.3.0-rc4 left it, applications coexist with each other normally. I can even open multiple /usr/lib/xscreensaver/gears windows. While doing so, CPU usage spikes slightly as expected, and glxinfo continues to report that it can get direct rendering. xawtv also coexists nicely with 3D apps. The problem is simply that I can't see any visible rendering. Now, can anyone think of what *specific* misinteraction might cause these symptoms? I just realized, Gentoo patches might be screwing me up... here's the ones with 'radeon'in the name: 1212_all_4.3.0-radeon-dpms-on-dvi-v2.patch 1214_all_4.3.0-radeon-disable-VideoRAM-option.patch 5100_all_4.3.0-radeon-support-from-ATI-backport-from-CVS-v2.patch 5105_ia64_4.2.99.901-ati-radeon-pagesize.patch 5114_all_4.3.0-radeon-drm-ioremapagp.patch 5115_all_4.3.0-radeon-reinit.patch 5116_all_4.3.0-radeon-rh-forcelegacycrt-alan.patch 5117_all_4.3.0-radeon-support-backport-from-CVS-v2.patch 5118_all_4.3.0-radeon-autodetect-pci-or-agp-cards.patch 5120_all_4.3.0-radeon-ap1-from-daenzer.patch 5150_ia64_4.3.0-radeon-preint10.patch Any likely culprits jump out at you? --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
