> From: "Marco Strack" <[EMAIL PROTECTED]>
> ok, changed the code and recompiled the source.
>
> Now the drm module recognizes the card and inits it.
[...]
> in X log :
[...]
> this is drm stuff :
>
[...]
> (**) SAVAGE(0): DRI is enabled
> (II) SAVAGE(0): virtualX:1400,virtualY:1050
> (II) SAVAGE
try reproducing that problem in the diretory on the commandline by hand.
remove one qualifier after the other until the problem vanishes.
also try replacing the `...` expression with 0 or 1.
try running that sub expression separately.
sometimes such problems cannot be tracked down other than
at t
in the past Valgrind was likely to choke on anything
but pure gcc generated assembler and binary code.
this means an sort of hand coded assembler,
non-default calling convention and alikes
could bring that checker to a halt.
to my best knowledge you could not even guide
that tool to ignore speci
the admin list got this,
i think it is ment to the main list.
forwarding it now, just to get it right...
-Original Message-
From: TA [mailto:[EMAIL PROTECTED]
Sent: Monday, December 08, 2003 19:55
To: [EMAIL PROTECTED]
Subject: S3 TwisterK...
Hi DRi Team!
I've got a notebook with S3 T
just a few words for the future, nothing serious...
> -Original Message-
> From: Christopher Gleba [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 23:02
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Dri-devel] mach64-0-0-6-branch dri bug report
> Size: 220 k
not beeing totally deep into the drm-radeon driver...
excerpt of agp command register,
when chipset is in AGPv3 mode:
bit 3, value 8: reserved
bit 2..0, value 0: agp transfer mode not yet programmed
value 1: agp transfer mode 4x
value 2: agp transfer mode 8x
sorry for going off topic now, the following
is not tightly related to dri development works
but only to the embedding reallity in the real
world of software development.
> From: Pawel Salek [mailto:[EMAIL PROTECTED]
> for recently released game "Savage" that was even
> announced on Slashdot. I
comments inline...
> From: Carl Switzky
> I'm new to this list, so please excuse me if this topic has
> been exhaustively discussed, or if it is not appropriate.
> I didn't see any way of searching the archives.
There are archives, see dri.sf.net, page Mailing lists
for the links.
> I'm interes
TECTED]
> Sent: Thursday, November 20, 2003 17:16
> To: Alexander Stohr; Alex Deucher
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Dri-devel] Fwd: Your message to Dri-devel
> awaits moderator
> a pproval
>
>
> I get it too, maby letters and then numbers if it's not just
you were the only one that hit those problem.
i only have the very same problem report.
the rest is driven by source forge internals.
maybe its the yahoo origin paired with a
quite random looking user name since you
are using your initials.
-Alex.
> -Original Message-
> From: Alex Deuch
Hello,
i stumbled across the above mentioned define and
related code in the XFree86 sources (lnx_video.c).
comparing X4.1.0 and X4.3.0 i found that the
condtitnal coding of "if (base % size)" has
vanished at some point in time and the handling
is now hardcoded at this code location.
to my best k
just if thas a pending duty...
if the monitor refreshes at 75 Hz
then the grafics adapter has no need
for producing more then 75 frames per second.
having images updated before the cathode ray
has finished one image leads to showing two
images in a single refresh cycle which looks bad.
if you ar
John,
i gave your code a short review and found nothing worth a note.
In other words, if there is a problem at all
then i've overlooked that due to the speed i browsed it.
One thing to ask you: there is always those secondary PCI ID
on the current Radeon designs. Do you see some chance to get
ri
i want to propose to integrate a link
to the new WIKI pages to the Help & FAQ
section of the DRI homepage.
further there was some sort of uncertainty
to which XF86 version the current driver
snapshots do apply. maybe some clarificatiion
is needed in that area.
as Liam is possibly unavailabel for
GART range a physical bus address including a size value,
which will get fixed up by PCI config process in BIOS.
It should not need any touching at a later time on sane systems.
It can be reprogrammed in most cases but only with full system awareness.
I dont know a regular reason why to do that on
The mainboard chipset provides two things in respect to the keyword AGP.
- a high speed bus interface to the graphics controller
- a memory paging uint exposed to the graphics controller and the CPU
the 2nd is just a remapped view of the main memory,
resembling some/any page of main memory in a
Maybe the printed strings in your patch should
mention the "SE" so that no one gets confused.
Anything else looks smooth to me right now.
-Alex.
> -Original Message-
> From: Michel Dänzer [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 13, 2003 22:08
> To: #NGUYEN THANH NAM#
> Cc:
> I did some basic work on factoring out the common code and
> discussed it
> with Thomas Winischhofer (Sis maintainer and driving force behind
> mergedfb development). He is of the opinion that it is still
> too early
> to create a generic API for mergedfb. There is still no consensus on
> wha
CP mode means using an engine on the chip
that gets the command data from main memory
by itselves, some sort of busmaster DMA stream.
MMIO means that the driver does program the
chipset directly via its memory mapped registers.
DRI means direct rendering and is the most common
socket for current
why wont the module compilation still pass
when SIS fb configuration flags from the
Linux kernel configuration are missing?
sorry if that requirement is already
mentioned in the readme. i am just wondering.
-Alex.
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]
> Sent: Su
all info contained below is my personal opinion,
should be retriveable from several pbulic sources
and it is only accurate to my best knowledge.
> linux/pci_ids.h and xf86PciInfo.h are in disagreement
> for several Rage128 PCI ids. Xfree appears to be
> correct and the kernel file is wrong. This i
can someone answer this request for DRI tarballs?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 21, 2003 08:27
To: [EMAIL PROTECTED]
Subject: AW: Request to mailing list Dri-announce rejected
Importance: High
Hello Admin,
Thanks for your anser
Hello,
dumb question but might help in resolving
those well known pending problem with tux racer:
Is there any way to run tux racer on the win32 platform?
i know you can run nearly any win32 game on linux by using
Wine or WineX - but i do want to go the opposite direction.
for simple textmode bi
i am reading the list and i have not seen a fix for this.
maybe the root cause is somewhere else,
like using an uniprocessor config of an alternate CPU
or a non current CPU desing ( -Original Message-
> From: Warren Turkal [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 04:54
> To
seen that bunch of notifications
and added a respective phrase to
the setup. lets see if that was it.
-Alex.
> -Original Message-
> From: José Fonseca [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 19, 2003 02:28
> To: Alexander Stohr
> Cc: [EMAIL PROTECTED]
> Subje
for dri-announce, dri-devel, dri-users, dri-patches
i have now enabled the mailman option "member_posting_only".
this is done for stopping the major portion of spam
as we have seen it coming via the list in recent times.
dri-announce already was set to the aproval plight,
so there wont shift anyth
for dri-announce, dri-devel, dri-users, dri-patches
i have now enabled the mailman option "member_posting_only".
this is done for stopping the major portion of spam
as we have seen it coming via the list in recent times.
dri-announce already was set to the aproval plight,
so there wont shift anyth
try testing with the possible release-candidate
drivers form www.schneider-digital.de for your purposes.
it might be that the fglrxconfig program does fail the
detection of R350 based boards (like the ATI Radeon 9800),
simply ignore any such message and give `startx` a try.
if drivers do reject
> I've been a bit slack with it recently, so the numbers of
> posts have just
> been sitting there. You get daily reminders of how many are
> in the queue
> waiting for your attention too. But to be managed properly you need to
> tend to them on a daily basis.
>
> Alan
I have no problem taking
In response to the attached list of spam
(18 spam e-mails to dri-devel in only 3 days!)
i have to ask if the dri-devel mailing list
can now be set to subscribers-only policy?
i dont feel thats any longer acceptable.
that daily mailbox digging is really a hoax.
-Alex.
From: Myrtle Elliot [mail
on the web page, titled "CVS fro the DRI",
linked via "CVS Web Page" on the documentation page
there is a comment for the mesa-4-0-4-branch
with states:
"A Stable branch to be included in XFree86 4.3"
XF86 4.3.0 is already out a few months,
so that line obviousely needs an update.
-Alex.
Is the "subsribers only" policy now established?
(lets hope that, i do agree with that)
And the non-subscriber settings tuned to a
"notification about adminitrator decisison" policy?
(that would not be a friendly act even to non-subscriber)
/me really wonders why the sourceforge servers
do not
below is a sample how other lists do handle
list submissions from non subscribers.
on a second place i know that the adminstrators
eased their job by setting a maximum hold time
after which the mail will be passed trough
unless an admin has canceled its delivery.
I would further like to know if
o that this conflict is solved.
-Alex.
> -Original Message-
> From: Ove Kaaven [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 13, 2003 20:25
> To: Alexander Stohr
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Dri-devel] ATI reference drivers
>
>
>
The updated package might be for X4.2.0 whilst you have still portions
of X4.1.0 on your system. That mixed up system revokes to run.
Install a consistent XF86 environment and then install the _matching_
drivers.
-Alex.
-Original Message-
From: Nitin [mailto:[EMAIL PROTECTED]]
Sent: We
i dont know about that.
i cant verify, i have no such hardware.
-Alex.
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 13:59
> To: Alexander Stohr
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Dri-devel] ATI reference driv
hands,
so i cant test anything at all with that.
-Alex.
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 13:59
> To: Alexander Stohr
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Dri-devel] ATI reference drivers
>
>
&g
> I really would like to buy an ATI card (9100 or 9500), but
> with no driver
> support I'll have to stay with Nvidia cards.
>
> Hope you have some info for me.
>
> Best regards
> Michael Born
9500 is a r300 based design and is nicely supported.
9100 is a r200 based design and is nicely suppor
first let me separate the framebuffer data from GL data
by four more spaces.
> > MGA
> > r g b a amaskbsz ar ag ab aa Xvisual dpth
> > 5 6 5 0 16 16 16 16 0 16
> > 8 8 8 8 32 16 16 16 0 24
> >>>
> >>> alphaMask should be 0xff0
> I would just add that if you're using a kernel that uses a
> better source
> directory naming scheme (e.g. 2.4.19 unpacks to linux-2.4.19 whereas
> 2.4.18 unpacks to just linux), you'll want to use the
> TREE=/usr/src/linux-2.4.XX/include option in your make
> command. Like so:
>
> make -f
> /usr/bin/ld: cannot find -lXpm
> collect2: ld returned 1 exit status
> make[6]: *** [xf86cfg] Error 1
> make[6]: Target `all' not remade because of errors.
check for existance of files
./lib/libXpm/libXpm.so*
and
./exports/lib/libXpm.so*
I assume those were not built or were cleaned up unin
Title: RE: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful?
> > My question is, what are the gottchas of having the DRM run
> in a 64-bit
> > kernel and the rest of the driver run in either a 32-bit
> application or
> > a 64-bit application? Will it even matter? If it will
> m
Title: RE: [Dri-devel] Newer Radeon cards and ATIs driver
> On Wed, Jan 22, 2003 at 06:15:13PM -0800, magenta wrote:
> > good, though there's a LOT of apparent bugs in lighting and
> stencils; I'm
> > going to probably be annoying the hell out of Alexander
> S
Title: RE: [Dri-devel] Newer Radeon cards and ATIs driver
have you tried parsing the extension strings?
have you tried getting the function entry points
with the gel/glx-get-by-name functions?
That far that i am aware of, the Linux driver
exports nearly the same set of extensions as
the w
Title: RE: [Dri-devel] [ANNOUNCE] AGPGART Version 2.0
please note that normally a PCI device that does represent
a PCI to PCI bus bridge should carry the AGP-caps registers
if it does support AGP transfer protocoll.
please further note that thare are already lots of systems
out there where t
Title: RE: lockups w/ AGP 4x
> > My system is a Mobile P-4 1.8 ghz with a 16 MB 4x AGP [ATI Radeon] M7.
> > I would like to inform you that I have found the solution to the
> > above-mentioned problems. These problems occur in several branches of
> > XFree86 starting from about one-and-a-h
Title: RE: [Dri-devel] R200 notes & issues
> >> There are sporadic rendering bugs in FlightGear, however.
> Every ~40
> >> frames or so, I'll see a large triangle or two flash on the screen.
>
> > Like these ones ?
>
> > http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4_3.png
>
Title: RE: [Dri-devel] S3TC
sorry, you are so false in several important points
that i have to reply to you in public via the list.
andy ross wrote:
> magenta wrote:
> > But they're not transferring the license to others, they're just
> > providing a reference implementation. nVidia thems
Title: RE: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
Accoding to the official Linux pci database at
http://www.yourvote.com
the strings in the table should be:
INTEL_I845,
"Intel",
"i845 E/MP/MZ",
and
INTEL_I845_G,
"Intel",
"i845 G/GL/GV/GE/PE",
I think that would bring a
Title: RE: [Dri-devel] Wrapper library stuff (was: Re: Smoother graphics with 16bpp on radeon)
> From: magenta [mailto:[EMAIL PROTECTED]]
>
> Another note: A third-party tweak library could conceivably
> convert calls for S3TC functionality into appropriate calls for
> ARB_texture_compressi
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon
The layer idea is not bad,
but its more the taste of a hack.
Remember that dri is OpenSource,
so you dont need those hacks.
As soon as you start with that you will notice that a layer
will increase distance between your applicatio
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon
> > What about remote indirect rendering? Someone else has
> already mentioned
> > that the driver would have no way of getting environment
> variables in that
> > case.
>
> Remote indirect rendering is a problem no matter how
Title: glTune Proposal (was RE: [Dri-devel] Smoother graphics with 16bpp on radeon)
I was reading almost 80% of the discussion
and want to give you a quite "bold" sheme
of how that all can be handled in terms of
a real world system:
You'd write an extension to the drivers that
advertises all
Title: RE: [Dri-devel] Radeon x86 PCI [Was: help selecting a graphics
> > I don't think PCI cards work less stably than AGP cards per
> se, [...]
>
> One could pretend the Radeon driver isn't stable anyway so
> people adding PCI
> support would not change that ;-))
Can you consider code
dri-lists
from any unwanted traffic. Do not reply here!
For the sake of feedback use the ATI web-support form
in the first row, http://apps.ati.com/linuxDfeedback/.
Anyways those drivers are labled "unsupported".
-Alex.
-----Original Message-
From: Alexander Stohr [mailto:[EM
Title: RE: [Dri-devel] CVS issue - unresolved symbols from GLcore?
> I did notice that rendering has
> slowed down on the r200 driver by a magnitude of about 5
> times. This of
> course isn't a very accurate measure purely based of glxgears
> frame rates,
> but it does make me raise an e
Title: drmOpen coding is incomplete
drmOpen tries opening the drm device two times,
but on second try it does "trash" that file handle
in the case of success. the below patch does
add the missing return statment for this case.
-Alex.
PS: the patch should nicely apply to current
XF86
Title: RE: [Dri-devel] Re: New ATI FireGL drivers announced
> I used stock SuSE 2.4.19-4GB kernel optimized for Athlon processors.
Please try using a stock kernel.org kernel in the mean time.
There might be need for us to check
if there is a patch in the SuSE kernels
that do impact system
Title: RE: [Dri-devel] New ATI FireGL drivers announced
> What about support for other architectures, in particular PPC?
The Apple as the #1 PPC platform (okay there might be several others)
does have an AGP slot and to my knowledge there is a nice ATI history
for the MacOS. Not bad the idea
Title: RE: [Dri-devel] Re: New ATI FireGL drivers announced
> Hi, Alexander!
>
> It's a great news that ATI is making Linux driver for R200
> boards,
for completeness its: R200/RV250/R300/some-Mobility
> At first I attempted to set up SuSE's xfglrx package to get
> 3D acceleration
> f
Title: RE: [Dri-devel] New ATI FireGL drivers announced
> Hi
>
> Does this driver works with Powered By Ati cards??
> The previus driver didnt work giving the error that is not a
> Build By Ati card.
Just to get rid of any such querys now...
The state is unchanged:
ATI Boards (PCB a
Title: RE: [Dri-devel] New ATI FireGL drivers announced
> By reading the readme, xinerma+dri is not yet supported. Is support
> planned for this? if so, when?
To be honest, i just dont know because i am
not that deeply involved in 2D development.
Anyways, i wouldnt be allowed to talk abou
Title: New ATI FireGL drivers announced
Hello,
i know that DRI is targeting open source development,
but i know myselves that for a developer there can
always be a need for a 2nd source driver reference.
There are several other reasons why an alternate
Linux driver might be of interest for t
Title: RE: [Dri-devel] mesa 4.1 branch / NO go on 2.5.48
> >
> > > GL_RENDERER: Mesa X11
> > > GL_VENDOR: Brian Paul
> >
>
> Yeah, that seems to be true for the mesa test programs I installed.
>
> Doing a regular glxinfo shows
>
> OpenGL renderer string: Mesa DRI R200 20021
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
> > Nice sheme - this will even allow to check the software paths
> > by just tuning the GL version (e.g. via environment variable).
> >
> > But what will you do if your software path is not yet covered
> > by a specific OpenG
Title: RE: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue
> From what I have been told, this is how it works on the
> Nvidia drivers. I
> have not verified this first hand.
>
> if ( extension string contains "GL_EXT_texture3D" )
> 3D textures are hardware accelerated
>
Title: RE: [Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
> >Its c code, so I don't think the version of gcc is that
> important, what
> >matters is the GLIBC_2.3 symbol, it doesn't show up in the X driver,
> >because it isn't linked against libc, howe
Title: RE: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems
> Hi! here is my problem: I was using the drm drivers wich
> comes with the 2.4.19 kernel (1.1.1),
Sounds stable for me, and compatible to XFree86 4.x.x versions.
> it was workig "right" exept fo this:
>
> (II
Title: RE: [Dri-devel] Spam on this list, list email addresses are out in the open.
Set ML submission to moderated for non-subscribers
and few persons that check the backlog regularily.
Further add e.g. a 24 hours timeout (if possible),
so that nothing gets stuck unclassified forever.
This
Title: RE: [Dri-devel] nForce and AGPGART
Can you please send the outputs of
`lspci -v -xxx` to the list?
> -Original Message-
> From: Rene Sepulveda [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 08:27
> To: [EMAIL PROTECTED]
> Subject: [Dri-devel] nForce and AGPGART
> I'm planing on
> having DRISUP_BOTH, DRISUP_BSD, DRISUP_LINUX, DRISUP_NONE
> defined for the 3rd element.
I dont like the "both" thing. The design looks for me rather
like a bitfild than an enum... so this would be the solution:
(DRISUP_BSD | DRISUP_LINUX)
a DRISUP_ALL would make more s
> I just set up a 2nd PC and ssh'd into mine and ran Tribes 2.
> My original post said that the lockups occur within 5 seconds of 3D
> rendering starting. That's not quite correct.
> The lockups occur only after I move the mouse (which moves
> the 3D scene
> around). But anyway ...
> /var/log/X
> Meelis Roos wrote:
>
> > $ glxinfo
> > name of display: localhost:10.0
> > Xlib: connection to ":0.0" refused by server
> > Xlib: Client is not authorized to connect to Server
> > display: localhost:10 screen: 0
> > direct rendering: No
> >
> > If the display is different from :0.0 (:1.0, r
> On Saturday 06 July 2002 20:38, David Willmore wrote:
> > Well, I've been waiting what seems like forever for a driver
> > for my laptop and now there is one! What a happy day! One
> > problem, it's an older Compaq laptop and uses a propriatary
> > chipset (and AGP bridge) so no AGPGART. *do-
folks wont like it).
> -Original Message-
> From: Sergey V. Udaltsov [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 26, 2002 21:23
> To: Alexander Stohr
> Cc: Al Tobey; DRI
> Subject: RE: [Dri-devel] Capturing debugging info without networking
>
>
> Good boys
> he using 20020625 snapshot
>
> from XFree86.0.log
> ...
> (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0),
> Permission denied
> (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.
> ...
Huh? Hi might try as root. If it works then something
with per user file permissions or st
i would prefer this
DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%Y-%m-%d-%T`
so that on sorted dir listings the most recent is
always on top since this date is encoded "MSB first".
(textual month locales wont sort that good at all.)
another two things you might want to add:
/sbin/lspci -vvv >$DRI
If the critical feedback is already big now,
then first fix a bit in drivers
and then widen the testing audience.
> A bit I had to study (laws + Savage4 docs). A bit I have to workc.
> A bit I had to drive my Toyota MR2 Roadster. A bit I had to live.
>
> ; )
>
> Feedback is starting to rise.
> From: Malverian ... [mailto:[EMAIL PROTECTED]]
> I'm having some pretty serious speed issues with my ATI
> Radeon 7500 64MB
> DDR. And my hopes are in you guys for helping me iron out the kinks.
>
> glxinfo says that direct rendering is enabled
> X startup has no warnings or errors
>
> I'm
Hardware -> "wibble" whatever this is.
DRI Logo doesnt represent a link to "home". it should be for convenience
(other highly important things already mentioned by others.)
for sake of niceness the sourceforge.net link with logo is missing.
The previous design had some headers and footers, i d
> Hello Alexander!
>
> No change to get this going on "your partner" boards?
> Even with flashed BIOS?
>
> I can get may hands on a 8500LE on top of my dual Athlon
> 1900+ MP/XP for
> testing.
>
> Thanks,
> Dieter
The partner boards do have individual board features
which aren't tested
Or you are try out the current closed source drivers
for X11 and the ATI FireGL 8700/8800 - they do run
on the "BUILT BY ATI" Radeon 8500 boards as well.
The board indicates this compatibility by a PCI
Subvendor ID of 0x1002 or ATI.
> -Original Message-
> From: Mike A. Harris [mailto:[EM
> Seriously, the DRI stuff does live in seperate directories,
> with the sole
> exception of the 2D driver, many of which have different
> maintainers in
> the XFree86 project scope. So there is a strong physical
> seperation of the
> DRI code in the XFree86 tree. So, more than the time that
> First, I took a look at the current radeon source,
> but if someone could explain me what the ringbuffer
> and the freelist are, i think i would at least
> be able to imagine something of what's supposed to happen.
Maybe you should start reading about advanced c programming
technics first?
Good fix Felix.
I do "hate" local function prototypes.
Its just bad coding style and laziness.
Further it shows a critical lack of
knowledge for the header file organisation.
They are never verified against the
implementation by the compiler and
might be overseen rather quickly
when the functi
The ATI Fire GL 4 is based on the IBM GXT chip series.
To all my knowledge IBM produced that high performance
grafics chip for their AIX based server and workstation
machines with IBM board design. Further there is the
FireGL board (the responsible high end group that is now
at ATI and was forme
oops, should go to the list.
-Original Message-
From: Alexander Stohr
Sent: Thursday, May 16, 2002 01:11
To: 'Dieter Nützel'
Subject: RE: [Dri-devel] Radeon 7500 + AMD761 Locks machine
I can confirm from own expirience so far...
Some 300-350 Watts power supply are require
> in the /usr/X11R6/lib/modules/dri/
> there is an file called sis_dri.so.
Its the OpenGL hardware accelleration module for some SIS chipset.
It "plugs" into the DRI concept when an application does use OpenGL.
> Do i have to up date this or what ?
It should have the same version as the rest of
> Please do the following tasks via telnet and report
> back to the list:
> - See if there is any application consuming all processor (top).
> - Copy the Xfree86.0.log to a safe place and post it here.
> - Check if X is still running or not (ps -A | grep X) and
> point down
> it's pid, an
Oops, intended to send this to the list...
-Original Message-
From: Alexander Stohr
Sent: Friday, April 19, 2002 13:54
To: 'Gareth Hughes'
Subject: RE: [Dri-devel] New cards (GPU's) from old card makers? DRI
support?
> > I really hope not... and at least in
> I thought about it again and made a plot of the fps over the pixel
> clock. This indicates that the different performance is *only* related
> to the CRT refresh. This is the Octave code I used to
> generate the plot:
>
> modes=[125.00; 115.50; 69.65; 45.80; 57.75; 34.83];
> fps =[155.20;
> I recently found out that the 3d performance of the mach64 branch (in
> terms of glxgears frame rates) is related to the physical screen
> resolution. I got the following glxgears frame rates with different
> resolutions:
>
> 1152x864: 155.2 fps
> 1024x768: 165.6 fps
> 800x600: 209.6 fps
>
I think i know about that state.
Terminating it doesnt work in the end.
It does happen to me that way if corrupt
the command buffers for the grafics chip.
This is either a direct programming error
like an inadequate amount of data after
a specific command package, an illegal
command or some situ
> I agree with the "you have to read pixels back from the frame
> buffer and
> then continue rendering polygons." For a hardware
> implementation I might
> agree with the "you need to draw more polygons than your
> hardware has room
> to store", but only if the hardware implementation decides
> > But now think that:
> > you have 8 light sources (specular, highlight, abient
> nicely mixed),
> > some 3 to 8 clipper planes,
> > an exponentional fog function applied,
> > you are using two sided triangles
> > and of course misc material sepcifications.
>
> I suspect that un
> > Maybe i am on error with you, and you might want to enlighten
> > me what successful computer projects on earth are a result of
> > your bold mind. (dont exclude computer projects for space crafts.)
>
> Now the above is something a bit 'trollish'. Kindly address
> the arguments, not the arg
Hey Raystonn,
Oh my godness, who fed that trolls. ;-)
Lets still assume, you havent had the facts handy
(due to your age, education, place of birth or current location)
for seeing clear in all the subjects you are trying to adress.
I would be much happier if i did feel that you were really wor
Hello Raystonn,
sorry, but a dedicated ASIC hardware is always faster.
(you are a troll, arent you?)
in the straight forward OpenGL case (flat and smooth shading)
you can turn on several features in the pixel path and in
the geometry pipeline (culling, 8x lighting, clipping)
that you wont be ab
> > > I don't think so. I haven't noticed a problem with fog
> in the tunnel demo.
> > So it works for you, doesn't it? Envious.
> > For me, the fog effect does not work. Some time ago, someone (Jose?)
> > even explained that is should not work on mach64 (alpha
> blending + some
> > other effec
> > (This is based on the idea that a full set of mipmaps packs
> perfectly to take
> > up two times the size of the base texture). That's also
> not true for all
> > architectures...
>
> Ok, that explains a bit. However, in some circumstances we
> may loose a
> level. The mipmaps don't dou
1 - 100 of 141 matches
Mail list logo
