AMD-760MP wrote:
>
> > Anytime the dri developers are in the Philadelphia area, dinner is on me
> > :-)
> >
> > Adam
>
> Only if I don't get to them first. :)
>
> Gareth - You never answered my last mail... What kind of microbrews do you
> like? I've got a box and peanuts and the UPS label read
Greg Hughes wrote:
>
> HI,
>
> I was attempting to build the mesa-3-5-branch with GlxBuiltInRadeon
> defined. I got multiply defined symbols in the link phase. Is this
> known to work/not work on this branch? Is there a better way to build
> modules that gdb is happy with?
It's not a configu
Greg Hughes wrote:
>
> Inline assembly experts,
>
> I've been palying with RedHat 7.1 Beta. This ships with gcc 2.96.77,
> which is much better than the 2.96 bundled with RedHat 7.0. This
> compiler can build the xc tree from the trunk, but it chokes trying to
> build the mesa-3-5-branch. It
Adam K Kirchhoff wrote:
>
> > I was getting ~1400 fps with my Radeon on a 600MHz Duron (ASUS A7V,
> > KT133 chipset), even with AGP 1x. Something's going horribly wrong with
> > your system...
>
> Are you serious? In all the times I've pulled and tested CVS code, I've
> never gotten above 1000
Kreuzritter2000 wrote:
>
> > On Sun, Apr 01, 2001 at 04:40:44AM +0200, Kreuzritter2000 wrote:
> >> Ok
> >>
> >> Now i benchmarkt my Voodoo3 2000 PCI card under XFree-DRI with
> >> gears.
> >>
> >> I get 125.623 frames/s.
> >>
> >> The tdfx driver was branch 3.0, dri-cvs from beginning of march.
>
"Ademar de Souza Reis Jr." wrote:
>
> Hello all.
>
> I'm trying to "play" with DRI support for SiS boards on xf-4_0_3 branch.
>
> After some work, everything is loaded and the log reports it's
> working, but when I try to start any app that uses it (ex. tuxracer
> or quake3), I get:
>
> SIS dr
Gareth Hughes wrote:
>
> I'm going to be committing my latest work, so expect the driver to be
> broken for a day or so. Note that it may not even compile, so you may
> want to avoid updating until I am done.
Just comment it out of the Imakefile in mesa/src/drv.
Keith
Looking at the tdfx driver I see this:
/* FIXME: Combine this into one call...
*/
FALLBACK( tmesa, TDFX_FALLBACK_BLEND_EQ, mode != GL_FUNC_ADD_EXT );
FALLBACK( tmesa, TDFX_FALLBACK_BLEND_EQ,
ctx->Color.ColorLogicOpEnabled && ctx->Color.LogicOp != GL_COPY );
This is bro
Gareth Hughes wrote:
>
> Keith Whitwell wrote:
> >
> > Looking at the tdfx driver I see this:
> >
> >/* FIXME: Combine this into one call...
> > */
> >FALLBACK( tmesa, TDFX_FALLBACK_BLEND_EQ, mode != GL_FUNC_ADD_EXT );
>
"Marcelo E. Magallon" wrote:
>
> Brian Paul wrote:
>
> > The DRI trunk code has a few problems with thread safety and
> > swapbuffers (all drivers but tdfx, probably). I've fixed this on
> > the 3.5 branch. You might try that.
>
> hmm... I picked the branch on a bad day it seems...
Do y
Brian Paul wrote:
>
> "Mike A. Harris" wrote:
> >
> > I would like to know given x Mb of video RAM on a given DRI
> > supported video card, how can I calculate what the maximum
> > screen resolution should be?
> >
> > width * height * fbbpp / 8 == 2D screensize
> >
> > I'll need to take virtual s
Mark Crichton wrote:
>
> Hello,
>
> I've been mucking around in the mesa-3-5 DRI branch, and was wondering
> if I should be reporting bugs (and fixes) for it?
>
> I've found some issues in lib/GL/mesa/src/drv/mga/mgatris.c w.r.t. some
> of the inline assembly (newer gcc's will complain that esi
Mark Crichton wrote:
>
> * Keith Whitwell ([EMAIL PROTECTED]) [010531 15:37]:
> > Mark Crichton wrote:
> > > I've found some issues in lib/GL/mesa/src/drv/mga/mgatris.c w.r.t. some
> > > of the inline assembly (newer gcc's will complain that esi has alre
Brian Paul wrote:
>
> CVSROOT:/cvsroot/dri
> Module name:xc
> Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/
> Changes by: brianp@usw-pr-cvs1. 01/06/01 09:21:32
>
> Log message:
> removed multipass loop from render tab functions, fixes gloss, spectex, etc
The loop should
Brian Paul wrote:
>
> Keith Whitwell wrote:
> >
> > Brian Paul wrote:
> > >
> > > CVSROOT:/cvsroot/dri
> > > Module name:xc
> > > Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/
> > > Changes by: brianp@usw-pr-cvs1.
Gareth Hughes wrote:
>
> Digital Z-Man wrote:
> >
> > Well, anyone who wants to, IMO.
>
> In theory, yes. In practice? Not really. Sure, the odd patch is
> submitted, but that's about it. Not much else has come from the "open
> source community"...
The fact that most of the interesting desi
Brian Paul wrote:
>
> CVSROOT:/cvsroot/dri
> Module name:xc
> Repository: xc/xc/lib/GL/mesa/src/drv/tdfx/
> Changes by: brianp@usw-pr-cvs1. 01/06/07 09:46:17
>
> Log message:
> add divide by zero checks to fix occasional clipping bugs in Q3
>
> Modified files:
>
"Sottek, Matthew J" wrote:
>
> The i810 driver used to have interrupt sharing before moving to the template
> code, it appears to have lost this functionality since the change. This is a
> real problem since a lot of the i810's and i815's have integrated lans that
> are using the same interrupt a
Catonga wrote:
>
> Hello,
>
> I just read this great review of XFree 4.1.0
> on "the duke of url" Website:
>
> http://www.thedukeofurl.org/reviews/misc/xfree86410/index.shtml
>
> And what i saw was more than impressive!
>
> The Voodoo 3 card is now nearly as fast as under Windows 2000
> in Qu
Michael Zayats wrote:
>
> The configuration is following:
>
> i810 + 2.4.3 + agpgart + 4.1.0 + kmod from 4.1.0
>
> I have the following problem:
>
> when drm loads (from /var/log/XFree86.0.log) it reports that
> it can't register IRQ handler due to another device that have taken it.
>
> it's
Manuel Teira wrote:
>
> El Sáb 22 Sep 2001 18:12, escribiste:
> > Manuel Teira wrote:
> > > Then, I closed my eyes and fired 'gears'. Well, it didn't lock my
> > > machine, the gears window only contained garbage, but the program was
> > > running, and saying:
> > > 1786 frames in 5.002 seconds =
Manuel Teira wrote:
>
> El Sáb 22 Sep 2001 18:30, escribiste:
>
> >
> > You can pass an argument to isosurf to tell it to render only 100 triangles
> > (isosurf -100) - another good option, and you can get it to render more by
> > moving with the arrow keys.
> isosurf, where could I find it?
Me
TAU wrote:
>
> Can you direct me on what should I do to get a cvs version working:
> Where cvs is
> what X11 parts should I compile and where to install
> should I compile anything except i810 kmod for the kernel?
> I can't find any ready RPMs for Mesa 3.5, should I take it directly from
> Mesa s
Michael Zayats wrote:
>
> > > > 1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back
> to
> > > > the driver?
> > >
> > > The irq is removed in the mesa-3-5 branch. If you feel ok about
> > downloading,
> > > compiling and installing a cvs branch, you might be able rid of the
> >
On Sun, 23 Sep 2001 21:48, you wrote:
> Keith Whitwell wrote:
> > > Can I remove irq from the current branch? I have no option in BIOS
> > > that will
> > > disable IRQ for video, but If I had I suppose that DRM would manage
> > > with that. Can I simul
Will Newton wrote:
>
> On Tuesday 18 Sep 2001 7:35 am, you wrote:
>
> > I think it is too early to put a donation page up on the website. Before we
> > can do anything like that a few important details have to be sorted out ...
>
> What are the odds of the project coming under the XFree86 umbre
I'm going to start getting the 3-5 branch uptodate with current cvs using the
old MesaSrcDir technique. I probably won't commit until Brian releases 4.0 &
it is merged across, unless anyone would rather I did so sooner. (Doing so
would require people to revert to the MesaSrcDir technique also).
Jeff, Rik, Others,
Can you please post a description of what the backwards compatibility kernel
code changes are, how they work, what developers are expected to do to keep
them working?
Has this code/technique been ported to the 3.5 branch? Has that been examined
for feasibility?
Keith
__
On Mon, 24 Sep 2001 21:49, you wrote:
> Ok, I've been trying for days to get this sucker working. Here's all the
> important info I can think of:
>
> Running RH 7.1, clean install, everything installed from both discs.
> ASUS A7V motherboard
> Kernel 2.4.2-2
> ATI Radeon 64Mb DDR VIVO card
>
> Her
On Sun, 30 Sep 2001 07:50, Regard Inbox wrote:
> Does current i810 drm accelerate 2D path?
>
No.
Keith
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Dri-devel
On Sun, 30 Sep 2001 09:06, you wrote:
> - Original Message -
> From: Keith Whitwell <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; Regard Inbox <[EMAIL PROTECTED]>
> Sent: Sunday, September 30, 2001 3:59 PM
> Subject: Re: [Dri-devel] glDrawPixels on i81
On Wed, 3 Oct 2001 19:46, Steven Fuller wrote:
> This small patch fixes/works around a problem with tdfxDDTexturePalette
> when glColorTable() is used with a proxy texture (it tries to access a
> non-existent color table).
>
Sorry Steven, I must have missed your earlier patches. Can you resend
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
> The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
> suffice it to say that it results in some, interesting, rendering bugs.
Looks like a cut&paste bug. I'll commit the fix.
Keith
On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
> The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
> suffice it to say that it results in some, interesting, rendering bugs.
>
Actually I think the loop should read
for (i = start; i < count - 4; i+=4) {
ie. a less-th
On Thu, 4 Oct 2001 12:55, Zephaniah E\. Hull wrote:
> On Thu, Oct 04, 2001 at 10:32:15AM -0600, Keith Whitwell wrote:
> > On Wed, 3 Oct 2001 19:19, Zephaniah E\. Hull wrote:
> > > The current mesa-3-5-branch code has a bug dealing with GL_QUADS,
> > > suffice it to
On Thu, 4 Oct 2001 19:40, Dieter Nützel wrote:
> Hello all,
>
> after your latest fixes I've to report the following issues together with
> my Voodoo5 5500 AGP.
>
> First of all:
> Do I have to use the Mesa-4.0 CVS tree?
> Keith what was the name of the path variable, again?
No.
> 1. UT 436 sho
On Fri, 19 Oct 2001 17:24, Leif Delgass wrote:
> Great work! I'll check this out soon.
>
> Once we get DMA working for the 3D operations, I guess the next task is to
> get the 2D acceleration routines synchronizing with the 3D ones so we can
> reenable XAA, right? Also, it looks as if the AGP se
Manuel Teira wrote:
>
> El Dom 21 Oct 2001 04:18, Daryll Strauss escribió:
> > On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
> > > OK. Thank you for the clear explanation. Now I think I'm ready to put the
> > > new branch in the repository. I'm waiting for the access, guys. As soo
Josef Karthauser wrote:
>
> No one responded to this :(. Does anyone know of any problems with r128
> in 2D mode?
>
> Joe
>
> On Wed, Oct 17, 2001 at 03:14:32PM +0100, Josef Karthauser wrote:
> > Hi,
> >
> > I'm using the r128.ko driver with a matrox rage mobility chipset under
> > FreeBSD:
>
"Frank C. Earl" wrote:
>
> On Saturday 20 October 2001 10:18 pm, Daryll Strauss wrote:
>
> > On Sat, Oct 20, 2001 at 07:49:56PM +0200, Manuel Teira wrote:
> > > OK. Thank you for the clear explanation. Now I think I'm ready to put the
> > > new branch in the repository. I'm waiting for the acces
ralf willenbacher wrote:
>
> "B. van den Heuvel" wrote:
> >
> > But will it help if I lower my resolution ?
> >
> yep, and to reduce the color depth.
> its printed in the X log:
>
> (II) MGA(0): Reserved 12288 kb for textures at offset 0x140
>
> but i just realized that my g400 box still ru
"Daniel T. Chen" wrote:
>
> Hi folks,
> I'm attempting to incorporate DRI's mesa-4-0-branch into my
> current X 4.1.0.1 (Debian sid from X 4_1 branch) setup but am running
> into difficulties. I checked out the mesa-4-0-branch and created the build
> tree as the DRI compilation guide inst
Pawel Salek wrote:
>
> On 2001.10.25 10:25 Daniel T. Chen wrote:
> > Actually I just bypassed it by putting in a #define in host.def (thanks
> > [EMAIL PROTECTED]) and a few extra twiddles, and it compiled and installed just
> > fine. Thanks.
> > [...]
> > On 25 Oct 2001, Michel [ISO-8859-1] Dänz
Bill Currie wrote:
>
> On Wed, Oct 24, 2001 at 02:59:11PM -0600, Keith Whitwell wrote:
> > Ralf, I haven't been able to test your patch, but it sounds like it works
> > well for those who've tried it. If you clean it up to include just the agp
> > texture st
ralf willenbacher wrote:
>
> Keith Whitwell wrote:
> > Ralf, I haven't been able to test your patch, but it sounds like it works
> > well for those who've tried it. If you clean it up to include just the agp
> > texture stuff, I can commit it...
> >
&
ralf willenbacher wrote:
>
> Keith Whitwell wrote:
> > Ralf, I haven't been able to test your patch, but it sounds like it works
> > well for those who've tried it. If you clean it up to include just the agp
> > texture stuff, I can commit it...
> >
&
"Carsten Haitzler (The Rasterman)" wrote:
>
> On Sun, 11 Nov 2001 15:17:15 -0800 strobe anarkhos <[EMAIL PROTECTED]> babbled
> profusely:
>
> > Has anybody seen a project or code which renders X11 graphics using OpenGL
> > calls?
>
> evas.
> (canvas library - can use X11, software rendering or
Steve Bergman wrote:
>
> Hi,
>
> I'm having problems with lockups since I upgraded my memory to > 1GB. I
> have reason to suspect that the location of the SAREA (just above the
> 1GB level) is my problem. Does anyone know how to change the address
> that DRI picks for the SAREA?
>
I don't kn
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 driv
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
On Wed, 10 Oct 2001 15:45, [EMAIL PROTECTED] wrote:
> 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 arc
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 (o
>
> 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 */
Jeff, Others,
I've been reviewing the work in the 3.5 branch for backwards compatibility
and to me it looks like we can do it with a lot less effort. Here's what I'm
proposing, in one simple sentence:
Instigate a rule where any released ioctl will always be supported, with the
same s
> Actually 2.5 will see a lot of devices moving away from IOCTLs (even legacy
> ones) as Linux gains namespace support. From the Linus threads I've read,
> even older IOCTLs will be shot down. The unmaintainability and randomness
> of IOCTL numbering schemes is one of the things that brought th
-- Forwarded Message --
Subject: Re: [Dri-devel] Using drm (fwd)
Date: Sat, 13 Oct 2001 16:42:59 -0600
From: Keith Whitwell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
> That's what I am trying to do. With not much luck so far. The reason (at
> least to m
On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
> On Sat, 13 Oct 2001, Keith Whitwell wrote:
> > > That's what I am trying to do. With not much luck so far. The reason
> > > (at least to me) is that the 3d driver is the interaction of 3 parts:
> > > ke
> Well, this explains some things - but not all of them. Perhaps you can
> point out to me where I am wrong ?
>
> First of all, how PCI scatter-gather works: instead of having one
> physically contiguous buffer to DMA in/out, we have a list of page-sized
> buffers and a table (not more than a f
> Yep. What I was trying to understand is that, since I already setup my own
> region, what can I do to it ? For example, how do I get to "AGP
> space" addresses (as oppposed to physical or virtual).
Userspace programs always deal in virtual addresses. You need to map the
section of agp space
>
> Are you sure ? I am asking because there are newer cards with 64megs of
> RAM and they way AGP was marketed is to allow to extend the amount of
> offscreen memory..
The agp aperture is implemented on the motherboard, nothing to do with which
video card you plug in. Some newer chipsets appa
> >
> > I hope I've explained a little better above. You map the agp region into
> > the process virtual address space useing drmAddMap/drmMap, then just get
> > a regular old pointer that you can write to and read from (but reads are
> > very slow because agp is uncached)
>
> Wait a moment - I
On Sun, 14 Oct 2001 12:59, [EMAIL PROTECTED] wrote:
> On Sun, 14 Oct 2001, Keith Whitwell wrote:
> > > Are you sure ? I am asking because there are newer cards with 64megs of
> > > RAM and they way AGP was marketed is to allow to extend the amount of
> > > offs
On Sun, 14 Oct 2001 12:59, [EMAIL PROTECTED] wrote:
> On Sun, 14 Oct 2001, Keith Whitwell wrote:
> > > Are you sure ? I am asking because there are newer cards with 64megs of
> > > RAM and they way AGP was marketed is to allow to extend the amount of
> > > offs
On Sun, 14 Oct 2001 12:59, [EMAIL PROTECTED] wrote:
> On Sun, 14 Oct 2001, Keith Whitwell wrote:
> > > Are you sure ? I am asking because there are newer cards with 64megs of
> > > RAM and they way AGP was marketed is to allow to extend the amount of
> > > offs
On Sun, 14 Oct 2001 14:31, [EMAIL PROTECTED] wrote:
> On Sun, 14 Oct 2001, Keith Whitwell wrote:
> > On Sun, 14 Oct 2001 12:59, [EMAIL PROTECTED] wrote:
> > > On Sun, 14 Oct 2001, Keith Whitwell wrote:
> > > > > Are you sure ? I am asking because there are newer c
On Sun, 14 Oct 2001 22:39, jhartmann wrote:
> Keith Whitwell wrote:
> > Jeff, Others,
> >
> > I've been reviewing the work in the 3.5 branch for backwards
> > compatibility and to me it looks like we can do it with a lot less
> > effort. Here's
On Mon, 15 Oct 2001 11:36, Daryll Strauss wrote:
> On Mon, Oct 15, 2001 at 10:14:33AM -0600, jhartmann wrote:
> > If you have demenstrated that this is the case then we should remove the
> > version system then I guess. I do want to voice my concerns though by
> > writing out my argument fully th
> I suppose I'm basing my assumptions on sarea usage that is not there right
> now (a private sarea per context system rather than the temporary copies
> which we have now), and assuming a full featured t&l card will have
> somewhere around 4-16k of possible state. (WARNING: The following is
> s
> Actually it doesn't acheive anything. There's no pretending that you don't
... There's no use pretending...
> have ioctls that you really do - that's all a versioning scheme can
> acheieve (ignoring the sarea snafu, of course).
Keith
___
>
> LT> Now, we already have one case where this broke, which is why we
> probably
> LT> should have a major version number too, which indicates that things
> start
> LT> from a clean slate. So the old 4.0.x DRM should be called version
> 0.0, and
> LT> the new 4.1 DRM should be called 1.0.
> LT>
> The Radeon 7200 DRI drivers work, but performance is a
> problem. I get roughly 1/2 to 1/3 the performance in
> linux than in windows. I've tried quake3 and unreal
> tournament. In Windows I get about 100fps in UT, as
> opposed to 40 or so in Linux. (Quake3 was even
> worse...) Linux glxgears o
dan wrote:
>
> Hi all. I'm trying to get the Mesa-4 branch to compile. If this isn't
> going to happen now, please excuse me - I will wait. But it's _so_ close...
> I downloaded the mesa_4_0_branch of Mesa and added it to my host.conf
> 'make world' seemed to go OK. At least it got to the end and
Jorge Luis Williams wrote:
>
> Hello,
>
> I've run into what appears to be a dead-lock while running tessellation
> demo by David Blythe which is included in the Glut-3.7 source
> distribution (glut-3.7/progs/advanced/tes.c)
I'll look at this.
Keith
___
Dieter Nützel wrote:
>
> Oh,
>
> I've forgotten to send you a little screenshot.
> It shows some texture/clipping errors, too.
>
I don't have this, and I haven't been able to see anything similar in other
programs. Can you retest?
> > Q3A 1.30 (final)
> > is running at the same speed as with
Bjorn Helgaas wrote:
>
> In the Linux AGP/GART driver, the agp_memory struct contains a memory[]
> array with the physical address of every page in the block.
>
> Currently, the elements of the memory[] array are the actual values put
> into the GATT, i.e., they contain the valid bit and any oth
> Please, beware of another problem with AGP. Several chipsets including
> Apple's UniNorth or some ia64 ones can't let the CPU access the AGP
> aperture. So the kernel has to map real physical memory pages into
> the process space when mmap'ing bits of the aperture. That makes
> very difficult t
Philip Brown wrote:
>
> On Mon, Dec 10, 2001 at 05:53:32PM -0800, Gareth Hughes wrote:
> > On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote:
> > > ...
> > > But... isnt there a straightforward mmap type way to access the RAM on
> > > board the card, then?
> > > Or is it usually "load
Philip Brown wrote:
>
> On Mon, Dec 10, 2001 at 12:05:47PM +0200, Abraham vd Merwe wrote:
> > ...
> > It is not always necessary to memory map the device. For instance with the
> > I810 driver, just plain 2D, there is no need to mmap the device, but the GTT
> > (or GATT if you wish) must be popul
Jorge Luis Williams wrote:
>
> Hello,
>
> I've run into what appears to be a dead-lock while running tessellation
> demo by David Blythe which is included in the Glut-3.7 source
> distribution (glut-3.7/progs/advanced/tes.c)
>
> I've been able to reproduce the problem on two different Intel Pen
Keith Whitwell wrote:
>
> Jorge Luis Williams wrote:
> >
> > Hello,
> >
> > I've run into what appears to be a dead-lock while running tessellation
> > demo by David Blythe which is included in the Glut-3.7 source
> > distribution (glut-3.7/
Keith Whitwell wrote:
>
> Keith Whitwell wrote:
> >
> > Jorge Luis Williams wrote:
> > >
> > > Hello,
> > >
> > > I've run into what appears to be a dead-lock while running tessellation
> > > demo by David Blythe which i
Alexander Stohr wrote:
>
> > > Sure, an app can always elect whether or not it uses
> > particular extensions.
> > > Maybe I'm missing your point.
> > "An app"? Probably. But some particular (very nice, BTW) apps
> > still very
> > dumb in terms of configuration so I'd like to have ability to tur
Bill Currie wrote:
>
> this is for mesa-4-0-branch, current cvs + mga agp texturing patch (minus the
> bits for mgavb.c: they didn't apply).
>
> http://taniwha.2y.net/~bill/qf011.png shows the bug nicely. The black to white
> gradient areas should be solid black (they are in trunk). It looks lik
Bill Currie wrote:
>
> this is for mesa-4-0-branch, current cvs + mga agp texturing patch (minus the
> bits for mgavb.c: they didn't apply).
>
> http://taniwha.2y.net/~bill/qf011.png shows the bug nicely. The black to white
> gradient areas should be solid black (they are in trunk). It looks lik
Bill Currie wrote:
>
> This patch fixes undefined symbol errors for _compat_FogCoordfEXT (and likely
> _compat_SecondaryColor3ubEXT and _compat_SecondaryColor3fEXT but I didn't
> bother checking to see if they caused problems).
They are defined in api_compat.c. You probably need to do a make Ma
Daryll Strauss wrote:
>
> On Fri, Dec 21, 2001 at 04:05:33PM -0800, Philip Brown wrote:
> > I have a question about "what if physical memory is fragmented"?
> > The AGIPIOC_ALLOC call returns a 'physical' address.
> > This implies that the ALLOC is a single contiguous chunk of physical
> > memory
Fray Bentos wrote:
>
> Forgot all about sending this in
>
> Fixes the HP_OCCLUSION_TEST on voodoo (5500) hardware.
>
> Basically the FIFO needs flushed, otherwise you can end up getting the
> result from a previously rendered geometry.
>
> Also modified to handle a query on a polygon that
Carl Busjahn wrote:
>
> I think the question is not wether they want to kill openGL or not.
> Microsoft doesn't have anything to replace openGL therefore they are
> not capable of killing it even if they wanted to. I wish people
> wouldn't get excited about this, because SGI wouldn't be stupid
Karl Czajkowski wrote:
>
> We have one particularly brute-force application that draws large
> batches of points (millions per frame) with low alpha value using an
> acculative blend mode and no z-buffer. I am curious what kind of
> performance is expected through the DRI in the long run.
>
> U
Lynn Quam wrote:
>
> 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 pl
Lawrence Gold wrote:
>
> Hi,
>
> Back in June 2001, Karl Lessard posted the following patch to the mailing
> list:
>
> http://www.geocrawler.com/lists/3/SourceForge/680/0/5955984/
>
> Are there any plans to incorporate this? I perused the latest CVS sources
> and wasn't able to find t
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
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
"Sottek, Matthew J" wrote:
>
> 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
Panagiotis Papadakos wrote:
>
> A better patch without whitespace changes...
>
> --- lib/GL/mesa/src/drv/mga/mgatexmem.c Sun Jan 27 12:59:37 2002
> +++ lib/GL/mesa/src/drv/mga/mymgatexmem.c Sun Jan 27 13:12:48 2002
> @@ -254,8 +254,18 @@
> idx != MGA_NR_TEX_REGIONS && nr < MGA_NR_T
Jose Fonseca wrote:
>
> On Mon, 2002-01-28 at 14:17, Jens Owen wrote:
> > ...
> >
> > Perhaps this question could be answer in our new FAQ. I've seen it
> > frequently.
> >
>
> Okay. I'll add a summary of what was said in this thread into:
>
> Harware / ATI / Radeon 8500 / What are the plans t
Vladimir Dergachev wrote:
>
> On Wed, 30 Jan 2002, deek wrote:
>
> >
> >
> > Vladimir Dergachev scribbled:
> >
> > > <__snipped_>
> > >>
> > >
> > > I've implemented this (easier than software CCE) scheme. If you want to
> > > please try the latest ati.2 CVS code at http://gatos.sf.net - or just
Vladimir Dergachev wrote:
>
> On Wed, 30 Jan 2002, Daryll Strauss wrote:
>
> > On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote:
> > > Regardless of the way it is merged the driver major version will need to
> > > be bumped. GATOS drivers does this but only minor - as I did not
Daryll Strauss wrote:
>
> On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote:
> > I completely agree with you.. but I did not give you details :))
> >
> > What happens is that if you try to use older drm driver with GATOS 2d
> > driver the GATOS driver will notice and complain. Bu
1 - 100 of 1259 matches
Mail list logo
