Re: [Dri-devel] Enabled in xfree log, but not in glxinfo

2002-12-12 Thread Sven Luther
On Fri, Dec 13, 2002 at 03:40:06AM +0100, [EMAIL PROTECTED] wrote:
> 
> 
> Hi!
> I've just reinstalled my system and tried to use dri with my radeon 8500. I've
> my module and drivers (from the debian package, thanks M.Danzer) but i can't
> figure why it's not working. Xfree logs' say that Direct Rendering is enabled,
> but glxinfo says the oposite.

That is usually because you are using a non DRI enabled libGL.

Could you check which libGL you are using, and eventually put the path
of the DRI one in /etc/ld.so.conf and rerun ldconfig.

man ldconfig is your friend for this.

Friendly,

Sven Luther


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Sven Luther
On Thu, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote:
> On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> > ...
> > It takes two to tango so its not just what I need its also what do they
> > need.
> > 
> > What I would like to see would be:
> > 
> > A single definitive source for the DRM code, one where contributions go
> > back from Linux, from *BSD, from core XFree86 as well as from the DRI
> > project.
> 
> 
> May I suggest that the best way to do that, is to keep the kernel DRM code,
> as a **SEPARATE PROJECT**, at least on the source code repository level.
> 
> IMO, there should be a separate repository, or at least a separate
> directory at the same level as the top-level "xc".
> 
> The only thing from the driver that really belongs buried in the xfree86
> server code, is a single, os-neutral copy of "drm.h", from whatever version
> of DRM that branch of xfree86 is officially supporting.
> 
> 
> Once you have achieved that separation, you have something actually
> resembling a formal API between user-level and kernel driver level.
> That is the only way things are going to get cleaned up, process-wise.
> Not to mention greatly aiding kernel coding efforts for non-linux
> platforms.

And there are also people wanting to use the DRM outside of XFree86,
maybe even outside of the DRI, not sure though.

Friendly,

Sven Luther


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] problems with CVS head and i810

2002-12-12 Thread Dave Airlie

Just to give more information..

the first time I run my application it runs fine. I exit it and X reloads
and then I start it again .. the second time the app claims Indirect
rendering, and then X dumps out the below and crashes out..

The app works with the latest i810.o + XF86 4.2 from Redhat. The DRI X
server blows up..

Dave.

Dave Airlie said:
>
> Well I built the CVS tree head and made the i810 modules and ran my test
> opengl program on it and it worked the first time then started spewing
> errors ala
>
> (II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is
> 0x pgetbl_ctl: 0x7e40001 pgetbl_err: 0x0
> ipeir: 0 iphdr: c2fb
> LP ring tail: a0 head: 94 len: f001 start 2ac000
> eir: 0 esr: 1 emr: 3d
> instdone: ff7a instpm: 0
> memmode: 4 instps: 10
> hwstam: 9ac7 ier: 0 imr: 9ac7 iir: 0
>
> Fatal server error:
> Active ring not flushed
>
> dmesg has this to say:
> [drm] Initialized i810 1.2.1 20020211 on minor 0
>
>  mtrr: base(0xf800) is not aligned on a size(0x12c000) boundary
>
>   PCI: Found IRQ 11 for device 00:02.0
>
>[drm:i810_wait_ring] *ERROR* space: 65508 wanted 65528
>
> [drm:i810_wait_ring] *ERROR* lockup
>
> I had set the library path to pick up the newer version of the GL libs..
>
> Dave.
>
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
> pam_smb / Linux DecStation / Linux VAX / ILUG person
>
>
>
>
>
>
> ---
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person





---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] problems with CVS head and i810

2002-12-12 Thread Dave Airlie

Well I built the CVS tree head and made the i810 modules and ran my test
opengl program on it and it worked the first time then started spewing
errors ala

(II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x
pgetbl_ctl: 0x7e40001 pgetbl_err: 0x0
ipeir: 0 iphdr: c2fb
LP ring tail: a0 head: 94 len: f001 start 2ac000
eir: 0 esr: 1 emr: 3d
instdone: ff7a instpm: 0
memmode: 4 instps: 10
hwstam: 9ac7 ier: 0 imr: 9ac7 iir: 0

Fatal server error:
Active ring not flushed

dmesg has this to say:
[drm] Initialized i810 1.2.1 20020211 on minor 0  
 mtrr: base(0xf800) is not aligned on a size(0x12c000) boundary   
  PCI: Found IRQ 11 for device 00:02.0
   [drm:i810_wait_ring] *ERROR* space: 65508 wanted 65528 
[drm:i810_wait_ring] *ERROR* lockup

I had set the library path to pick up the newer version of the GL libs..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person






---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Philip Brown
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> ...
> It takes two to tango so its not just what I need its also what do they
> need.
> 
> What I would like to see would be:
> 
> A single definitive source for the DRM code, one where contributions go
> back from Linux, from *BSD, from core XFree86 as well as from the DRI
> project.


May I suggest that the best way to do that, is to keep the kernel DRM code,
as a **SEPARATE PROJECT**, at least on the source code repository level.

IMO, there should be a separate repository, or at least a separate
directory at the same level as the top-level "xc".

The only thing from the driver that really belongs buried in the xfree86
server code, is a single, os-neutral copy of "drm.h", from whatever version
of DRM that branch of xfree86 is officially supporting.


Once you have achieved that separation, you have something actually
resembling a formal API between user-level and kernel driver level.
That is the only way things are going to get cleaned up, process-wise.
Not to mention greatly aiding kernel coding efforts for non-linux
platforms.




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: Floating point exception

2002-12-12 Thread Michel Dänzer
On Don, 2002-12-12 at 21:55, dax wood wrote:

>   (WW) R128(0): Can't determine panel dimensions, and none
> specified.
>  Disabling programming of FP registers.
>:::
>   honestly i think this bug is in the r128 implementation of Mesa
> 5.0

That message is from the r128 2D driver and has nothing to do with Mesa.


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Enabled in xfree log, but not in glxinfo

2002-12-12 Thread marc . poulhies


Hi!
I've just reinstalled my system and tried to use dri with my radeon 8500. I've
my module and drivers (from the debian package, thanks M.Danzer) but i can't
figure why it's not working. Xfree logs' say that Direct Rendering is enabled,
but glxinfo says the oposite.
Is it a bug or do i have something wrong...?
Thanks

-
This mail sent through IMP: http://horde.org/imp/



XFree86.0.log
Description: Binary data


glxinfo
Description: Binary data


[Dri-devel] Re: bugreport: http://people.debian.org/~daenzer/dri-mach64/

2002-12-12 Thread Michel Dänzer
On Don, 2002-12-12 at 19:23, Vladimir Wiedermann wrote:
> 
> I'm send this email to both adresses, because i don't know, if problem is
> in package or DRI ..
> 
> I have Debian Unstable and ATI (rage pro) Mobility graphics card.
> I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page
> in subject, made .deb by make-kpkg and installed it.
> 
> Problem is, that KDM don't want to run anymore. I see, that X server
> started, but then it restarted.
> (see attached files)
> 
> I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1.
> 
> Funny is, that when I put startx, it works well (except that I change
> to console before kde is fully loaded)

See /usr/share/doc/xserver-xfree86-dri-mach64/README.Debian .


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] bugreport: http://people.debian.org/~daenzer/dri-mach64/

2002-12-12 Thread Leif Delgass
This probably won't help with kdm, but did you also install the xlibmesa* 
packages?  I think those contain the mach64 Mesa driver (mach64_dri.so) 
among other things, that you'll need to use DRI.

On Thu, 12 Dec 2002, Vladimir Wiedermann wrote:

> hi,
> 
> I'm send this email to both adresses, because i don't know, if problem is
> in package or DRI ..
> 
> I have Debian Unstable and ATI (rage pro) Mobility graphics card.
> I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page
> in subject, made .deb by make-kpkg and installed it.
> 
> Problem is, that KDM don't want to run anymore. I see, that X server
> started, but then it restarted.
> (see attached files)
> 
> I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and
> XFree86Server 4.2.1.
> 
> Funny is, that when I put startx, it works well (except that I change
> to console before kde is fully loaded)
> 
> so please help if you can..
> 
> 

-- 
Leif Delgass 
http://www.retinalburn.net




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] vblank and i810

2002-12-12 Thread Dave Airlie

Well I asked a question on dri-users and Keith said I'd be better asking
here ..

