On Thu, Jan 24, 2002 at 08:07:18PM -0700, Jens Owen wrote:
> [WARNING, this is a long response that addresses the pros and cons of
> separating the 3D drivers from XFree86]
>
I'd like to respond to just a few things in Jens's excellently written
email.
> Another pitfall that comes to mind
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:
Nicholas Charles Leippe wrote:
>
> > > Does the current (what's in X4.2.0 or DRI CVS) code use
> > > the T&L 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
> > > g
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
startu
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
> > 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
> >
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
templ
[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
> 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
> performan
> 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
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 beca
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 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 o
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 TD0_color_blend_e
> > 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 co
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.
-
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 ru
> 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, an
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
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 Val
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
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 expecta
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 expecta
23 matches
Mail list logo
