Karl Rasche wrote:
Attached is a patch to attempt to duplicate the r200 agp allocator,
independant of any one particular drivers' code.
Also, is a quick implementation for the mga driver.
Hopefully I went about this in a somewhat correct mannor. If not, please
let me know...
Felix Kühling wrote:
Keith,
you got the condition for waiting for an interrupt wrong.
r200_ioctl.c, line 330
...
/* if there was a previous frame, wait for its IRQ */
- if (iw-irq_seq != -1 sarea-last_frame r200GetLastFrame( rmesa ) ) {
+ if (iw-irq_seq != -1
I definitely running this on my dual Athlon with latest ACPI for 2.4.19 and
irq's routing enabled, I think.
With procinfo -f I see ~980 irq/sec during gears.
Same with r200 code from yesterday. But it was much faster.
I think I may have fixed your problem (thanks to Felix), can you try
On Tue, Oct 01, 2002 at 04:25:21PM -0700, Russ Dill wrote:
I just uploaded a set of binary snapshots built from the CVS head
using RedHat's compat-gcc-7.3-2.96.110 package (which produces
code compatible with the gcc bundled with the RedHat 7.3 and is
the same which was producing
On Mit, 2002-10-02 at 11:13, José Fonseca wrote:
On Tue, Oct 01, 2002 at 04:25:21PM -0700, Russ Dill wrote:
I just uploaded a set of binary snapshots built from the CVS head
using RedHat's compat-gcc-7.3-2.96.110 package (which produces
code compatible with the gcc bundled with the
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,
On Wed, Oct 02, 2002 at 01:15:26PM +0200, Michel Dänzer wrote:
You don't need to build for every system, just against an older version
of glibc.
I am not using these binary snapshots, but I appreciate this work. But
please do not compile it against RedHat's glibc2.3 version. RedHat is
the
On Wed, Oct 02, 2002 at 01:35:50PM +0200, Michael Thaler wrote:
On Wed, Oct 02, 2002 at 01:15:26PM +0200, Michel Dänzer wrote:
You don't need to build for every system, just against an older version
of glibc.
I am not using these binary snapshots, but I appreciate this work. But
please do not
Hi,
I'm a newbie who offered to continue development of the SIS630
DRI drivers. (The non DRI sis X drivers are being maintained by
Thomas Winischhofer and he's doing a good job)
My first task it to find out why DRI crashes my computer after a
few seconds when any game (I'm using Foobillard)
My first question, I haven't looked at the code properly yet, is about ioctl
numbers. Where are they coming from? How do we avoid overlapping with the
driver-specific ioctl numbers?
From what I gather from drm.h, the driver specific ioctls are supposed to
begin at 0x40. The highest
Karl Rasche wrote:
My first question, I haven't looked at the code properly yet, is about ioctl
numbers. Where are they coming from? How do we avoid overlapping with the
driver-specific ioctl numbers?
From what I gather from drm.h, the driver specific ioctls are supposed to
begin at
On Mit, 2002-10-02 at 14:41, Keith Whitwell wrote:
Michel Daenzer wrote:
* environment variables are checked every time instead of just once on
context setup
What's the logic behind this?
You can change behaviour during runtime by changing the environment
variables, without
On Wed, 2002-10-02 at 12:35, Michael Thaler wrote:
I am not using these binary snapshots, but I appreciate this work. But
please do not compile it against RedHat's glibc2.3 version. RedHat is
the only distribution using it right now. The only reason I can see
for this is, that RedHat _wants_
On Wed, Oct 02, 2002 at 02:25:40PM +0100, Alan Cox wrote:
Get a clue.
glibc 2.3 is used because its newer, because it fixes lots of bugs,
because its more standards compliant, because it uses new syscalls.
Everyone will be using it soon enough.
glibc 2.3 is LSB compliant, like current
I finally last night got the CVS version to run, but only by running the
complete X server out of the build tree. glxgears runs several hundred
fps (I forget the exact number) but even better, used virtually no CPU
time, so apparently the IRQ stuff is working. (Radeon 8500 128MB (QL),
Pentium
I'm getting quite similar results:
with xmms running in background: ~150 FPS
with xmms paused: ~130 FPS
after i unpause xmms, FPS will drop down very low (~10 FPS or s.th.) for
about 1 or 2 seconds (system load is almost 100% during that period),
and then go up to 150 again (with low
is
./dripkg.sh RADEON /path/to/cvs/xc/ /path/to/cvs/build/ 20021002-linux.i386
If didn't built on a seperate lndir'd 'build' directory just give the
same path to the CVS.
Can anyone put together a list of what libraries must be upgraded? The
GL directory in the dripkg is empty in all the old snapshots
/ . Then all you have to do
is
./dripkg.sh RADEON /path/to/cvs/xc/ /path/to/cvs/build/ 20021002-linux.i386
See, that's the problem: I'm already using this script, and it does not
include enough. Even if I remove that PKG_MINIMAL (or whatever it was, I
don't have the script at hand
Am Mittwoch, 2. Oktober 2002 18:03 schrieb Andy Dustman:
On Wed, 2002-10-02 at 10:57, José Fonseca wrote:
On Wed, Oct 02, 2002 at 09:40:20AM -0400, Andy Dustman wrote:
[-]
Can anyone put together a list of what libraries must be upgraded? The
GL directory in the dripkg is empty in all the
On Wed, 2002-10-02 at 12:19, Dieter Nützel wrote:
Perhaps we need to produce binary snapshots for each driver that
includes only the device-specific stuff (kinda like what dripkg.sh does
now) and then have a separate snapshot for the libraries (particularly
the GL libraries) which you
Am Mittwoch, 2. Oktober 2002 18:35 schrieb Andy Dustman:
On Wed, 2002-10-02 at 12:19, Dieter Nützel wrote:
Perhaps we need to produce binary snapshots for each driver that
includes only the device-specific stuff (kinda like what dripkg.sh does
now) and then have a separate snapshot for
On Wed, Oct 02, 2002 at 06:50:50PM +0200, Dieter Nützel wrote:
Am Mittwoch, 2. Oktober 2002 18:35 schrieb Andy Dustman:
[...]
Which is it, then: Snapshots or no snapshots? The current snapshots (for
linux-i386) don't work unless you have Red Hat 8.0 and/or glibc-2.3; I'm
not even sure that
On 02 Oct 2002 12:35:19 -0400
Andy Dustman [EMAIL PROTECTED] wrote:
Which is it, then: Snapshots or no snapshots? The current snapshots
(for linux-i386) don't work unless you have Red Hat 8.0 and/or
glibc-2.3;
Really? is that why my machine dies when using the current snaps? I have
glibc
The efforts that have gone into binary snapshots have been a good thing.
They have enabled a broader user base by allowing users access to 3D
drivers that didn't have them before, getting us feedback from a larger
testing base, and exposing backwards compatability issues with our
binary
On Mon, 2002-09-30 at 22:14, Alex Deucher wrote:
I'm pretty unfamiliar with OpenGL programming. I have an idea for an
xfree module that I suspect would not be too hard to implement, but I
wanted to get some other opinions on it. What I'd like to do is
create
a module called perhaps
On Wed, Oct 02, 2002 at 10:33:11AM -0700, Russ Dill wrote:
[...]
But I see rough times ahead for the binary snapshots. I surely can't make
one for each system out there. And if the others distros don't also
upgrade to glic-2.3 then I think the best is to completely stop the
snapshots builds
On Wed, 2002-10-02 at 18:56, Jens Owen wrote:
2) The kernel AGP GART module is one monolithic driver. IHV's need some
way of releasing AGP GART updates without stepping on one another.
I think I speak for the most of the kernel community in saying that we
don't give a hoot about idiots
On Mon, Sep 30, 2002 at 05:07:39PM -0600, Brian Paul wrote:
This was a topic on today's IRC session. Here's a very rough list of issues
and goals to consider. After we get a good list we can move onto implementation
proposals. If we're really going to do this, let's be sure we do it right.
*please* find a machine with a copy of glibc2.2, wait until glibc2.3
actually becomes a release to compile against it (or, if in the case of
redhat, distribute it with your distro)
The final RHL 8.0 was released 2 days ago. I'll upgrade soon but I
already checked and it has the same
Ian Romanick wrote:
Really there are 3 places the texture data can be duplicated: in the app, in
libGL, and on-card / AGP. This can either be done by exposing some sort of
allocate AGP memory extension or with APPLE_client_storage and dynamic AGP
remapping.
I've done a cursory look at
release version, and using that. CVS versions of software often contain
new bugs and even security vulnerabilities, it is far more prudent to
work with a release version of such a major system component. Because of
this, most distros will probably wait until it becomes a release until
they
On Wed, Oct 02, 2002 at 04:35:16PM -0600, Jens Owen wrote:
Ian Romanick wrote:
Really there are 3 places the texture data can be duplicated: in the app, in
libGL, and on-card / AGP. This can either be done by exposing some sort of
allocate AGP memory extension or with
I managed to get the r200 driver working again by doing a complete CVS
install. Some notes:
* The card does now seem to generate interrupts at about the same
frequency as the current mode's vertical refresh.
* Surprisingly (for me, at least), glxgears is now running at about
2000+ fps and
Thanks for the answer! :), well all modules seems to be right, the black
screen problems is fixed, I just installed the cvs version and
everything is going right, some guy told me something about the libxaa
thing (didnt understand, not an english speaker you know ...), about the
aperture thing,
On Sat, 22 Sep 2001, Michael Zayats wrote:
SNIP
it's true that lspci shows that both my video card and ethercard use IRQ
11.
2 questions:
1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back to
the driver?
2) practical: AFAIK BIOS is in charge of setting IRQs, but the
Title: nrporulcbxvsvbwjxgorvuwvktttgsmvnclhw
Hello dri-devel,
Get a Free Mortgage
Quote
for any State!
Get the best Mortgage Rates in the Country Free!
Let the Banks Compete for your Loan!
We
specialize in approving BAD CREDIT
Bad
36 matches
Mail list logo