I want to get my OpenGL application to stop flickering on my i815 using a
sync to the vertical refresh, work has apparently started on this for the
radeon and g400, so,

a) does someone intend working on the i810 driver?
b) if !a, where do I start to work on this, I have a development system
sitting here waiting :-), and I've no fear of X or kernels,

Do I need a particular branch of the dri CVS tree or will the HEAD do fine?
Do I need an updated X11/GL to support the new IOCTL? (am running XFree86
4.2.0)
Can I avoid downloading/building the Xserver, just grab the DRI stuff?

Will this be in 4.3 (I have to do a product and a stable release looks
better to management!).

Thanks,
Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person






---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Martin Spott
>> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
>> constraints and stability concerns. [...]

> I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
> chose for XFree86-4.3,

I'd like to add to my own posting that the branch that you consider for
inclusion into XFree86-4.3 definitely looks worse than the Mesa-5.x based
stuff - at least from the user perspective.

If anyone cares I'll create a few screenshots with FlightGear to lay out
the difference I mean,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Segfault in DRI Xserver extension

2002-12-12 Thread Keith Whitwell
Felix Kühling wrote:

Hi,

while I was messing around with my query programme I found this: if I
specify an invalid screen as argument to XF86DRIGetClientDriverName the
Xserver segfaults. I had a quick look at xc/xc/Xserver/GL/dri/xf86dri.c.
stuff->screen is used as array index without checking. I'm not sure
though, where would be the right place to fix it.

Other functions in xf86dri.c must be affacted, too. They use
stuff->screen in the same way.


Those functions should validate any information they receive over the wire, as 
soon as is feasible.

Keith




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Querying DRI Client drivers

2002-12-12 Thread Keith Whitwell
Felix Kühling wrote:

Hi,

referring to our discussion on IRC on monday about querying client
driver configuration options I made a small programme which just reads
the client driver names of all screens. It's pretty simple actually. No
need for any GLX initialization at all. The source is attached. Compile
like this:


Nice, though I think you should check for the XF86DRI extension somehow first?

This is probably only the second ever use of that extension...

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Version handshake problems?

2002-12-12 Thread Carlos O'Donell
> > /proc/dri shows 0, 1 and 2.
> > 0 -> tdfx 0xe200 (The Matrox)
> > 1 -> radeon 0xe201 PCI:1:0:0 (Radeon 7500 QW AGP)
> > 2 -> radeon 0xe202 (Radeon, the VGA interface?)
> 
> No, the radeon DRM actually only registers a single instance.
> 
> This had me very stumped, but someone else reported it before, and it
> turned out to be the DRM already built into the kernel. Do I get the
> prize now? :)
> 

You win. tdfx and radeon were built _into_ the kernel.
/me modifies build script to vapourize old .config that snuck in the back window

c.



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Version handshake problems?

2002-12-12 Thread Carlos O'Donell
> >> /proc/dri shows 0, 1 and 2.
> >> 
> >> 0 -> tdfx 0xe200 (The Matrox)
>  ^^
> tdfx == 3Dfx Voodoo 3/4/5 or banshee, it is not Matrox
> 

I wish I had one installed :)

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II]
00:0e.0 Ethernet controller: Winbond Electronics Corp W89C940
00:0f.0 Multimedia audio controller: Aureal Semiconductor Vortex 2 (rev fe)
00:10.0 Ethernet controller: 3Com Corporation 3c590 10BaseT [Vortex]
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon 7500 QW

I have no idea why it's in /proc/dri/0*

c.
 


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Segfault in DRI Xserver extension

2002-12-12 Thread Felix Kühling
Hi,

while I was messing around with my query programme I found this: if I
specify an invalid screen as argument to XF86DRIGetClientDriverName the
Xserver segfaults. I had a quick look at xc/xc/Xserver/GL/dri/xf86dri.c.
stuff->screen is used as array index without checking. I'm not sure
though, where would be the right place to fix it.

Other functions in xf86dri.c must be affacted, too. They use
stuff->screen in the same way.

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:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Querying DRI Client drivers

2002-12-12 Thread Felix Kühling
Hi,

referring to our discussion on IRC on monday about querying client
driver configuration options I made a small programme which just reads
the client driver names of all screens. It's pretty simple actually. No
need for any GLX initialization at all. The source is attached. Compile
like this:

cc -I$dritrunk/xc/xc/lib/GL/dri 
-I$dritrunk/xc/xc/programs/Xserver/hw/xfree86/os-support -lX11 -lXext detectdrv.c 
$dritrunk/xc/xc/lib/GL/dri/XF86dri.o -o detectdrv

Regards,
   Felix

   __\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
  [EMAIL PROTECTED]>o<__/   \___/   \___/at the same time!

#include 
#include 
#include 

int main () {
Display *display;
int major, minor, patch, screenCount, i;
Bool capable;
char *driver;

if (!(display = XOpenDisplay (NULL))) {
	fprintf (stderr, "Error: Couldn't open display\n");
	return 1;
}

screenCount = ScreenCount (display);
printf ("ScreenCount=%d\n", screenCount);
for (i = 0; i < screenCount; ++i) {
	if (!XF86DRIQueryDirectRenderingCapable(display, i, &capable))
	fprintf (stderr, "DRI call failed\n");
	else if (!capable) {
	printf ("Screen %d: not direct rendering capable\n");
	continue;
	}
	if (!XF86DRIGetClientDriverName (display, i, &major, &minor, &patch, &driver))
	fprintf (stderr, "DRI call failed\n");
	else
	printf ("Screen %d: %s %d.%d-%d\n", i, driver, major, minor, patch);
}

XCloseDisplay (display);
}



Re: [Dri-devel] Re: Floating point exception

2002-12-12 Thread dax wood
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 11, 2002 at 09:34:23AM -0800, dax wood wrote:
> > the CPU i got is
> > vendor_id   : GenuineIntel
> > cpu family  : 6
> > model   : 8
> > model name  : Pentium III (Coppermine)
> > stepping: 3
> > cpu MHz : 701.601
> > cache size  : 256 KB
> > 
> > The ENV var 'MESA_NO_SSE' has no effect at all. I
> > Recompiled the cvs this time with 
> > #define MesaUseKatmai YES 
> 
> To make any difference, you'd have to change it to NO.
> 
> > commented out and yet still recieve "Floating point
> > exception" a notable mention thought when dri is
> > disabled I am able to run all opengl programs
> > (slowly).
> > the odd thing is that I cant find the error
> > msg Floating point exception in any of the sources. Is
> > this in kernel?
> 
> What version of GCC are you using?  If you're using 3.2.x, try adding
> '-mno-sse -mno-mmx -mno-3dnow' to DefaultGcc2i386Opt in host.def and
> make
> World.
ok, (but)
  first:   I'm using gcc 2.95.3 (due to the new C++ mod's in 3.2.x)
  second:  I got frustrated and went to XFree86 CVS as of 12/11/2002
  and installed so that i can have a working base for my
