John Utz wrote:
hi again;
is there a drm implementation in cvs that is looked upon with favor as
being done 'more correctly than others'?
is there a drm implementation in cvs that is looked upon with favor as
being done 'more simply than others'?
note that i have no expectation as
John Utz wrote:
hi again;
is there a drm implementation in cvs that is looked upon with favor as
being done 'more correctly than others'?
is there a drm implementation in cvs that is looked upon with favor as
being done 'more simply than others'?
note that i have no expectation as
On 23 Jan 2002, Steve Bergman wrote:
On Wed, 2002-01-23 at 13:56, Brian Paul wrote:
FYI, the new issue if Linux Journal (february, page 78) has a technical
support question regarding stability of a Soyo K7V Dragon/1.4GHz Athlon
system. The system runs fine with 1GB of ram but is
John Utz wrote:
one last question before i knock off for the nite
suppose one has two cards.
the first, the FooBarTech VisiBlaster, has special hardware for optimizing
the generation of very realistic clouds.
the second, the BazGrafix RadiantTurkeyBaster XL6000 AGP 4X Value
On Wed, Jan 23, 2002 at 07:47:12PM +, Keith Whitwell wrote:
Michael wrote:
I got that to work. Typing from my head here, but there's an offset
defined RADEON_AGP_TEX_OFFSET (radeon_reg.h), that's 2mb (0x0200?) for R128,
that needed to be 4mb on the
radeon and it didn't need the
Does anyone have any ideas about this problem?
Here is my configuration:
RedHat Linux 7.2, Linux kernel 2.4.7-10
XFree86-4.1.0
XFree86-4.1.0-0.99.3-GLonly
redhat-mesa-3.4.2
Dual CPU AMD Athlon (running in uniprocessor mode due to DRI problems)
Matrox G450
I've got a G450, and DRI
Hi there,
I'm really disappointed about this patch story, not because it hasn't
been applied yet (I've notive that yesterday too), but because I was
indirectly told why, exactly 7 months later. If I knew, it would have
been really easy to change my patch to make it conform to the DRI
patching
Keith Whitwell wrote:
but also, people have put some work into looking at GL_DECAL on mga - and
concluded that it isn't possible to do correctly. Maybe a 2-stage process can
simulate single-texture blend, but in general it doesn't look possible.
i got it working once.. ill dig it up.
--
The kernel interfaces are highly dependent on the hardware they work
with.
different in the sense that they all have a common collection of
fundamental activities and they all have a collection of disparate
activities?
or different in the sense that they have *no* common collection
my patch and the tweaked multiarb test programm.
the mga texture blending units:
clock | unit1 | unit2
cl1:t1*t2
cl2:t2*t3t1*t2
cl3: t2*t3
so unit2 should use the previous stage
at the third clock and not at the second.
(TD0_color_arg2mul_alpha2 and
I have an OpenGL (Mesa) application that works fine except when I attempt to render
the same texture objects in more than one window (GLX windows) at the same time, in
which
case the textures are incorrect and I get the following error message:
Couldn't alloc placeholder sz 4 ofs
Well, it seems that the problem is indeed hardware. I had tried setting
my bios settings to fail safe but that still left the memory at
133MHZ. Setting it to 100mhz alleviates the problem. So DRI just
aggravates an existing hardware issue. All things considered. With the
performance hit in
I posted a RFC about a new type of Shared agp memory a while back
but didn't get any input. I thought I would try again since there has
been better communication as of late, and the idea has progressed
somewhat.
The problem:
The agpgart usage model is not well suited for UMA architectures
Hmm.. Another thing to check - are you sure your power supply is
adequate ? Radeon chip has a fan on it for a reason.
Actually the fan is there to make the Radeon look faster, it runs cool at the .18
process on wich it was manufactured. Power draw I wouldnt know, then again I run my
radeon
Well, it seems that the problem is indeed hardware. I had tried setting
my bios settings to fail safe but that still left the memory at
133MHZ. Setting it to 100mhz alleviates the problem. So DRI just
aggravates an existing hardware issue. All things considered. With the
performance hit
[WARNING, this is a long response that addresses the pros and cons of
separating the 3D drivers from XFree86]
David Johnson wrote:
If anything I would like to become even less dependent on
XFree. I think one of the things that scares potnetial developers away is
the fact that they have to
José Fonseca wrote:
Unless anyone has a better suggestion I think this is the way to go. What
do the elder developers think?
The one down side I see is the complexity (and clutter) created by the
TAGS. I like simple
paragraphs myself. Perhaps we could encourage a very basic simple
template
Well, it seems that the problem is indeed hardware. I had tried setting
my bios settings to fail safe but that still left the memory at
133MHZ. Setting it to 100mhz alleviates the problem. So DRI just
aggravates an existing hardware issue. All things considered. With the
Philip Brown wrote:
It might be nice to have some sort of generic 3d card stub, that
would have certain functions common to all 3d cards.
Nothing too fancy. In fact, NOTHING fancy :-)
We had one along time back--but it quickly got left behind as
development progressed. What's needed is an
Ian Romanick wrote:
I've been going through the DRI code and documents trying to figure out how
all this stuff works. I decided to start at the start, so I've been looking
at the driver initialization process.
Ian,
You and Brian have already done an excellent job commenting on the
startup
Nicholas Charles Leippe wrote:
Does the current (what's in X4.2.0 or DRI CVS) code use
the TL features on the Radeon? (the original QD)
There are hooks in the code, but support is not there.
Correct.
If not, what's the prognosis? Is it in the works and just
gonna take some
John Utz wrote:
hi;
i have reason to suspect that i have successfully hooked up agp in my
FreeBSD kernel.
Why? because agp0 is now attached to a pci id that matches the one that
http://www.yourvote.com/pci/vendors.txt asserts is the agp port on the
SiS630
agp0@pci1:0:0:
22 matches
Mail list logo
