_
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
//========\\
|| D. Hageman ||
\\//
-mail to the dri-devel mailing
list.
On Tue, 15 Mar 2005, Felix [ISO-8859-1] Kühling wrote:
Am Dienstag, den 15.03.2005, 10:36 -0600 schrieb D. Hageman:
I have made a RPM, SRPM and SPEC file of driconf available. The RPM
was made under Fedora Core 3. The link is in the Download section on
this
sy to modify the SPEC file to make it work for you.
//\\
|| D. Hageman ||
\\//
---
SF email is sponsored by - T
I just finished updating my CVS tree and rebuilding ...
No updates for Mesa showed up, but several for the r300 driver did. I no
longer experience the lockups I was having with lesson01.
I will continue to test ...
On Mon, 31 Jan 2005, D. Hageman wrote:
My tree that I built with was updated and
Mon, 31 Jan 2005, Vladimir Dergachev wrote:
On Mon, 31 Jan 2005, D. Hageman wrote:
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
The speed reported by glxgears has improved by about a 100 frames a second
over what it was last weekend.
I have started to go through the lessons at nehe for
ati fragment program
stopped the lockup.
I am going to continue on this path of testing and will let you know what
I find.
//\\
|| D. Hageman
primitive 08 - help me !
4311 frames in 5.0 seconds = 862.151 FPS
4356 frames in 5.0 seconds = 871.109 FPS
4210 frames in 5.0 seconds = 841.978 FPS
4333 frames in 5.0 seconds = 866.465 FPS
//\\
|| D. Hageman
On Sat, 15 Jan 2005, Adam Jackson wrote:
On Saturday 15 January 2005 13:56, D. Hageman wrote:
I just got done with the second try at this. I pulled the Mesa and
r300_driver cvs trees this morning and recompiled. The only hitch was
that apparently some changes have happened to the radeon and r200
:
agpgart: Found an AGP 3.0 compliant device at :00:00.0.
agpgart: Putting AGP V3 device at :00:00.0 into 4x mode
agpgart: Putting AGP V3 device at :01:00.0 into 4x mode
[drm] Loading R300 Microcode
On Sat, 15 Jan 2005, Vladimir Dergachev wrote:
On Sat, 15 Jan 2005, D. Hageman wrote:
5 Jan 2005, Peter Zubaj wrote:
Did you get latest CVS x.org source with support for r300 ? Or did you patch
it with ati.patch from r300_driver ?
D. Hageman wrote:
<
I just got done with the second try at this. I pulled the Mesa and
r300_driver cvs trees this morning and recompiled. The only h
On Fri, 14 Jan 2005, Vladimir Dergachev wrote:
On Fri, 14 Jan 2005, D. Hageman wrote:
I took the time to compile the r300 driver and give it a whirl.
The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility
9600 M10. It has a device ID of 0x4e50.
glxgears runs with a 370-380 FPS
match the screenshots.
I see that some changes have went into CVS today so I will take the time
to compile those tonight. If you have something specific you want me to
try with this hardware let me know.
//====\\
||
On Wed, 19 Feb 2003, Brian Paul wrote:
> Felix Kühling wrote:
> > Hello list,
> >
> > D. Hageman and I have been bouncing a design document for the new
> > configuration infrastructure back and forth in private mail for the past
> > week. Now we think
On Mon, 17 Feb 2003, Mike A. Harris wrote:
> On Sat, 15 Feb 2003, D. Hageman wrote:
>
> >> I think spam filtering for dri-devel and dri-users would be a good
> >> solution -- IMO, that would be better than moderation. For dri-patches,
> >> the Reply-To is dri-de
On Sun, 16 Feb 2003, Philip Brown wrote:
> On Sun, Feb 16, 2003 at 05:55:55PM -0600, D. Hageman wrote:
> > > So, why not do it by PCI vendor/devid ? That sort of information is visible
> > > from the DRI level, I believe. I think its just another Xserver internal
> > &g
On Sun, 16 Feb 2003, Philip Brown wrote:
> On Sun, Feb 16, 2003 at 02:00:01PM -0600, D. Hageman wrote:
> > On Sat, 15 Feb 2003, Philip Brown wrote:
> > > I think this is a much cleaner overall design.
> > > After all, you dont open /dev/fbX and tell it,
> > >
accept that spam happens. I think the digest format is just for people
who can't setup mail rules anyway. :-)
A nice sourceforge option would be to be able to purge unwanted e-mails
out of the archives.
>
> On Sat, 15 Feb 2003, D. Hageman wrote:
>
> >
> > I
On Sat, 15 Feb 2003, Philip Brown wrote:
> On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote:
> >... We played around with using Screens and driver
> > names, but in the end we were looking at keying off the device identifier.
> > At this time I still believe t
gt; the Reply-To is dri-devel. I'd rather have just commit messages and
> nothing else on dri-patches. Any comments/replies to specific patches, or
> posts dealing with CVS should go to dri-devel anyway. That's why I
> suggested limiting just dri-patches to sourceforge addresses.
&
* busIdString;
This option would set in the DRIScreenInit much like the busIdString is
set during initialization. Does anyone see any issues with this or does
anyone have any technical objections on why this shouldn't be done?
--
//\\
tify allocated AGP regions. I don't know why the DRM module
> doesn't do the same, since the key is guaranteed to be unique.
> The patch below changes the handle to be the "key" value.
>
> I'm wary of making changes like this so close to
On Tue, 28 Jan 2003, Ian Romanick wrote:
> D. Hageman wrote:
> > On Tue, 28 Jan 2003, Ian Romanick wrote:
> >
> >>How do we want to handle the case where a user changes video cards?
> >>Some of the parameters are likely to be generic, but a lot will be very
>
the
> driver and present the user's prefered langauge, if available. As we
> shift to a Joe User mindset, internationalization will become more and
> more important.
Good call!
--
//\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\=
the configuration utility know what is up. The ... is just my way of
saying so on and so forth.
--
//========\\
|| D. Hageman
Jan 2003 02:55:22 -0600 (CST)
> "D. Hageman" <[EMAIL PROTECTED]> wrote:
> >
> > > So what are the "technical" advantages of XML in this case?
> >
> > Quick List --
> >
> > *) Text Based - easy to edit.
>
> Text based does
On Tue, 28 Jan 2003, Dieter Nützel wrote:
> Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman:
> > On Mon, 27 Jan 2003, Philip Brown wrote:
> > > I am trying to point out that none of
>
> [-]
>
> > > On the other hand,
> > > "DRI is meant
at it is spending more time
applying the XSLT to the document then actually "loading" the document if
you run some tests.
--
//=
On Tue, 28 Jan 2003, Sven Luther wrote:
> On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
> >
> > I think you misunderstand. We aren't replacing the XF86Config file here.
> > This is for DRI specific driver settings with capabilities extending to
>
gt; the x server itself uses?
No - as stated above it is a custom built parser with very specific
operating parameters. You can look at it yourself in the XFree86 tree and
you will see what I mean.
--
//\\
|| D. Hageman
y on your box. It is a library.
You can link it statically or dynamically. If you link it dynamically a
future upgrade may break things. All programs on your box that use shared
libraries have the same issue. If it is a major issue for some group of
people then static linking
editor, too. But the percentage
> of DRI users that can usefully DO that, is a very small number, comparative
> to the overall number of users.
Hence the GUI ... I think I have covered all the arguments that needed to
be addressed.
Seri
on + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
//
rd from DRI CVS.
--
//====\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
ht
On Sun, 29 Dec 2002, magenta wrote:
> On Sun, Dec 29, 2002 at 08:06:58PM -0600, D. Hageman wrote:
> > >
> > > I know that my engine Solace (http://www.cs.nmsu.edu/~joshagam/Solace/)
> > > causes such artifacts... my guess is that it happens when playing back a
>
all drivers are included. They are made from a modified version
of Mike Harris's SPEC file.
Let me know.
--
//\\
|| D. Hageman<[EMAIL P
nshot could change the Solace
> setting of GL_draw_method to 0 (which switches to immediate mode rendering
> rather than using vertex arrays) and see if that continues with the
> funkiness, that would be another useful data point. :)
Switching the GL_draw_method to 1 gave me ... from wh
that I could run to reproduce these on my system?
--
//========\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
---
This sf.net email is sponsored by:Th
tp://thinkgeek.com/sf
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
//\\
|| D. Hageman<[EMAIL PROT
s me to do that, but in
many ways it is understandable. You must pick your battles to fight
wisely.
--
//\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
---
se the common radeon macros was pulled out into this
seperate file. Not sure if it was worth the effort. It should be in the
ati directory under the Xserver driver tree. Make sure it is there.
--
//========
ut 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
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 d
; > chose for XFree86-4.3,
>
> I'd mostly agree, but I guess the floating point exceptions are
> showstoppers.
>
>
>
--
//===
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?
On Wed, 11 Dec 2002, Alan Cox wrote:
> On Wed, 2002-12-11 at 20:12, D. Hageman wrote:
> > I have noticed some feedback from Alan and Linus already on this
everything is up to par with what they want
from their feedback.
I have noticed some feedback from Alan and Linus already on this list. Is
anyone taking care of things yet?
--
//\\
|| D. Hageman<[EMAIL PROTEC
[dhageman@moko r200]# grep xf86usleep *
Binary file r200_dri.so matches
Binary file r200_ioctl.o matches
Binary file r200_texmem.o matches
I have also attached the compiler output for the compilation of that
directory.
On Mon, 9 Dec 2002, Keith Whitwell wrote:
> D. Hageman wrote:
>
ess to the xf86* symbols? If not, then should we
stick in -DDONT_DEFINE_WRAPPERS to ensure that this doesn't happen?
On Mon, 9 Dec 2002, D. Hageman wrote:
>
> I finally got a momment this weekend to build the CVS tree since I had not
> done it since 11/22. My usual build proc
--
//\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PRO
most of the work is
that *they* have done most the work and by all rights should have the most
say in what happens. If you think you can code up an OpenGL wrapper that
can do just this in a short amount of time why don't you code one up as a
demo case. We can try it out, see how it
reated in each driver causing your so called
inconsistancies. I think we all know what we want, but getting there is
just going to have to take some friendly debate and in the en
On Wed, 4 Dec 2002, magenta wrote:
> On Wed, Dec 04, 2002 at 02:30:31PM -0600, D. Hageman wrote:
> > On Wed, 4 Dec 2002, magenta wrote:
> > >
> > > Actually, I just thought of a solution which could possibly satisfy all
> > > three camps: have a libGL wr
of user
friendliness as well.
Next please ...
--
//========\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
---
This SF.net
operate on the "grouped" settings.
It provides a nice balance between those that can tweak things and those
that just want the basics. The duty is left up to the people doing the
GUI part of things. The core DRI team just has to
a configuration file isn't
> signifigantly more than the amount of code needed to check the various
> environment variables.
>
>
--
//
up page dedicated to
turning this on or this little thing off, etc and so forth. It is okay to
do this kind of stuff with games and what not, but not every program needs
that level of sophistication. I think being able to have a 3rd party app
that would be able to tweak driver options wouldn&
On Wed, 27 Nov 2002, Brian Paul wrote:
> Brian Paul wrote:
> > D. Hageman wrote:
> >
> >> Is anyone else experiencing unresolved symbols from GLcore from CVS?
> >>
> >> It seems that it can't resolve fabsf and xf86strncat (or some variant
> &g
it go
... or at least see if I can get some more information to debug with.
--
//\\
|| D. Hageman<[EMAIL P
cenerio there of course).
--
//========\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek he
Scott's patch is also included in the one that I sent, so maybe wording it
as an addition to wasn't the best wording. The patch that I sent in is a
comprehensive patch of all the changes needed to get DRI to work on the
9000s.
On Mon, 4 Nov 2002, Keith Whitwell wrote:
> D.
l add CHIP_FAMILY_M9 to the list of chipsets that can use the
r200 driver.
Note: This diff is from the most recent "unified" ATI driver in the main
XFree86 trunk, so the line numbers may be off a couple of lines for the
DRI tree.
--
//=======
:10 moko last message repeated 2485 times
Attached is my XFree86.0.log ...
Any ideas would be appreciated ... I will continue to play on my end and
see what I can come up with.
--
//========\\
|| D. Hageman
61 matches
Mail list logo