test.
   (All's well sort of) ---using Mesa 4.0.4
  when X initializes I get this warning
  (WW) R128(0): Can't determine panel dimensions, and none
specified.
 Disabling programming of FP registers.
   :::
  honestly i think this bug is in the r128 implementation of Mesa
5.0
  any thoughts?
-dax

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Cox
On Thu, 2002-12-12 at 19:00, Keith Whitwell wrote:
> I've been looking at what's in 2.4 and it's quite divergent from what we've 
> got on the trunk.  It is pretty closely related to the xfree 4.2 code, though, 
> and most of the changes seem to be in the 2.4 code.
> 
> Are you proposing pulling the dri trunk code into 2.4?

I dont have time to look at this before christmas but if no one else has
done it I'll try and get a set of patches/explanations to feed the 4.2.x
DRM changes back at least to the 4.2 branch of DRM



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: Floating point exception

2002-12-12 Thread Mike A. Harris
On Thu, 12 Dec 2002, Ian Romanick wrote:

>Date: Thu, 12 Dec 2002 11:26:34 -0800
>From: Ian Romanick <[EMAIL PROTECTED]>
>To: DRI developer's list <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=us-ascii
>List-Id: 
>Subject: Re: [Dri-devel] Re: Floating point exception
>
>On Wed, Dec 11, 2002 at 09:34:23AM -0800, dax wood wrote:
>> the CPU i got is
>> vendor_id   : GenuineIntel
>> cpu family  : 6
>> model   : 8
>> model name  : Pentium III (Coppermine)
>> stepping: 3
>> cpu MHz : 701.601
>> cache size  : 256 KB
>> 
>>  The ENV var 'MESA_NO_SSE' has no effect at all. I
>> Recompiled the cvs this time with 
>> #define MesaUseKatmai YES 
>
>To make any difference, you'd have to change it to NO.

Just a quick note..  If anyone is using XFree86 CVS trunk, 
you should note that the Imake defines have had a s/Katmai/SSE/
done on them.  Backward compat with Katmai is present however, so 
using HasKatmai should still work, although it is deprecated.

Just thought I'd mention that.

-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Mike A. Harris
On Thu, 12 Dec 2002, Keith Whitwell wrote:

>> Right now for 2.4 I'm juggling too many conflicting balls, if its all in
>> the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and
>> since I can do it item by item as it changes its also easy to know when
>> something bad happens.
>
>I've been looking at what's in 2.4 and it's quite divergent from what we've 
>got on the trunk.  It is pretty closely related to the xfree 4.2 code, though, 
>and most of the changes seem to be in the 2.4 code.
>
>Are you proposing pulling the dri trunk code into 2.4?

Is the DRI trunk compatible with XFree86 4.1.0, 4.2.0, 4.2.1, and 
current CVS XFree86?  If so, and it is considered stable, which 
is what I presume by it being considered for 2.4.x integration, 
then it makes sense to me to do so.

Backward compatibility with releases back at least as far as 
4.1.0 is critically important though.


-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread D. Hageman
On Thu, 12 Dec 2002, Mike A. Harris wrote:

> On Thu, 12 Dec 2002, Alan Hourihane wrote:
> 
> >> > > The ability to track changes to that with reasons so that we can keep a
> >> > > stable DRM and also the 'DRM of the day' visible to the kernel people -
> >> > > perhaps the devel kernel tree having an option for "Development DRM
> >> > > (XFree86 4.4) (Y/M/N)".
> >> >  
> >> > For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> >> > that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> >> 
> >> Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them
> >> for things pci_alloc_consistent ?
> >
> >No, nor does 4.2.1.
> 
> Should anyone be using XFree86 CVS stable branch DRM nor trunk
> DRM then?  I presume if bugfixes are not going into XFree86 CVS 
> stable branches, that the DRM in there is snapshoted and then 
> throwaway.

This is pretty much what my claim was the other day when we were talking 
on IRC ... one needs to see the DRI stuff moved into the XFree86 CVS tree 
on a regular basis to see any decent results.  This is why I take the time 
to merge in the DRI stuff everytime I build new RPMs to test XFree86 code.  
Changes to the XFree86 code proper seems to not be getting moved over as 
quickly as it should.  If we want to take a recent example - we can use 
the xf86strncat symbol missing out of the loader code.  The issue was 
first noticed in the DRI tree, but the change didn't get put into the 
XFree86 tree until about two weeks later ... and then it was just because 
I happened to make an off hand comment about it on the xfree86-devel list.  

I checked the vendor and what not tags on the RPMs I built for myself and 
you are correct that they are undefined.  I really like that new version 
of RPM.  It does nice things [tm].

-- 
//\\
||  D. Hageman<[EMAIL PROTECTED]>  ||
\\//


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Re: Floating point exception

2002-12-12 Thread Ian Romanick
On Wed, Dec 11, 2002 at 09:34:23AM -0800, dax wood wrote:
> the CPU i got is
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 8
> model name  : Pentium III (Coppermine)
> stepping: 3
> cpu MHz : 701.601
> cache size  : 256 KB
> 
>   The ENV var 'MESA_NO_SSE' has no effect at all. I
> Recompiled the cvs this time with 
> #define MesaUseKatmai YES 

To make any difference, you'd have to change it to NO.

>   commented out and yet still recieve "Floating point
> exception" a notable mention thought when dri is
> disabled I am able to run all opengl programs
> (slowly).
> the odd thing is that I cant find the error
> msg Floating point exception in any of the sources. Is
> this in kernel?

What version of GCC are you using?  If you're using 3.2.x, try adding
'-mno-sse -mno-mmx -mno-3dnow' to DefaultGcc2i386Opt in host.def and make
World.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Mike A. Harris
On Thu, 12 Dec 2002, Alan Hourihane wrote:

>> > > The ability to track changes to that with reasons so that we can keep a
>> > > stable DRM and also the 'DRM of the day' visible to the kernel people -
>> > > perhaps the devel kernel tree having an option for "Development DRM
>> > > (XFree86 4.4) (Y/M/N)".
>> >  
>> > For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
>> > that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
>> 
>> Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them
>> for things pci_alloc_consistent ?
>
>No, nor does 4.2.1.

Should anyone be using XFree86 CVS stable branch DRM nor trunk
DRM then?  I presume if bugfixes are not going into XFree86 CVS 
stable branches, that the DRM in there is snapshoted and then 
throwaway.

Where should we be getting DRM from for our kernel, and where 
should we be sending bug fixes for DRM to?

I'd like to have one single location, be it kernel.org, DRI-CVS,
or XFree86.org to both get DRM from, and send in bugfixes for.  
I have been getting it from XFree86 CVS in the past, generally
right after a merge, or when I spot drm changes in cvs-commits.

Right now however, for both Red Hat kernels, and kernel.org
kernels there is up to 2 levels of indirection between the
kernel.org kernel updates and the DRM upstream source, and it 
seems also that many bugfixes also go through 2 or more levels of 
indirection.

Where should all DRM bug fixes be sent? Right now if I've got a 
DRM bugfix hypothetically, I've got to send it to Arjan for 
inclusion in our kernel, then Alan or Marcelo for inclusion in 
the kernel.org kernel, and should probably have it sent to 
linux-kernel so other vendors are aware of it also, 
then dri-devel to make DRI developers aware of it for inclusion 
into DRI CVS too, as I understand nobody follows linux-kernel, 
and also to XFree86's patch queue.

It's impossible to track all of that, and to track wether or not
a given patch has actually been accepted in all of those
locations and is applied or not.  It's possible that one group of 
people may not apply the patch until it is accepted by group B or 
C, and that the submitter may be expected to monitor group B to 
see if they accept and apply it, and then again notify group A, C 
and D that the patch is applied, please apply it to your set too.

As the number of patches goes up, and the number of releases of 
the kernel, XFree86, our distro, etc. it is impossible to keep 
track of it all.

What I would like to see, is the DRI project, the XFree86 
project, the Linux kernel folk all agree to one single 
unmistakeable official location for acquiring the 
current official "stable" kernel DRM source, and one 
single official location for submitting bug fixes, and then 
either:

1) That one location is responsible for pushing the fix out to
   whatever other places they feel are necessary or warranted.

or

2) The various projects all pull the fixes in themselves from the 
   one single central 'official' location, and if sent a fix from 
   someone randomly, they automatically forward it on to the
   official location and not just apply it locally to their tree.
   That could be DRI-CVS, XFree86 CVS, or kernel.org.

Also, it'd be prefered if that one "official" location would 
release versioned tarballs of the official DRM release, which 
would then be easier for people to manage what changed between 
different versions than tracking a given CVS head which may 
possibly become unstable at some times, etc.

Right now, as it stands, I often get bug reports of DRI lockups
and problems in our bugzilla, which upon deeper investigation 
turns out to be someone using a kernel.org kernel instead of our 
supplied kernel, and the DRM isn't new enough, or contains bugs 
that our kernel does not, and that DRI-CVS or XFree86 might not.

We need...

One DRM to rule them all,
One developer to find them,
One DRM to bring them all,
And in the darkness find them.



Yes, that was a lame attempt at humor.

Seriously though, having 50 frayed trees of the same source code 
benefits nobody really, especially if various people consider 
different trees as authoritative/stable/official/whatever.

As long as XFree86 / DRI Project / kernel.org each have their own 
DRM code, people will pull DRM from one of the three locations, 
and people will send bug reports, fixes, etc. to 3 locations.  If 
each of those locations refuse to send patches on to the other 
locations, and expect the submitter to do it, the whole thing 
breaks down.

What solutions do people think would be appropriate?



