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(0):
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
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
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 kB
i
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
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
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 interested
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
]
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
anyone /w yahoo.
--- Alexander Stohr [EMAIL
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
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
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
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
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
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
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 Dnzer [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2003 22:08
To: #NGUYEN THANH NAM#
Cc: [EMAIL
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
what the
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
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
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
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 (i686).
if you hear about an answer, then please post to the list
for letting people fix that.
-Alex.
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
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
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
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]
Subject: Re: [Dri-devel
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 over
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
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.
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
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
tir, 2003-02-11 kl. 12:26 skrev Alexander Stohr:
development
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:
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 supported.
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
On Tue, 2003-02-11 at 11:26
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
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 0xff00.
In the argb
/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
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
matter, is
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
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
Stohr for a while ;)
Do you know
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 lot more
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] 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 you slice
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
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:[EMAIL PROTECTED]]
Sent: Thursday, November
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
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 and
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
for my
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
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: 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
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 about
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 20021009 AGP 4x
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
else if ( advertised
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 OpenGL version
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, however,
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] 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] 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
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-oh*
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, remote
display,
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
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 sticky
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! Can anyone invent the way to do the same thing
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.
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:[EMAIL
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 and/or
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 dont
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
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 required to drive
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, and if
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 with the cards that I
may
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
640x480:
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 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 to perform
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
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 under these
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
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 effect?) So my
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
Oops, i should better care for sending
things to the mailing list address.
-Original Message-
From: Alexander Stohr
Sent: Wednesday, March 27, 2002 22:14
To: 'Leif Delgass'
Subject: RE: [Dri-devel] Max texture size
No, i dont see problems with that.
When the resoultion changes
just a quick guess since i am not aware of that specific function...
(assumed) its an extension to the OpenGL 1.x standard.
extension names arent most often exported by standard lib GL as symbols
but only via the get by name method.
you might want to have a look at the respective OpenGL specs
At http://dri.sourceforge.net/IRC-logs/
you will find these chat logs online:
20020121.txt22-Jan-2002 04:0062k
20020128.txt04-Feb-2002 11:0246k
20020204.txt07-Feb-2002 05:3441k
20020218.txt26-Feb-2002 16:2731k
20020225.txt
On 2002.03.13 19:21 Brian Paul wrote:
...
But if the Mach64 chip is the bottleneck, no amount of
(conventional)
driver optimization will improve the results. It _really_
depends on
the particular application.
-Brian
That means if the triangles are big then pretty few to do
Would anyone know what was wrong with support for Radeon
third texture
unit ?
The problem is that Mesa 3.4 only supported two texture
units (there were
some bitfields that didn't have room for more bits). In
Mesa 3.5 and
later the limit is eight. It shouldn't be hard to
PIO = Programmable IO.
Registers that are possibly in x86 IO address space or PCI config
space.
Today these are just memory mapped registers where the CPU has direct
access.
DMA = DirectMemoryAccess.
Typically an engine on a chip which trasnfers data forth and back.
It
It's puzzling that chown-chmod would have any baleful effect.
With a plain
file, once you've opened it you can monkey with the inode all
you want and
the filehandle remains valid, and similarly with devfs the
various device
inodes (/dev/misc/psaux, modem TTY, etc.) can be chowned even
Does anyone have any news on support for iDCT and
Motion-Compensation or any of the video related
features of the radeons? Do the reference drivers
from ATi have anything for these features? Just
curious.
Thanks,
Alex
So far i do know, there should be a solution for your
problem in
I have a Shuttle AK31 Rev3 motherboard (Athlon XP 1800 cpu)
and am trying to get XWindows working.
The one thing that sticks out to me is that, with the 2.4.16
kernel, the agpgart driver says the chipset is a KT266
(but not KT266A), but the drm
driver says the chipset is a KT133.
as
From: Philip Brown [mailto:[EMAIL PROTECTED]]
I thought that was just from the perspective of the graphics card.
A GART memory mapping is a memory range that is visible from
the grafics card (if on AGP socket) and from the CPU (or CPUs).
The GART memory area is looking just as a PCI card that
The GART is the paging unit of the AGP system.
It deals nicely with fragmented chunks of page sized
memory chunks. So you only need some sort of memory
allocation and a way to determine eachs pages physical
adress to use it for those GART purposes.
You just need to ensure that your memory is
From: Philip Brown [mailto:[EMAIL PROTECTED]]
On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote:
...
Try this page:
http://developer.intel.com/design/chipsets/datashts/index.htm
I found what seems to be the only document relevant to my AGP
programming
issue,
440BX
please visit http://www.sis.com/support/driver/linux.htm
in general most chips are supported since XFree86 3.3.6
which is required to run their Linux drivers.
as far as i can see there, XFree86 4.0a is a requirement
(we are currently apporaching X4.2.0) for their 630 / 540 family
while running
But we're talking page count, not byte count. So signed vs unsigned is
something like having 8 vs 16 TERRABYTES addressable.
Personally, I dont think that should be an issue :-)
well estimated. ;-)
consider such a coding:
size_t size_of_one_member, total_size_in_bytes;
int
Make the enable/disable configurable by an environment variable, like
so:
if ( getenv( LIBGL_DISABLE_MULTITEXTURE ) ) {
gl_extensions_disable( ctx, GL_ARB_multitexture );
}
if ( getenv( LIBGL_ENABLE_TEXTURE_ENV_ADD ) ) {
gl_extensions_enable( ctx,
BTW - I found the matter of problem. I have 8M video RAM. And use
resolution 1280x1024 (I have LCD so lower resolutions look
bad). Even in
16bpp, all buffers take almost 8M - so only 192K remains for textures
(actually, on 32bpp the server does not start at all). When I
experimentally
From: Thomas Dodd [mailto:[EMAIL PROTECTED]]
How do I speed up AGP? It looks to be in 1x mode, not 2x.
start X11 and respective driver.
then login as root and tryout this:
/sbin/lspci - | less
then you will spot capabilites for AGP on host bridge
and on grafics adapter.
See AGP[+/-],
1 - 100 of 115 matches
Mail list logo
