On Tuesday 20 November 2001 11:27 pm, you wrote:
Yep, that's correct. Had to deal with missing and/or conflicting info
to boot...
This sounds strangely familiar... :-)
--
Frank Earl
___
Dri-devel mailing list
[EMAIL PROTECTED]
I've just got a new Radeon 7500. I've tried to get it working under XFree86
4.1.
I get a problem (EE) No devices detected. I assume this is because the 7500
is not supported as yet. I've downloaded and compiled the CSV tree and stil no
joy.
XFree reports (--) PCI:*(1:0:0) ATI unknown chipset
Hi all,
these cards have Linux32 driver (written at www.ati.com) and base AFAIK on
the Radeon 7500/8500 GPU.
So do these drivers give TL Hardware support for OpenGL on new ATI cards?
I would like to buy a Radeon 7500 with DVI/TV/VGA out.
Anybody has these drivers?
Best Regards
Michael
Hey, did these ATI FireGL products already hit the stores now?
AFAIK they have not.
As Linus always told: Things will come when they are done.
Unlike Linus, the driver wont be open source, simply because
of the high amount of trade secrets contained within. But
on the other side you will get
[Personal reply with public CC.]
Yeah, but would ATI release drivers for the 7500/7800/8500 or
only to the 8500 series?
I dont know these specific models, not my personal scope.
But i would like them to be supported, so that anyone is happy.
Any time frame? I'm going to order a machine
The FireGL card is basically the same as the 7500/7800 with
some modification
to enable it to perform much faster then the 7500/7800.
As i wrote elsewhere, the 8xxx series is based all on similar chips.
(similar means that the hardware feature subset is compareable.)
Its the so calle Radeon
On Sat, 2001-11-10 at 20:58, Benjamin Herrenschmidt wrote:
Note that it doesn't work correctly with all chipsets yet (the Rage M3
loves to lockup) with XFree 4.1. I beleive the problem is specific to
that chip and possibly not related to those AGP fixes as other r128
cards seem to work
On Mon, 2001-11-19 at 10:03, Daniel Polombo wrote:
Michel Dänzer wrote:
My first guess would have been a wrong version of the kernel module, but
the one from the 2.4.14 kernel should work. Could there be a stray
libGL, e.g. in /usr/local, that gets picked up? You can check with ldd.
I
I suspect it's less stable for us than for the x86 folks though, or
there would be more noise about it on the various lists.
What's this agp_special_page about?
The agp_special_page is a page of RAM reserved by some code I have
in the kernel's MM init stuff which is as high as possible, that
On Thu, 2001-11-22 at 12:03, [EMAIL PROTECTED] wrote:
Well, if we are supposed to flush the CPU write buffer, then yes.
mb() doesn't do that?
mb() is a lot more expensive, and I'm not completely sure how it
behaves regarding main memory accessed by UniNorth via AGP. It works
for SMP
On Thu, 2001-11-22 at 11:55, [EMAIL PROTECTED] wrote:
I suspect it's less stable for us than for the x86 folks though, or
there would be more noise about it on the various lists.
What's this agp_special_page about?
The agp_special_page is a page of RAM reserved by some code I have
in
Robert Risack wrote:
Hi folks
Since I own a ATI Mach64 graphic card, I would like to help developing
the DRI driver. I am computer scientist, but do not have any experience
of driver writing on Linux or X.
Greetings
___
Dri-devel mailing
Did you use it from the start in your AGP implementation? I didn't
notice any difference between a couple weeks back and lately.
It was there since I had working AGP. The only difference between
what I had in my tree previously and what I submited here are some
cleanups to remove warnings and
Dieter Nützel wrote:
Am Mittwoch, 7. November 2001 07:07 schrieb Keith Whitwell:
Dieter Nützel wrote:
Yes, I know it _is_ wok in progress, but I am trying to test it. The
former mesa-3-5-branch has some bugs in conjunction with the tdfx driver
and was slower as the trunk. I think it
hey,
Can anyone recommend a laptop which'll run hw accelerated gfx under dri? (my wallet
isnt huge :( )
thx
samuel
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Around 10 o'clock on Nov 21, Michel D nzer wrote:
In 1600x1200x24 It takes 1 full second to draw the screen, or a
good 3/4 of a second. That is definitely not accelerated.
Again, disabling DRI, the MMIO accel makes everything fly.
Color expansion is probably what's missing.
Color
On Wed, 2001-11-21 at 18:05, Keith Packard wrote:
Around 10 o'clock on Nov 21, Michel D nzer wrote:
In 1600x1200x24 It takes 1 full second to draw the screen, or a
good 3/4 of a second. That is definitely not accelerated.
Again, disabling DRI, the MMIO accel makes everything
Hi.
I am sure these questions are answered in a FAQ, but I couldn't find this
info on the mesa website nor in the xfree86 docs. (May have overlooked
something.)
1.
XFree86 4.1.0 contains (pieces of) Mesa 3.4.2.
The most noticeable exception being glut, I guess.
Are there other major parts of
Dag B wrote:
Hi.
I am sure these questions are answered in a FAQ, but I couldn't find this
info on the mesa website nor in the xfree86 docs. (May have overlooked
something.)
1.
XFree86 4.1.0 contains (pieces of) Mesa 3.4.2.
The most noticeable exception being glut, I guess.
Are
I've noticed a general slowdown of XAA on Radeon when DRI is
enabled. This is in our XFree86-4.1.0-3 package that shipped
with Red Hat Linux 7.2.
If DRI is disabled by commenting out the dri and GLcore
module load lines in XF86Config-4, then 2D acceleration flies.
Re-enabling DRI however
It's a little suprising to me that removing some (fairly unimportant)
accelerations makes 2D painfully slow; except for a few things
like blits and solid area fills, acceleration just doesn't matter
much any more. What applications were you testing with?
I've seen DRI slow 2D down to a crawl,
On 20 Nov 2001, Owen Taylor wrote:
Date: 20 Nov 2001 09:39:40 -0500
From: Owen Taylor [EMAIL PROTECTED]
To: Mike A. Harris [EMAIL PROTECTED]
Cc: DRI devel list [EMAIL PROTECTED], [EMAIL PROTECTED],
Hui Yu [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: Re:
I've had a couple of FreeBSD DRI and Radeon users complain about this too. I
had always chalked it up to some bug in our drivers and I was waiting to get
a Radeon myself to check it out.
On Tuesday 20 November 2001 16:29, Mike A. Harris wrote:
On 20 Nov 2001, Owen Taylor wrote:
Date: 20
On Tue, 20 Nov 2001, Eric Anholt wrote:
I've had a couple of FreeBSD DRI and Radeon users complain about this too. I
had always chalked it up to some bug in our drivers and I was waiting to get
a Radeon myself to check it out.
Well, I've now confirmed that we are not on crack. ;o) People
On Tue, 20 Nov 2001, Mike A. Harris wrote:
konsole, mozilla, any other application that is maximized. You
name it. I can watch it draw the whole screen and count out
loud.
In 1600x1200x24 It takes 1 full second to draw the screen, or a
good 3/4 of a second. That is definitely not
On Wed, 2001-11-21 at 01:29, Mike A. Harris wrote:
On 20 Nov 2001, Owen Taylor wrote:
It's a little suprising to me that removing some (fairly unimportant)
accelerations makes 2D painfully slow; except for a few things
like blits and solid area fills, acceleration just doesn't matter
much
On Tue, 20 Nov 2001, Ani Joshi wrote:
Well, I've now confirmed that we are not on crack. ;o) People
who claim they're using Radeon with DRI enabled and not having
any 2D slowdowns, are indeed on crack though, as the source code
itself, as well as developers have now confirmed to me that
On Thursday 27 September 2001 19:55, you wrote:
Dacobi Coding wrote:
Hello people!
...
Not to say that ATI won't switch to a binary-only driver as well, but
anyway...
But are they planing to, or have they allready releaced the specs
for the new Radeon chips? And I mean full specs complete
Dacobi Coding wrote:
But are they planing to, or have they allready releaced the specs
for the new Radeon chips? And I mean full specs complete
with V/P Shaders and TL?
Did they ever release specs for the original Radeon? No. One would
guess the same policy will apply in this case as
From: Gareth Hughes <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Radeon 8500, what's the plan?
Date: Thu, 27 Sep 2001 12:05:13 -0700
Dacobi Coding wrote:
But are they planing to, or have they allready releaced the specs
for the new
Simon Fowler wrote:
About a month or two ago the DRI cvs tree was pruned a lot, so
that it only really has the code needed for building the xserver
and a few libs that need modifications from the base XFree86 4.x
install - this is what's causing the problem.
Actually, I think the problem is
On Thursday 27 September 2001 21:05, you wrote:
Dacobi Coding wrote:
But are they planing to, or have they allready releaced the specs
for the new Radeon chips? And I mean full specs complete
with V/P Shaders and TL?
Did they ever release specs for the original Radeon? No. One would
They did release specs (under NDA) to many people
(including yourself through PI/VA Linux).
Keep in mind that ATI was paying VA Linux to develop Radeon Linux drivers at
the time.
- Daniel Vogel, Programmer, Epic Games Inc.
___
Dri-devel mailing
From: Gareth Hughes <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Radeon 8500, what's the plan?
Date: Thu, 27 Sep 2001 12:56:53 -0700
David Johnson wrote:
They did release specs (under NDA) to many people (including
yourself
through
On Thursday 27 September 2001 21:56, you wrote:
David Johnson wrote:
They did release specs (under NDA) to many people (including yourself
through PI/VA Linux).
Sure, but not to people in the general open source community, and with the
demise of PI/VA, I would say the chances of a driver
On Thu, Sep 27, 2001 at 08:19:46PM +, David Johnson wrote:
Sure, that is a valid point but we need to remember that in the past
ATI has not been adverse to supporting open source drivers or to
releasing specs to qualified people.
They are very friendly actually. They provided me
On Thu, 27 Sep 2001, Peter Surda wrote:
On Thu, Sep 27, 2001 at 08:19:46PM +, David Johnson wrote:
Sure, that is a valid point but we need to remember that in the past
ATI has not been adverse to supporting open source drivers or to
releasing specs to qualified people.
On Thu, 27 Sep 2001, Dacobi Coding wrote:
Dacobi Coding wrote:
Hello people!
...
Not to say that ATI won't switch to a binary-only driver as well, but
anyway...
But are they planing to, or have they allready releaced the specs
for the new Radeon chips? And I mean full specs complete
with
Ever since the CVS clean up it's been annoying to build the tree.
I have so far used #define ProjectRoot /opt/X4 (in config/cf/site.def)
and this leads to annoyances with libraries and stuff.
X libraries incs are installed in /usr/X11R6/{lib,include}/ but build
process nolonger seems to care
On Thu, Sep 27, 2001 at 11:21:37PM -0700, David Bronaugh wrote:
If you look at it from a purely monentary point of view, yes, you are most
likely correct.
Not only from monetary point of view.
However, one has to remember that a LOT of people that run Linux are
computer people that users
From: Carl Busjahn
I have to disagree. If people are really concered about performance
they should be using Linux anyway. What David said is also
true. I'm
not going to reccomend a company that doesn't support Linux. We also
know that Online games require good bandwidth, and the
I just installed Slackware 8 with XFree86 4.1.0 and I've come across some
weirdness with glxgears. When I'm running a window manager everything is
fine but when I don't run a window manager I get a much higher frame rate
but what I see is some garbage with a piece of a large red gear. Is this a
On 25 Nov 2001, Michel Dänzer wrote:
On Wed, 2001-11-21 at 15:29, Diarmuid Drew wrote:
I've just got a new Radeon 7500. I've tried to get it working under
XFree86 4.1. I get a problem (EE) No devices detected. I assume
this is because the 7500 is not supported as yet. I've downloaded
Am Donnerstag, 22. November 2001 17:20 schrieb Keith Whitwell:
Dieter Nützel wrote:
Am Mittwoch, 7. November 2001 07:07 schrieb Keith Whitwell:
Dieter Nützel wrote:
Yes, I know it _is_ wok in progress, but I am trying to test it. The
former mesa-3-5-branch has some bugs in
On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote:
Log message:
Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for
versioning information.
Modified files:
xc/xc/lib/GL/mesa/src/drv/r128/:
r128_xmesa.c
On Sun, 2001-11-25 at 23:28, Damien Miller wrote:
On 25 Nov 2001, Michel Dänzer wrote:
On Wed, 2001-11-21 at 15:29, Diarmuid Drew wrote:
I've just got a new Radeon 7500. I've tried to get it working under
XFree86 4.1. I get a problem (EE) No devices detected. I assume
this is
On Mon, Nov 26, 2001 at 02:51:18PM +0100, Michel Dänzer wrote:
On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote:
Log message:
Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for
versioning information.
Modified files:
xc/xc/lib/GL/mesa/src/drv/r128/:
Michel Dänzer wrote:
On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote:
Log message:
Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for
versioning information.
Modified files:
xc/xc/lib/GL/mesa/src/drv/r128/:
r128_xmesa.c
On Mon, 2001-11-26 at 15:59, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2001-11-26 at 14:28, Keith Whitwell wrote:
Log message:
Put drm version back from 3.0 to 2.2; XFree86 4.1 is the baseline for
versioning information.
Modified files:
Peter Surda wrote:
On Fri, Sep 21, 2001 at 05:08:29PM +0200, Michel Dänzer wrote:
Yes, PCI GART is still disabled in source for the Radeon AFAIK.
Hmm I thought pci gart isn't implemented yet for radeon?
The code has been there for as long as for the Rage128, it's just still
disabled on
$$$
WOW $89 for 10,000 targeted user
$$$
The Cheapest Source of Traffic on the Internet... ANYWHERE...
INCREDIBLE... Targeted Traffic to your website... No Pop-up's...
Yes, YOU CAN flood your site on the
On Thu, 2001-11-29 at 06:34, Nicholas Leippe wrote:
This isn't really DRI specific, but I don't know where else
to ask.
I just built + installed X from cvs, and it didn't build
the pex5 or xie libs. I'm not even really sure what these
do, but my other machine that I built a while back
Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane:
That's because you need to use the mesa_4_0_branch check out from mesa3d
too, and not the trunk code.
You call the Mesa CVS (4.1) which I use, the trunk?
So I have to checkout the Mesa 4.0/4.0.1 branch?
Thanks,
Dieter
On Thu, Nov 29, 2001 at 04:31:30PM +0100, Dieter Nützel wrote:
Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane:
That's because you need to use the mesa_4_0_branch check out from mesa3d
too, and not the trunk code.
You call the Mesa CVS (4.1) which I use, the trunk?
So I
Michel Dänzer wrote:
agpgart is really stable for you? Most things like glxgears work fine on
my Pismo with it, but a few other things like tuxracer reliably lock up.
Haven't tried anything like TuxRacer yet. Don't know what kind of effect
that will have on it.
Never seen that. Or heard
Am Donnerstag, 29. November 2001 16:40 schrieb Alan Hourihane:
On Thu, Nov 29, 2001 at 04:31:30PM +0100, Dieter Nützel wrote:
Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane:
That's because you need to use the mesa_4_0_branch check out from
mesa3d too, and not the trunk
Oh,
I've forgotten to send you a little screenshot.
It shows some texture/clipping errors, too.
Yours,
Dieter
Am Donnerstag, 29. November 2001 23:23 schrieb Dieter Nützel:
Am Donnerstag, 29. November 2001 16:40 schrieb Alan Hourihane:
On Thu, Nov 29, 2001 at 04:31:30PM +0100, Dieter
On Thu, 2001-11-29 at 21:00, Derrik Pates wrote:
Michel Dänzer wrote:
That's too low indeed. I get ~350 without agpgart and almost 500 with
it. (Or is your CPU slower than 300 MHz?)
It's a 366 MHz G3 processor.
So you should be able to achieve higher numbers. I'd expect somewhere
On Sat, Oct 06, 2001 at 02:46:44AM +0200, Dagfinn Ilmari Mannsåker wrote:
Hi,
I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't
work. The r128 module loads fine, when I try to read from /proc/dri/0/vm,
cat segfaults and I get this oops:
With 2.4.10-ac7 it no
On Fri, 2001-10-05 at 18:09, Frank Earl wrote:
On Friday 05 October 2001 10:46, you wrote:
i noticed your name on dri.sourceforge.net and was wondering if mach64
support was still being worked on or if the developers aren't going to
continue with the project. there are many questions
Nathan Hand wrote:
My alternative is of course to have a dedicated DOS-only box, just for
games. I know perps who play the old Sierra adventures this way. So if
people are willing to do this for DOS surely they're willing to have a
Linux 2.2 system just for running Linux games? Not likely!
- Original Message -
From: Michel Dänzer [EMAIL PROTECTED]
To: Nathan Hand [EMAIL PROTECTED]
Cc: Michael Zayats [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, October 05, 2001 2:14 AM
Subject: Re: [Dri-devel] glDrawPixels on i810
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
Hey,
It's more than likely that your problem is in the 2.4.3 kernel, it had
several issues with agp, and didn't work at all on Cyrix processors.
2.4.10 is a excellent release, and you'd do well to get it.
Carl Busjahn
Dagfinn Ilmari Mannsåker wrote:
Hi,
I have a Dell Inspiron 4000 with an
- Original Message -
From: Michel Dänzer [EMAIL PROTECTED]
To: Nathan Hand [EMAIL PROTECTED]
Cc: Michael Zayats [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, October 05, 2001 2:14 AM
Subject: Re: [Dri-devel] glDrawPixels on i810
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
On Sun, 2001-10-07 at 17:43, Michael Zayats wrote:
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote:
XV is completely independent of V4L and the DRI.
This is true conceptually and was true implementation-wise until
recently. However, the r128 driver uses the DRM to transfer the XvImage
On Sun, Oct 07, 2001 at 08:15:38AM -0400, Carl Busjahn wrote:
Hey,
It's more than likely that your problem is in the 2.4.3 kernel, it had
several issues with agp, and didn't work at all on Cyrix processors.
2.4.10 is a excellent release, and you'd do well to get it.
I'm not running 2.4.3.
On Mon, Oct 08, 2001 at 01:56:28AM +0200, Michel Dänzer wrote:
On Sun, 2001-10-07 at 23:44, Dagfinn Ilmari Mannsåker wrote:
I am very keen on getting DRI up and running on this machine, and I
will assist with any tests and/or troubleshooting you find necessary,
just give me the
Yes, You must be running this thing at about 1600x1200... Your highest
mode for 16 bit is 1024x768. You really wouldn't get any preformance at
a higher resolution anyway. And highest for 24(32)bit is 800x600, but
use 16bit.
Dagfinn Ilmari Mannsåker wrote:
On Mon, Oct 08, 2001 at 01:56:28AM
From: Peter Surda [mailto:[EMAIL PROTECTED]]
Hmm isn't this dri-devel? Shouldn't we be talking about stuff
like how to do
DMA efficiently and what new functions to add instead? Brings
me back to what
I wrote a couple of weeks ago, there is no function in DRI
that is able to
transfer
From: Michel Dänzer [mailto:[EMAIL PROTECTED]]
On Fri, 2001-10-05 at 17:25, [EMAIL PROTECTED] wrote:
Before I try delving deeper into this, maybe someone can
tell me what is
going on.
* Radeon: 1002:5144
* 2d is working fine
* software GL is working fine
*
After reading documentation (and confirming that I already know all the
acronyms) and sifting thru driver code I decided to ask on the list, while
the people who wrote this stuff can still answer ;)
Basically I want to DMA a chunk of video ram into plain RAM. This is
useful for: video
Vladimir,
The drm _does_ allow the client to mmap the video ram. Of course
there are security reasons to limit this behavior. The X server
handles the memory management and then sets up drm maps which are
areas of video memory that can be mapped by a drm client.
Take a look at the
On Mon, Oct 08, 2001 at 03:54:14PM -0700, Sottek, Matthew J wrote:
Basically I want to DMA a chunk of video ram into plain RAM. This
is useful for: video capture, VBI/closed captioning, taking screen
snapshots.
I think you are going about this the wrong way. Video capture does
not need
On Mon, 8 Oct 2001, Sottek, Matthew J wrote:
Vladimir,
The drm _does_ allow the client to mmap the video ram. Of course
I don't want video ram. I want to transfer data from video ram into plain
memory and then access it there - pci reads are way slow.
there are security reasons to limit
Vladimir,
As Peter pointed out to me you were speaking of a video card
with built-in capture. This _does_ require, as you stated a
way to get the video, out of the video ram and into system ram,
my apologies for the misunderstanding.
My point should still hold. The DRM should allow you to
On Tue, 9 Oct 2001, Peter Surda wrote:
On Mon, Oct 08, 2001 at 03:54:14PM -0700, Sottek, Matthew J wrote:
The drm _does_ allow the client to mmap the video ram.
I am not completely sure about this, but as I'm also working on the same thing
as Vladimir, capturing for ATI AIWs, I think he
On Mon, Oct 08, 2001 at 06:14:13PM -0700, Sottek, Matthew J wrote:
my apologies for the misunderstanding.
np, the point is we all learned something new :-)
My point should still hold. The DRM should allow you to map
an video area into a client accessible memory location.
You don't need DRM
On Mon, Oct 08, 2001 at 06:31:24PM -0700, Gareth Hughes wrote:
I think it'll be hard to set up and initiate DMA transfers without
proper hardware documentation. Do you have Radeon specs?
Yes, all the developers working on this (volodya, RC and I) have docs from ATI
under NDA (well I don't
On Mon, 8 Oct 2001, Gareth Hughes wrote:
[EMAIL PROTECTED] wrote:
After reading documentation (and confirming that I already know all the
acronyms) and sifting thru driver code I decided to ask on the list, while
the people who wrote this stuff can still answer ;)
Basically I
On Mon, 8 Oct 2001, Sottek, Matthew J wrote:
Vladimir,
As Peter pointed out to me you were speaking of a video card
with built-in capture. This _does_ require, as you stated a
way to get the video, out of the video ram and into system ram,
my apologies for the misunderstanding.
Hey, has anyone had experience with Radeon VE for dri? I'm not
interested in the extra heads particularly... VE 64mb starts at $57 on
pricewatch, or with tv out for $65. It's faster than a Geforce2 MX400,
and the linux drivers are open source... if they work. If anyone has
expereinced the
Hey, has anyone had experience with Radeon VE for dri? I'm not
interested in the extra heads particularly... VE 64mb starts at $57 on
pricewatch, or with tv out for $65. It's faster than a Geforce2 MX400,
and the linux drivers are open source... if they work. If anyone has
expereinced
On Wed, 10 Oct 2001, Bobakitoo wrote:
Radeon VE is verry diapointing. It propably the driver code and
it may be get improved.
A quick look at any of the reviews for the Radeon VE will point out that
there is a very significant difference between the VE and other Radeons.
The VE is intended
So, can anyone answer any of the questions below, or do I have to write
drm for multimedia ?
thanks
Vladimir Dergachev
interface of doing captures. I'm currently working on a new Xv function
(XvShmGetImage) that will do this, and
On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote:
So, can anyone answer any of the questions below, or do I have to write
drm for multimedia ?
The DRM is an architecture for accessing hardware directly.
What functions are implemented in any given kernel module is driven by
Thanks for the information, it was very helpfull., I'm sorry If I
offended anyone by saying radeon is faster than Gf2 mx400, though it is
:-) You might want to research your hardware before you say something
like a radeon doesn't have TL...
Carl Busjahn
Tim Keating wrote:
On Wed, 10 Oct
On Wed, 10 Oct 2001, Daryll Strauss wrote:
On Wed, Oct 10, 2001 at 05:13:40PM -0400, [EMAIL PROTECTED] wrote:
So, can anyone answer any of the questions below, or do I have to write
drm for multimedia ?
The DRM is an architecture for accessing hardware directly.
What functions are
On Thu, 11 Oct 2001 19:15, Fray Bentos wrote:
Hi I submitted a bug report a few days ago concerning the HP_OCCLUSION_TEST
extention to opengl on the tdfx driver.
Im hopefully gonna fix it myself, but i was wondering if any one can verify
that the extension works perfectly on any other (other
On Fri, Oct 12, 2001 at 02:15:42AM +0100, Fray Bentos wrote:
Hi I submitted a bug report a few days ago concerning the HP_OCCLUSION_TEST
extention to opengl on the tdfx driver.
Im hopefully gonna fix it myself, but i was wondering if any one can verify that
the extension works perfectly on
Finally, someone who knows the stuff :)) No, there is no such variable,
but this phrase I plucked from the comment. Here is an example from
radeon.h:
/* CP vertex/indirect buffer data */
unsigned long bufStart;/* Offset into AGP space */
On Fri, 12 Oct 2001, Fray Bentos wrote:
Hi I submitted a bug report a few days ago concerning the HP_OCCLUSION_TEST
extention to opengl on the tdfx driver.
Im hopefully gonna fix it myself, but i was wondering if any one can verify that
the extension works perfectly on any other (other
vendredi, le 12 octobre, 2001, Fray Bentos nous a dit ceci:
Hi I submitted a bug report a few days ago concerning the HP_OCCLUSION_TEST
extention to opengl on the tdfx driver.
Im hopefully gonna fix it myself, but i was wondering if any one can verify that
the extension works perfectly on
On Wed, 10 Oct 2001, Keith Whitwell wrote:
Finally, someone who knows the stuff :)) No, there is no such variable,
but this phrase I plucked from the comment. Here is an example from
radeon.h:
/* CP vertex/indirect buffer data */
unsigned long
#
Mortgage rates have dropped again!! The lowest in years!!
Refinance your current mortgage loan with a better rate AND
save money on your monthly payment! Pay off those credit card
bills you dread paying every month! Or add that special home
improvement
Hi all.
Firstly, I know this isn't exactly the right place for this question,
but I've already tried on the video4linux list and the kernel developers
list, and got NO response at all :( ie I am desperate...
I have a 64MB ViVo Radeon - without the tuner.
I also have a BT878-based tuner /
Fray Bentos wrote:
Im hopefully gonna fix it myself, but i was wondering if any one can verify that
the extension works perfectly on any other (other than the v5500) voodoo card.
Seems to work OK on a Voodoo 3500TV. The results are as others have
described. Turning off the video refresh sync
On Thu, 11 Oct 2001, dan wrote:
Hi all.
Firstly, I know this isn't exactly the right place for this question,
but I've already tried on the video4linux list and the kernel developers
list, and got NO response at all :( ie I am desperate...
I have a 64MB ViVo Radeon - without the
Hi,
can anyone point me if the DRI cvs tree is broken
right now? i am trying to compile the xc tree
and the only lib it compiles correctly (after
a bit of modification to makefile) is libGL.
Any other libraries and binaries doesn't compile,
is the compilation guide in dri.sourceforge.net
On Thu, 11 Oct 2001 [EMAIL PROTECTED] wrote:
Is it possible to get the signal from the BT878 tuner into the Radeon
for hardware mpeg conversion? Maybe a video4linux-loopback-type-thing.
What do you mean by hardware mpeg conversion ?
Many All-in-Wonder (and I think some of the VIVO cards)
On Thu, 11 Oct 2001, Derrik Pates wrote:
On Thu, 11 Oct 2001 [EMAIL PROTECTED] wrote:
Is it possible to get the signal from the BT878 tuner into the Radeon
for hardware mpeg conversion? Maybe a video4linux-loopback-type-thing.
What do you mean by hardware mpeg conversion ?
Many
901 - 1000 of 46322 matches
Mail list logo