-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_

Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Charl P. Botha
On Thu, Dec 12, 2002 at 11:43:03AM -0700, Brian Paul wrote:
> Michel Dänzer wrote:
> >On Don, 2002-12-12 at 15:29, Martin Spott wrote:
> >
> >>>XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> >>>constraints and stability concerns. [...]
> >>
> >>I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
> >>chose for XFree86-4.3,
> >
> >
> >I'd mostly agree, but I guess the floating point exceptions are
> >showstoppers.
> 
> It's still not clear what the cause of this is. I've heard two
> possibilities:
> 
> 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with
> a command line switch.
> 
> 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow
> support.  This was fixed in the Mesa/src/X86/common_x86_asm.S file last
> month.

Neither of these explain the sigfpe that Andreas Stenglein and I have been
experiencing.  Both of us have been building with gcc 2.95: this eliminates
1.  In addition, I have confirmed that I've been running the fixed code:
this eliminates 2.

See (a.o.) the mail with subject:
Re: [Dri-devel] Re: Radeon: lockup on state change

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell


How would you ideally see this working?



Mostly I want to know how to make sure changes "stick" once they are
made and deemed or shown to work. If the Linux fixes get back into the
DRM CVS, then the only other bit is knowing when the DRM CVS has
changed. That sounds like a procmail filter on the commit notify list
for DRI if there is one set up.


dri-patches on sourceforge.net.


Right now for 2.4 I'm juggling too many conflicting balls, if its all in
the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and
since I can do it item by item as it changes its also easy to know when
something bad happens.


I've been looking at what's in 2.4 and it's quite divergent from what we've 
got on the trunk.  It is pretty closely related to the xfree 4.2 code, though, 
and most of the changes seem to be in the 2.4 code.

Are you proposing pulling the dri trunk code into 2.4?

Keith






---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Dri-devel] Radeon DRI resume - submission to XFree86 CVS

2002-12-12 Thread Charl P. Botha
As discussed in the mail below, herewith a submission of the Radeon DRI
suspend/resume patch for your review.  I've updated it to and tested it with
current XFree86 CVS.

FYI, this patch enables complete suspend to/resume from disk with Radeon
chipsets with active DRI (and also running 3D-accelerated and Xv clients).
More information is available at http://cpbotha.net/dri_resume.html

Thanks,
Charl

- Forwarded message from David Dawes <[EMAIL PROTECTED]> -

From: David Dawes <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Radeon DRI Resume - quo vadis?
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
List-Help: 
List-Post: 
List-Subscribe: ,

List-Id: 
List-Unsubscribe: ,

List-Archive: 
X-Original-Date: Tue, 10 Dec 2002 21:09:27 -0500
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK 
version=2.20
X-Spam-Level: 
X-Keywords: 
X-UID: 363

On Tue, Dec 10, 2002 at 01:45:09PM +0100, Charl P. Botha wrote:
>On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote:
>> One thing though. It doesn't look like it's hooked to any APM events.
>> 
>> It's just run generically everytime on ModeInit. What happens when you
>> VT switch - does it handle them cases too ?
>
>At the moment it's called from RADEONEnterVT() in radeon_driver.c - so
>the code is called after every VT switch.  During normal operation this
>doesn't cause any problems as it's idempotent.  I would prefer hooking
>it more specifically to a power event... however, last time I checked
>the infrastructure for non-APM power events didn't seem to be ready. 
>Many people are using this on ACPI-only laptops with swsusp for software
>suspension.

If you're restoring HW state required for the correct operation of the
driver, and especially if it's state that something else driving the
video card might change while the X server doesn't have control over
it, then it should be done from EnterVT().  As a general rule, any HW
state that's set in ScreenInit() should also be set in EnterVT().

By default, XFree86 handles APM events via EnterVT/LeaveVT.  It's possible
for a driver to provide a separate function to handle PM events, but in
most cases it shouldn't be needed.

I just had another look at your patch, and I didn't see any obvious
problem with the way it's structured.  Send it to [EMAIL PROTECTED],
and Kevin Martin can review it.

David
--
David Dawes
Release Engineer/Architect  The XFree86 Project
www.XFree86.org/~dawes

- End forwarded message -

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/

Index: drivers/ati/radeon.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h,v
retrieving revision 1.32
diff -u -r1.32 radeon.h
--- drivers/ati/radeon.h2002/10/31 18:06:59 1.32
+++ drivers/ati/radeon.h2002/12/12 18:45:10
@@ -566,12 +566,15 @@
 extern int RADEONMinBits(int val);
 
 extern voidRADEONInitVideo(ScreenPtr pScreen);
-
+/* added by [EMAIL PROTECTED] so that we can call this function from
+ * radeon_driver.c to get xvideo working after a resume from disc/ram */
+extern voidRADEONResetVideo(ScrnInfoPtr pScrn);
 extern voidR300CGWorkaround(ScrnInfoPtr pScrn);
 
 #ifdef XF86DRI
 extern BoolRADEONDRIScreenInit(ScreenPtr pScreen);
 extern voidRADEONDRICloseScreen(ScreenPtr pScreen);
+extern voidRADEONDRIResume(ScreenPtr pScreen);
 extern BoolRADEONDRIFinishScreenInit(ScreenPtr pScreen);
 
 extern drmBufPtr   RADEONCPGetBuffer(ScrnInfoPtr pScrn);
Index: drivers/ati/radeon_common.h
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h,v
retrieving revision 1.1
diff -u -r1.1 radeon_common.h
--- drivers/ati/radeon_common.h 2002/10/30 12:52:13 1.1
+++ drivers/ati/radeon_common.h 2002/12/12 18:45:10
@@ -70,6 +70,7 @@
 #define DRM_RADEON_INIT_HEAP  0x15
 #define DRM_RADEON_IRQ_EMIT   0x16
 #define DRM_RADEON_IRQ_WAIT   0x17
+#define DRM_RADEON_CP_RESUME  0x18
 #define DRM_RADEON_MAX_DRM_COMMAND_INDEX  0x39
 
 
Index: drivers/ati/radeon_dri.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.22
diff -u -r1.22 radeon_dri.c
--- drivers/ati/radeon_dri.c2002/11/25 14:04:57 1.22
+++ drivers/ati/radeon_dri.c2002/12/12 18:45:10
@@ -1559,6 +1559,86 @@
 return TRUE;
 }
 
+/**
+ * Th

Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Cox
On Thu, 2002-12-12 at 12:49, Keith Whitwell wrote:
> > A single definitive source for the DRM code, one where contributions go
> > back from Linux, from *BSD, from core XFree86 as well as from the DRI
> > project.
> 
> My feeling is that the dri cvs should be that place.  What workable 
> alternatives exist?

That seems right.

> It seems that changes get inserted to the drm code in the kernel from time to 
> time.  Is the expectation that we monitor the kernel drm and periodically 
> merge (or otherwise) those random or worthy changes back to this repository? 
> I personally don't want to subscribe to lkml or attempt to fully monitory the 
> traffic there.

Thats why I said its not just about what we need. Ok so DRI CVS is
definitive and has branches for 4.2.0/4.2.1/devel. So if I make sure all
the Linux changes to 2.4.x DRM get channeled back to this list they can
get reviewed and merged back and we are all happy.

Thats trivial for me to do since I'm already seeing each patch that
touches that area.

> We've been very lucky in that Linus has been pulling changes into 2.5 and 
> providing some useful feedback when things go wrong.  I don't know how 
> sustainable this is though - I think we're probably taking up more of his time 
> than we should be.
> 
> How would you ideally see this working?

Mostly I want to know how to make sure changes "stick" once they are
made and deemed or shown to work. If the Linux fixes get back into the
DRM CVS, then the only other bit is knowing when the DRM CVS has
changed. That sounds like a procmail filter on the commit notify list
for DRI if there is one set up.

Right now for 2.4 I'm juggling too many conflicting balls, if its all in
the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and
since I can do it item by item as it changes its also easy to know when
something bad happens.

Alan



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Keith Whitwell
Brian Paul wrote:

Michel Dänzer wrote:


On Don, 2002-12-12 at 15:29, Martin Spott wrote:


XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
constraints and stability concerns. [...]



I didn't notice the Mesa-5.x-based stuff is less stable than the 
stuff you
chose for XFree86-4.3,



I'd mostly agree, but I guess the floating point exceptions are
showstoppers.



It's still not clear what the cause of this is. I've heard two
possibilities:

1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with
a command line switch.

2. A bogus test in Mesa determines that newer P4 processors have 3Dnow
support.  This was fixed in the Mesa/src/X86/common_x86_asm.S file last
month.


Neither of these seems to explain what's happening.

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Mike A. Harris
On 12 Dec 2002, Alan Cox wrote:

>Date: 12 Dec 2002 18:22:10 +
>From: Alan Cox <[EMAIL PROTECTED]>
>To: Alan Hourihane <[EMAIL PROTECTED]>
>Cc: D. Hageman <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Content-Type: text/plain
>List-Id: 
>Subject: Re: [Dri-devel] DRM Kernel Questions
>
>On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote:
>> > The ability to track changes to that with reasons so that we can keep a
>> > stable DRM and also the 'DRM of the day' visible to the kernel people -
>> > perhaps the devel kernel tree having an option for "Development DRM
>> > (XFree86 4.4) (Y/M/N)".
>>  
>> For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
>> that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
>
>Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them
>for things pci_alloc_consistent ?

I don't know the answer to that, but it brought up a thought in 
my mind.  DRM is supposed to be backward compatible currently as 
far back as 4.1.0.  It would make the most sense to me then, to 
check all DRM changes into xf-4_2-branch, and xf-4_1-branch as 
soon as they're known to be stable and correct.  This ensures 
that DRM is updated in all releases.

The alternative is having people get a given X release, and then 
use the DRM from the most recent X release.  Or should they be 
getting it from DRI-CVS instead?  Or from kernel.org?

A lot of confusion in DRMland...

-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Brian Paul
Michel Dänzer wrote:

On Don, 2002-12-12 at 15:29, Martin Spott wrote:


XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
constraints and stability concerns. [...]


I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
chose for XFree86-4.3,



I'd mostly agree, but I guess the floating point exceptions are
showstoppers.


It's still not clear what the cause of this is. I've heard two
possibilities:

1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with
a command line switch.

2. A bogus test in Mesa determines that newer P4 processors have 3Dnow
support.  This was fixed in the Mesa/src/X86/common_x86_asm.S file last
month.

-Brian




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] bugreport: http://people.debian.org/~daenzer/dri-mach64/

2002-12-12 Thread Vladimir Wiedermann
hi,

I'm send this email to both adresses, because i don't know, if problem is
in package or DRI ..

I have Debian Unstable and ATI (rage pro) Mobility graphics card.
I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page
in subject, made .deb by make-kpkg and installed it.

Problem is, that KDM don't want to run anymore. I see, that X server
started, but then it restarted.
(see attached files)

I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1.

Funny is, that when I put startx, it works well (except that I change
to console before kde is fully loaded)

so please help if you can..

-- 
Vladimir Wiedermann



log.tgz
Description: GNU Unix tar archive


Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Mike A. Harris
On Thu, 12 Dec 2002, D. Hageman wrote:

>In all honesty ... I haven't run to any issues with the Mesa 5.x based 
>stuff.  Remember - I also take the time to merge the current DRI code back 
>into the the XFree86 CVS repository before I build a release.  I picked up 
>a copy of Wolfenstein a week or so back just so I could stress test things 
>and so far I have had no issues with it.  It works great!
>
>As a side note ... the code that I compile is bundled into RPMS based off 
>of Mike Harris' devel XFree86 RPMS.  I am willing to allow other people to 
>use them to test code, but  they need to realize that they shouldn't 
>bug RedHat or Mike Harris about issues they find in them!  Since I am the 
>only one using them, I usually don't change the name of the packager or 
>distributer ... I guess if anyone is really interested in these RPMS I 
>could go back and do that.

Distribution: and Packager: fields are filled in by rpm during 
building, and default to nothing.  If you query your rpm packages 
that you've built, they should show nothing for those 2 fields 
unless you've customized the rpm configuration to specify 
something in those fields.  Just thought I'd mention that.

My CVS XFree86 RPMs are also always avail at the URL in my sig 
for updating from, or for those who want to use them.

HTH



-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 06:22:10PM +, Alan Cox wrote:
> On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote:
> > > The ability to track changes to that with reasons so that we can keep a
> > > stable DRM and also the 'DRM of the day' visible to the kernel people -
> > > perhaps the devel kernel tree having an option for "Development DRM
> > > (XFree86 4.4) (Y/M/N)".
> >  
> > For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> > that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> 
> Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them
> for things pci_alloc_consistent ?

No, nor does 4.2.1.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Cox
On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote:
> > The ability to track changes to that with reasons so that we can keep a
> > stable DRM and also the 'DRM of the day' visible to the kernel people -
> > perhaps the devel kernel tree having an option for "Development DRM
> > (XFree86 4.4) (Y/M/N)".
>  
> For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.

Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them
for things pci_alloc_consistent ?




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Version handshake problems?

2002-12-12 Thread Mike A. Harris
On 12 Dec 2002, Michel Dänzer wrote:

>> /proc/dri shows 0, 1 and 2.
>> 
>> 0 -> tdfx 0xe200 (The Matrox)
 ^^
tdfx == 3Dfx Voodoo 3/4/5 or banshee, it is not Matrox




-- 
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 11:11:13AM -0600, D. Hageman wrote:
> On Thu, 12 Dec 2002, Alan Hourihane wrote:
> > For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> > that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> 
> I admit that your logic is sound, but answer me this:  Does one send the 
> changes back on the stable to the XFree86 team proper or to the DRI team?  
> The two group devel model gets kinda unwieldy at this point.   Right now 
> most vendors have to track the individual patches to XFree86 and DRI in 
> between releases ... and they kinda push the changes back into the code 
> base where they belong when they can.

I'd send stability changes directly to XFree86. Then the changes would go
straight into the stable branch of XFree86. There's a close working relationship
between the two groups anyway and if the XFree86 team want a quick response
from the DRI folks on a patch they've received then that would happen.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread D. Hageman
On Thu, 12 Dec 2002, Alan Hourihane wrote:

> On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> > On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> > > 
> > > Alan,
> > > 
> > > What would you like to see be implemented to help get the job done.  In 
> > > other words, what do you need from the DRI team?
> > 
> > It takes two to tango so its not just what I need its also what do they
> > need.
> > 
> > What I would like to see would be:
> > 
> > A single definitive source for the DRM code, one where contributions go
> > back from Linux, from *BSD, from core XFree86 as well as from the DRI
> > project.

I would love to see this as well.  I am not sure that this two tree CVS 
devel method is the most efficient.  I am sure it was started for good 
reasons, but I think it taxes some time for people like me who try keep 
testing the big picture by running both trees in one.

> > The ability to track changes to that with reasons so that we can keep a
> > stable DRM and also the 'DRM of the day' visible to the kernel people -
> > perhaps the devel kernel tree having an option for "Development DRM
> > (XFree86 4.4) (Y/M/N)".

I like that idea ... essentially two copies of DRM in the kernel tree.  
One that is visible always as it is considered most stable with the 
current release of XFree86 and the running experimental version.  
Admittably the compatibility with modules also depends on what version of 
XFree86 as you noted above - it sure ... complicates things.  I guess at 
some point we have to believe that if you are building your own kernel 
that you are reasonably competent to figure that one out.  Not always the 
case, but unfortunately it is so hard to check the intelligence sitting 
in front of the console with a configuring script. ;-)

> For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.

I admit that your logic is sound, but answer me this:  Does one send the 
changes back on the stable to the XFree86 team proper or to the DRI team?  
The two group devel model gets kinda unwieldy at this point.   Right now 
most vendors have to track the individual patches to XFree86 and DRI in 
between releases ... and they kinda push the changes back into the code 
base where they belong when they can.

Surely we can thing of a better way to do the tango to help everyone out 
...

-- 
//\\
||  D. Hageman<[EMAIL PROTECTED]>  ||
\\//


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread D. Hageman

In all honesty ... I haven't run to any issues with the Mesa 5.x based 
stuff.  Remember - I also take the time to merge the current DRI code back 
into the the XFree86 CVS repository before I build a release.  I picked up 
a copy of Wolfenstein a week or so back just so I could stress test things 
and so far I have had no issues with it.  It works great!

As a side note ... the code that I compile is bundled into RPMS based off 
of Mike Harris' devel XFree86 RPMS.  I am willing to allow other people to 
use them to test code, but  they need to realize that they shouldn't 
bug RedHat or Mike Harris about issues they find in them!  Since I am the 
only one using them, I usually don't change the name of the packager or 
distributer ... I guess if anyone is really interested in these RPMS I 
could go back and do that.


On Thu, 12 Dec 2002, Michel Dänzer wrote:

> On Don, 2002-12-12 at 15:29, Martin Spott wrote:
> > > XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> > > constraints and stability concerns. [...]
> > 
> > I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
> > chose for XFree86-4.3,
> 
> I'd mostly agree, but I guess the floating point exceptions are
> showstoppers.
> 
> 
> 

-- 
//\\
||  D. Hageman<[EMAIL PROTECTED]>  ||
\\//


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread David Willmore
> It's either that, or the person who sent Linus the patch should submit
> it here. I think the latter is far more difficult.
> 
> Otherwise we (as in someone on the DRI lists - not necessarily a committer to
> the project) are going to have to track the 2.5.x series and 2.4.x series
> for stable and development DRM modules now.
> 
> Alan.

Is the dri-devel mailing list set as the Maintainer of the drm code?  That's
the normal method for communicating to submitters when they need to pipe
changes through.

Cheers,
David


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Version handshake problems?

2002-12-12 Thread Michel Dänzer
On Die, 2002-12-10 at 19:08, Carlos O'Donell wrote: 
> 
> /proc/dri shows 0, 1 and 2.
> 
> 0 -> tdfx 0xe200 (The Matrox)
> 1 -> radeon 0xe201 PCI:1:0:0 (Radeon 7500 QW AGP)
> 2 -> radeon 0xe202 (Radeon, the VGA interface?)

No, the radeon DRM actually only registers a single instance.

This had me very stumped, but someone else reported it before, and it
turned out to be the DRM already built into the kernel. Do I get the
prize now? :)


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell
Alan Hourihane wrote:

On Thu, Dec 12, 2002 at 02:34:23 +, Keith Whitwell wrote:


Dave Jones wrote:


On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:


Some apps only run smooth with 2.5.49+ kernels due to Linus latest 


work. > > Nothing of it in XFree or DRI, yet.


Linus should submit it here for inclusion - simple. I doubt any of us
are tracking 2.5.x that closely at the moment.


I'm surprised Linus finds the time to do the DRI merges he does already.
Pushing stuff back to DRI-devel is going to take up even more of his time,
so this should ideally be done by someone else, preferably someone who
really understands the code.



Yes.  What Linus does is above and beyond what we could/should reasonably 
expect.  Asking him to do more isn't an option.


It's either that, or the person who sent Linus the patch should submit
it here. I think the latter is far more difficult.

Otherwise we (as in someone on the DRI lists - not necessarily a committer to
the project) are going to have to track the 2.5.x series and 2.4.x series
for stable and development DRM modules now.


Well, I've done this for 2.5.51, and the short answer is: there's not a lot of 
difference.

There's been a port of the DMA_IRQ_BH mechanism from tq_struct's to 
work_struct's.  This is a 2.5-only change for a start (no work_struct's in 
2.4, it seems), and additionally only affects the gamma driver (which should 
be binned if nobody takes it up -- it's been a year, I think).

There are some janatorial fixes - one to an #if 0'd region, one to the sis 
driver (which really must be binned!) and one to the i810, which is valid.

And that's it...

Maybe there's more in 2.4.20?

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Jens Owen
Dave Jones wrote:

On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote:
 > It seems that changes get inserted to the drm code in the kernel from time to 
 > time.  Is the expectation that we monitor the kernel drm and periodically 
 > merge (or otherwise) those random or worthy changes back to this repository? 
 > I personally don't want to subscribe to lkml or attempt to fully monitory the 
 > traffic there.

There should at the least be one person on the DRI team who looks at
each new kernel releases with a "Are there any changes here I need to
push into DRI CVS" mindset. This job doesn't need you to even monitor
l-k, just keep an eye on each release Linus does.

Dave,

I expect the changes Linus makes will run with the kernels he releases, 
but my question is, will they work with older kernels, too?  The DRI cvs 
sources need to support those as well?

Supporting DRM under stable and development XFree86 as well as stable 
and development Linux Kernel seems like a large job when your consider 
compatability with older releases (of XFree86 and kernel), the number of 
drivers, and the code being shared with other operating systems.

My point is this may require more of an effort than simply merging 
Linus' changes back into the DRI tree.

--
   /\
 Jens Owen/  \/\ _
  [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 04:20:35 +0100, Dieter Nützel wrote:
> Am Donnerstag, 12. Dezember 2002 15:09 schrieb Alan Hourihane:
> > On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote:
> 
> > > Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like
> > > hell for some apps on my SMP system.
> >
> > Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ?
> > That should be stable. As for your question, have you posted more details
> > on the problem ?
> 
> See "[Dri-devel] radeon.o DRM modules breaks my CD player (!)" thread.

O.k., but that's with the DRI CVS. What does 2.4.20 do with 4.2.1 ? That
should? be stable.

As for the problem, are the DRI trunk's DRM modules more stable with
the DRI CVS than the DRM modules in 2.4.20 ? If so, care to do a little
diffing and try and isolate the problem ?

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 02:34:23 +, Keith Whitwell wrote:
> Dave Jones wrote:
> >On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:
> > > > Some apps only run smooth with 2.5.49+ kernels due to Linus latest 
> > work. > > Nothing of it in XFree or DRI, yet.
> > > Linus should submit it here for inclusion - simple. I doubt any of us
> > > are tracking 2.5.x that closely at the moment.
> >
> >I'm surprised Linus finds the time to do the DRI merges he does already.
> >Pushing stuff back to DRI-devel is going to take up even more of his time,
> >so this should ideally be done by someone else, preferably someone who
> >really understands the code.
> >
> 
> Yes.  What Linus does is above and beyond what we could/should reasonably 
> expect.  Asking him to do more isn't an option.

It's either that, or the person who sent Linus the patch should submit
it here. I think the latter is far more difficult.

Otherwise we (as in someone on the DRI lists - not necessarily a committer to
the project) are going to have to track the 2.5.x series and 2.4.x series
for stable and development DRM modules now.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 03:31:30 +0100, Dave Jones wrote:
> On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:
>  > > Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
>  > > Nothing of it in XFree or DRI, yet.
>  > Linus should submit it here for inclusion - simple. I doubt any of us
>  > are tracking 2.5.x that closely at the moment.
> 
> I'm surprised Linus finds the time to do the DRI merges he does already.
> Pushing stuff back to DRI-devel is going to take up even more of his time,
> so this should ideally be done by someone else, preferably someone who
> really understands the code.

If Linus has already found the time to merge, how long would it be, to
do a diff and send an email off ? I doubt it's that much extra work.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell
Dave Jones wrote:

On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote:
 > It seems that changes get inserted to the drm code in the kernel from time to 
 > time.  Is the expectation that we monitor the kernel drm and periodically 
 > merge (or otherwise) those random or worthy changes back to this repository? 
 > I personally don't want to subscribe to lkml or attempt to fully monitory the 
 > traffic there.

There should at the least be one person on the DRI team who looks at
each new kernel releases with a "Are there any changes here I need to
push into DRI CVS" mindset. This job doesn't need you to even monitor
l-k, just keep an eye on each release Linus does.

I'm running through the differences between dri trunk and 2.5.51 now, with the 
aim of pulling stuff back.  So far nothing huge has jumped out at me.

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Michel Dänzer
On Don, 2002-12-12 at 15:29, Martin Spott wrote:
> > XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> > constraints and stability concerns. [...]
> 
> I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
> chose for XFree86-4.3,

I'd mostly agree, but I guess the floating point exceptions are
showstoppers.


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Dieter Nützel
Am Donnerstag, 12. Dezember 2002 15:09 schrieb Alan Hourihane:
> On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote:

> > Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like
> > hell for some apps on my SMP system.
>
> Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ?
> That should be stable. As for your question, have you posted more details
> on the problem ?

See "[Dri-devel] radeon.o DRM modules breaks my CD player (!)" thread.

-Dieter




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Martin Spott
> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> constraints and stability concerns. [...]

I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you
chose for XFree86-4.3,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell
Dave Jones wrote:

On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:
 > > Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
 > > Nothing of it in XFree or DRI, yet.
 > Linus should submit it here for inclusion - simple. I doubt any of us
 > are tracking 2.5.x that closely at the moment.

I'm surprised Linus finds the time to do the DRI merges he does already.
Pushing stuff back to DRI-devel is going to take up even more of his time,
so this should ideally be done by someone else, preferably someone who
really understands the code.


Yes.  What Linus does is above and beyond what we could/should reasonably 
expect.  Asking him to do more isn't an option.

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] MESA_PBUFFER_ALLOC, alignment

2002-12-12 Thread Brian Paul
Keith Whitwell wrote:

Is there any rational for the 512 byte alignment in this macro?

This is used to allocate main-memory copies of texture images, so the 
numbers add up pretty quickly...

I can't think of any reason to go beyond 16 or at most 32 byte alignment 
from a cpu/caching perspective, and these buffers aren't visible to 
hardware (which can have more stringent requirements).

I think that Gerk found a small performance improvement with a 512-
byte alignment.  But since he provided the macros that are used for
texture allocation he could override whatever default alignment is used.

Feel free to reduce or remove the alignment.

-Brian



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Dave Jones
On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote:
 > > Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
 > > Nothing of it in XFree or DRI, yet.
 > Linus should submit it here for inclusion - simple. I doubt any of us
 > are tracking 2.5.x that closely at the moment.

I'm surprised Linus finds the time to do the DRI merges he does already.
Pushing stuff back to DRI-devel is going to take up even more of his time,
so this should ideally be done by someone else, preferably someone who
really understands the code.

Dave

-- 
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Dave Jones
On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote:
 > It seems that changes get inserted to the drm code in the kernel from time to 
 > time.  Is the expectation that we monitor the kernel drm and periodically 
 > merge (or otherwise) those random or worthy changes back to this repository? 
 > I personally don't want to subscribe to lkml or attempt to fully monitory the 
 > traffic there.

There should at the least be one person on the DRI team who looks at
each new kernel releases with a "Are there any changes here I need to
push into DRI CVS" mindset. This job doesn't need you to even monitor
l-k, just keep an eye on each release Linus does.

Dave

-- 
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Michel Dänzer
On Don, 2002-12-12 at 14:50, Dieter Nützel wrote:

> Look at the "current" kernel (drm) source.
> There are "daily" changes/fixes and we should use the "latest" XFree (DRI) 
> DRM? Currently I'm under the impression that nobody (only a few) of the 
> XFree/DRI developers pay attention about SMP and/or latency where some Linux 
> kernel affords go.
> 
> Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell 
> for some apps on my SMP system.
> 
> Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
> Nothing of it in XFree or DRI, yet.

As Keith pointed out, we can't track all the DRM changes outside of our
tree. We need the people making those changes submitting them to us,
which happens rarely, if ever. I'd appreciate a lot if it did.


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote:
> Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane:
> > On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote:
> > > Alan Hourihane wrote:
> > > >On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> > > >>On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> > > >>>Alan,
> > > >>>
> > > >>>What would you like to see be implemented to help get the job done. 
> > > >>> In other words, what do you need from the DRI team?
> > > >>
> > > >>It takes two to tango so its not just what I need its also what do they
> > > >>need.
> > > >>
> > > >>What I would like to see would be:
> > > >>
> > > >>A single definitive source for the DRM code, one where contributions go
> > > >>back from Linux, from *BSD, from core XFree86 as well as from the DRI
> > > >>project.
> > > >>
> > > >>The ability to track changes to that with reasons so that we can keep a
> > > >>stable DRM and also the 'DRM of the day' visible to the kernel people -
> > > >>perhaps the devel kernel tree having an option for "Development DRM
> > > >>(XFree86 4.4) (Y/M/N)".
> > > >
> > > >For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM
> > > > modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> > >
> > > Or 4.2.x for most recent x?  What about bugs that are found in the
> > > modules after XFree is released?  Or api changes within the kernel?
> >
> > Sorry - yes 4.2.1 or most recent 4.2.x.
> >
> > As for bugs found or api changes they should be submitted back to XFree86
> > so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x
> > release - if there was to be one.
> 
> Sorry, but I think this is much to slow/few.

The speed of updates wasn't the original question, it was where to get
the right stable or development DRM modules.

> Look at the "current" kernel (drm) source.
> There are "daily" changes/fixes and we should use the "latest" XFree (DRI) 
> DRM? Currently I'm under the impression that nobody (only a few) of the 
> XFree/DRI developers pay attention about SMP and/or latency where some Linux 
> kernel affords go.
 
If people decided to upgrade their kernel, they'd already get a later DRM
that should function with the latest XFree86 4.2.x release regardless of
whether the DRI trunk DRM modules have anything to do with it. Thus getting
whatever bug fixes are in the later kernel.

> Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell 
> for some apps on my SMP system.

Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ?
That should be stable. As for your question, have you posted more details
on the problem ?

> Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
> Nothing of it in XFree or DRI, yet.

Linus should submit it here for inclusion - simple. I doubt any of us
are tracking 2.5.x that closely at the moment.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell


Sorry, but I think this is much to slow/few.
Look at the "current" kernel (drm) source.
There are "daily" changes/fixes and we should use the "latest" XFree (DRI) 
DRM? Currently I'm under the impression that nobody (only a few) of the 
XFree/DRI developers pay attention about SMP and/or latency where some Linux 
kernel affords go.


Well, that's the problem that we're addressing -- the changes from different 
people are going to different places, so there's no single good source.

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Mesa/DRI version for XFree86 4.3

2002-12-12 Thread Michel Dänzer
On Don, 2002-12-12 at 03:51, David Dawes wrote:
> XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time
> constraints and stability concerns.  I know that this complicates things
> a little, but I don't see a practical alternative.
> 
> I've created a branch called "mesa-4-0-4-branch" in the DRI CVS, branching
> from the trunk tag (trunk-20021125) that Brian put in before merging
> Mesa 5.0 into the trunk.  If any fixes since then that are independent
> of Mesa 5.0 could be committed to that branch, that should ensure that
> they get picked up for XFree86 4.3.  I'm planning to resync the XFree86
> trunk with that branch sometime this weekend.

Cool, thanks for the heads up. This sounds like our new stable branch
for 4.3?


-- 
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:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Dieter Nützel
Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane:
> On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote:
> > Alan Hourihane wrote:
> > >On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> > >>On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> > >>>Alan,
> > >>>
> > >>>What would you like to see be implemented to help get the job done. 
> > >>> In other words, what do you need from the DRI team?
> > >>
> > >>It takes two to tango so its not just what I need its also what do they
> > >>need.
> > >>
> > >>What I would like to see would be:
> > >>
> > >>A single definitive source for the DRM code, one where contributions go
> > >>back from Linux, from *BSD, from core XFree86 as well as from the DRI
> > >>project.
> > >>
> > >>The ability to track changes to that with reasons so that we can keep a
> > >>stable DRM and also the 'DRM of the day' visible to the kernel people -
> > >>perhaps the devel kernel tree having an option for "Development DRM
> > >>(XFree86 4.4) (Y/M/N)".
> > >
> > >For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM
> > > modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> >
> > Or 4.2.x for most recent x?  What about bugs that are found in the
> > modules after XFree is released?  Or api changes within the kernel?
>
> Sorry - yes 4.2.1 or most recent 4.2.x.
>
> As for bugs found or api changes they should be submitted back to XFree86
> so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x
> release - if there was to be one.

Sorry, but I think this is much to slow/few.
Look at the "current" kernel (drm) source.
There are "daily" changes/fixes and we should use the "latest" XFree (DRI) 
DRM? Currently I'm under the impression that nobody (only a few) of the 
XFree/DRI developers pay attention about SMP and/or latency where some Linux 
kernel affords go.

Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell 
for some apps on my SMP system.

Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. 
Nothing of it in XFree or DRI, yet.

Only some thoughts.

-Dieter


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell
Alan Hourihane wrote:

On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:


On Wed, 2002-12-11 at 22:11, D. Hageman wrote:


Alan,

What would you like to see be implemented to help get the job done.  In 
other words, what do you need from the DRI team?

It takes two to tango so its not just what I need its also what do they
need.

What I would like to see would be:

A single definitive source for the DRM code, one where contributions go
back from Linux, from *BSD, from core XFree86 as well as from the DRI
project.

The ability to track changes to that with reasons so that we can keep a
stable DRM and also the 'DRM of the day' visible to the kernel people -
perhaps the devel kernel tree having an option for "Development DRM
(XFree86 4.4) (Y/M/N)".


 
For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.

Or 4.2.x for most recent x?  What about bugs that are found in the modules 
after XFree is released?  Or api changes within the kernel?

Keith




---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote:
> Alan Hourihane wrote:
> >On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> >
> >>On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> >>
> >>>Alan,
> >>>
> >>>What would you like to see be implemented to help get the job done.  In 
> >>>other words, what do you need from the DRI team?
> >>
> >>It takes two to tango so its not just what I need its also what do they
> >>need.
> >>
> >>What I would like to see would be:
> >>
> >>A single definitive source for the DRM code, one where contributions go
> >>back from Linux, from *BSD, from core XFree86 as well as from the DRI
> >>project.
> >>
> >>The ability to track changes to that with reasons so that we can keep a
> >>stable DRM and also the 'DRM of the day' visible to the kernel people -
> >>perhaps the devel kernel tree having an option for "Development DRM
> >>(XFree86 4.4) (Y/M/N)".
> >
> > 
> >For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
> >that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.
> 
> Or 4.2.x for most recent x?  What about bugs that are found in the modules 
> after XFree is released?  Or api changes within the kernel?

Sorry - yes 4.2.1 or most recent 4.2.x.

As for bugs found or api changes they should be submitted back to XFree86
so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x
release - if there was to be one.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Keith Whitwell
Alan Cox wrote:

On Wed, 2002-12-11 at 22:11, D. Hageman wrote:


Alan,

What would you like to see be implemented to help get the job done.  In 
other words, what do you need from the DRI team?


It takes two to tango so its not just what I need its also what do they
need.

What I would like to see would be:

A single definitive source for the DRM code, one where contributions go
back from Linux, from *BSD, from core XFree86 as well as from the DRI
project.


My feeling is that the dri cvs should be that place.  What workable 
alternatives exist?

It seems that changes get inserted to the drm code in the kernel from time to 
time.  Is the expectation that we monitor the kernel drm and periodically 
merge (or otherwise) those random or worthy changes back to this repository? 
I personally don't want to subscribe to lkml or attempt to fully monitory the 
traffic there.


The ability to track changes to that with reasons so that we can keep a
stable DRM and also the 'DRM of the day' visible to the kernel people -
perhaps the devel kernel tree having an option for "Development DRM
(XFree86 4.4) (Y/M/N)".


This is the biggest unknown, I think - there are multiple sources that have a 
reasonable claim to this throne

	-- whatever was in the last XFree86 release
	-- XFree86 stable cvs (which differs only slightly from above)
	-- the newly created dri stable branch
	-- etc.

We've had some discussions about stable branches for other purposes (binary 
compatibility concerns with XFree versions), however it would make reasonable 
sense for this to be the definitive 'stable' source for drm modules also.

That would mean the DRM of the day gets more exposure to external review
and we find bugs in the kernel side (be they X or kernel caused)
rapidly, as well as submitting back changes to the common repository so
that when a new major Linux kernel appears DRM just works.



We've been very lucky in that Linus has been pulling changes into 2.5 and 
providing some useful feedback when things go wrong.  I don't know how 
sustainable this is though - I think we're probably taking up more of his time 
than we should be.

How would you ideally see this working?

Keith





---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Hourihane
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote:
> On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> > 
> > Alan,
> > 
> > What would you like to see be implemented to help get the job done.  In 
> > other words, what do you need from the DRI team?
> 
> It takes two to tango so its not just what I need its also what do they
> need.
> 
> What I would like to see would be:
> 
> A single definitive source for the DRM code, one where contributions go
> back from Linux, from *BSD, from core XFree86 as well as from the DRI
> project.
> 
> The ability to track changes to that with reasons so that we can keep a
> stable DRM and also the 'DRM of the day' visible to the kernel people -
> perhaps the devel kernel tree having an option for "Development DRM
> (XFree86 4.4) (Y/M/N)".
 
For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules
that ship with 4.2.0. For 'DRM of the day' use the DRI trunk.

Alan.


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] DRM Kernel Questions

2002-12-12 Thread Alan Cox
On Wed, 2002-12-11 at 22:11, D. Hageman wrote:
> 
> Alan,
> 
> What would you like to see be implemented to help get the job done.  In 
> other words, what do you need from the DRI team?

It takes two to tango so its not just what I need its also what do they
need.

What I would like to see would be:

A single definitive source for the DRM code, one where contributions go
back from Linux, from *BSD, from core XFree86 as well as from the DRI
project.

The ability to track changes to that with reasons so that we can keep a
stable DRM and also the 'DRM of the day' visible to the kernel people -
perhaps the devel kernel tree having an option for "Development DRM
(XFree86 4.4) (Y/M/N)".

That would mean the DRM of the day gets more exposure to external review
and we find bugs in the kernel side (be they X or kernel caused)
rapidly, as well as submitting back changes to the common repository so
that when a new major Linux kernel appears DRM just works.

Alan



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] 50% decrease in Consumers Supply of Cash forecasted for the coming year, by the Mortgage Bankers Assn., Fannie Mae, and Freddie Mac

2002-12-12 Thread lochard




The Mortgage Bankers
Assn., Fannie Mae, and Freddie Mac are forecasting a 50% decrease in Consumers
Supply of Cash for the coming year.  
The  50% decrease in Consumers cash supply is
based on less refinancing, raising interest rates, house-price appreciation
slows, the number of potential borrowers shrinks, and consumers worry about
their jobs.   From Bloomberg
News and Los
Angeles Time
 

  
  

  

   Jump
  Start your Sales now or possibly suffer layoffs or even lose your
  Business
   E-Commerce within an eMail can generate 3x
  higher click-through rates From Internet
  World (Industry news resource)
   eMail Marketing
  
  The
  Average Customer Response time is 1-5 days. Compare this to 1-7 weeks with
  Postal advertisement. 
   
  

  Send 20 Targeted Interactive
  Advertisements to Customers that meet your targeted Demographics for the
  cost of 1 pieces of Direct Postal Mail
   


 
Targeted eMail marketing is a faster, better, and a more cost effective
way to Reach your customers for less. Kick start your Sales
today!
 
 
 
For less then the
cost of a United States Postage Stamp DirectServices
provides:
 

  
  

  

Custom Developed
Targeted eMail address list to target your Customers specific
Demographics  (such as
Income, Location, Profession, etc...)
  
  

  
Designs  your Dynamic and interactive
Advertisement  (HTML Design with pictures, Text, and HTML FORM
[typing Fields] compatible with all Computer types)
  
  

  
Managed Delivery of  Advertisements by
Certified Engineers 
  

  
Marketing Success Report, noting confirmed delivery time,
Customers email address, and even when your advertisement was opened by
the Customer (subject to availability) 
  
 
  

Your Marketing Can Start in as little as 48 hours, after
completing your Order...
 
To
Start your Marketing Campaign Click here or Call 310-937-6368

 
  Click
here To Request more information
 
  Click
here to Request a Call from one of our Network Engineers
 
  


 
Information on Marketing is being
sent to you as part of a free Business Development Service. 
Please distribute this newsletter
freely; however, we ask that you not change its contents. 
To
Continue to Subscribe: To be included in future
newsletters, please Click here to send an
eMail Confirmation with "subscribe" as the subject. 
To
Unsubscribe: To unsubscribe, please Click here to send an eMail
Confirmation with "unsubscribe or remove" as the subject. 
Customer Service: To eMail Customer Service Click
here





[Dri-devel] MESA_PBUFFER_ALLOC, alignment

2002-12-12 Thread Keith Whitwell
Is there any rational for the 512 byte alignment in this macro?

This is used to allocate main-memory copies of texture images, so the numbers 
add up pretty quickly...

I can't think of any reason to go beyond 16 or at most 32 byte alignment from 
a cpu/caching perspective, and these buffers aren't visible to hardware (which 
can have more stringent requirements).

Keith



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?

2002-12-12 Thread Nicolas ASPERT
David Dawes wrote:



No, I think it should be intel_845_setup too, since the 845G docs on
Intel's public web site show that the behaviour is like the 845 when
the on-board graphics isn't enabled.  I made that change in my
locally maintained version of the agpgart driver a little while ago,
but haven't had the opportunity to test it with an external AGP card
in an 845G box yet.


Damn, you're right. Now I got the docs from Intel (at the time were the 
patch to support 845g was submitted, they were just not available yet), 
and truly the specs are closer to the 845, so let's switch to 
'intel_845_setup' to initialize the 845g. Not that it should change 
things too much, but it will avoid further confusions

Best regards.

Nicolas

PS: I hope the IBM annoyances for mails sent to lkml stopped...
--
Nicolas Aspert  Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel