Dear Jacob, dear everyone,
once you managed to get everything in place, would you mind to write
down what you did in a form like:
- Get xorg cvs via
# cvs command co
- cd into directory xy and edit Makefile z in some way
- ./configure & make
- Get some other cvs tree via this command:
# cvs
Vladimir Dergachev wrote:
there are no problems with stretching the window
I've experimented and found that 2 NOPs doesn't really help.
if I set full screen to be the LCDs native resolution it happens less
often.
I think this problem DVI-related. Until I or someone else can show the
problem is wi
On Thu, 03 Feb 2005 23:50:21 -0800, Jacob Gorm Hansen <[EMAIL PROTECTED]> wrote:
> Vladimir Dergachev wrote:
>
> > No special tinkering is required beyound recent Xorg CVS.
>
> Will version 6.8.1.902 (from Gentoo) be recent enough?
>
no. you need xorg from cvs HEAD.
Alex
---
On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote:
Vladimir Dergachev wrote:
No special tinkering is required beyound recent Xorg CVS.
Will version 6.8.1.902 (from Gentoo) be recent enough?
I don't think so - this sounds like 6.8.2-rc1
You ca check this easily by looking in /var/log/Xorg.0.log - it shou
On Fri, 4 Feb 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
there are no problems with stretching the window
I've experimented and found that 2 NOPs doesn't really help.
if I set full screen to be the LCDs native resolution it happens less
often.
I think this problem DVI-related. Until I o
On Fri, 4 Feb 2005, Fionn Behrens wrote:
Dear Jacob, dear everyone,
once you managed to get everything in place, would you mind to write
down what you did in a form like:
- Get xorg cvs via
# cvs command co
- cd into directory xy and edit Makefile z in some way
- ./configure & make
- Get some oth
Vladimir Dergachev wrote:
On Fri, 4 Feb 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
there are no problems with stretching the window
I've experimented and found that 2 NOPs doesn't really help.
if I set full screen to be the LCDs native resolution it happens
less often.
I think this prob
special cases. q3a and NeHe lessons 2-20 don't look any worse.
I haven't looked at the r300 code as it's not in Mesa CVS, but I'm
wondering if you've noticed that the i915 driver does a similar task of
converting fixed function GL to a programable fragment shader backend?
It may be a bit late in th
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
> > maybe it makes sense to start including r300 in mesa. You guys have
> > made a lot of progress. It doesn't have to be built by default, and
> > the development can still happen in r300 cvs (just sync them from time
> > to time), but
On Fri, 4 Feb 2005, Adam Jackson wrote:
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
maybe it makes sense to start including r300 in mesa. You guys have
made a lot of progress. It doesn't have to be built by default, and
the development can still happen in r300 cvs (just sync them
On Friday 04 February 2005 21:52, Vladimir Dergachev wrote:
> On Fri, 4 Feb 2005, Adam Jackson wrote:
> > Here again, ideally this would get folded upstream too, once it's at
> > least secure.
> >
> > I can't really mandate a policy since I haven't been contributing much
> > to r300, but I would li
Adam Jackson wrote:
I would really like to see the r300 code not get its own driver. Unified
drivers are a good thing, and radeon/r200 is bad enough. Unfortunately I
don't know a good way to make sure they don't diverge more than they already
have. I think the current development method is wo
On Friday 04 February 2005 16:17, Roland Scheidegger wrote:
> Adam Jackson wrote:
> > I can't really mandate a policy since I haven't been contributing much to
> > r300, but I would like to hear how people think this should progress.
>
> I'm not so convinced that r200 and r300 driver (and radeon, f
Adam Jackson wrote:
On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
The biggest reason at the moment against including R300 driver in Mesa CVS
is that the code is a mess. There are r200 files that are not being used
in any way and large sections of code simply cut'n'pasted from R200 dri
Adam Jackson wrote:
On Friday 04 February 2005 16:17, Roland Scheidegger wrote:
>
Direct3D drivers are not really an apples-to-apples comparison since they'll
try to factor out as many conditionals as possible for that last 0.03fps in
3dmark. fglrx is probably a more fair comparison, and fglrx c
So you might be able to unify them, but I'd bet it won't look pretty.
Of course, it depends on how dissimilar the chips actually are. IMHO the
differences between radeon and r200 are too big to make unifying
worthwile, I have only looked at the r300 driver briefly but the
differences to r200 seem
On Fri, 4 Feb 2005, Nicolai Haehnle wrote:
On Friday 04 February 2005 21:52, Vladimir Dergachev wrote:
On Fri, 4 Feb 2005, Adam Jackson wrote:
Here again, ideally this would get folded upstream too, once it's at
least secure.
I can't really mandate a policy since I haven't been contributing much
t
Adam Jackson wrote:
I'm not so convinced that r200 and r300 driver (and radeon, for
that matter) really should be only one driver. Why is it that bad
to have 3 drivers? Those chips just ARE different. Sure, the 2d
parts are more or less identical and certainly should be only one
driver, but tha
> Though if r200 and r300 are going to be unified, I'd definitely suggest
> that radeon gets unified too. The code which can be shared between r200
> and r300 is likely going to be pretty much the same as the code which
> can be shared between radeon and r200, I think. In fact, if one would now
>
Aha, you have a SuperSavage. Unfortunately it seems like vertex DMA
locks up these cards. Other SuperSavage users reported the same. I don't
know why and I can't debug the problem because I don't have a
SuperSavage to test (and neither has Alex :( ). The only way seems to be
to disable vertex DMA.
Vladimir Dergachev wrote:
1. Get Xorg CVS, Get Mesa CVS Get r300_driver from CVS at r300.sf.net
2. Compile drm from r300.sf.net, insmod ./drm.ko ; insmod ./radeon.ko
check for no lockups
3. Compile and install Xorg CVS. Check that there are no lockups
4. insmod drm modules as above, run Xor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir Dergachev wrote:
| On Thu, 3 Feb 2005, Jacob Gorm Hansen wrote:
|> Will version 6.8.1.902 (from Gentoo) be recent enough?
|
|
| I don't think so - this sounds like 6.8.2-rc1
Actually RC2 -- it's how the numbering scheme works. (version-1).90X i
On Fri, 4 Feb 2005, Jacob Gorm Hansen wrote:
Vladimir Dergachev wrote:
1. Get Xorg CVS, Get Mesa CVS Get r300_driver from CVS at r300.sf.net
2. Compile drm from r300.sf.net, insmod ./drm.ko ; insmod ./radeon.ko
check for no lockups
3. Compile and install Xorg CVS. Check that there are no lo
Vladimir Dergachev wrote:
I am just getting the message (WW) RADEON(0): Direct Rendering not yet
supported on Radeon 9500 and newer cards.
This means you have old Xorg code. You need to compile new one from CVS.
Hmm, apparently the 'make install' had not nuked all of my old X11
binaries. Now it
On Fri, 4 Feb 2005, Jacob Gorm Hansen wrote:
Vladimir Dergachev wrote:
I am just getting the message (WW) RADEON(0): Direct Rendering not yet
supported on Radeon 9500 and newer cards.
This means you have old Xorg code. You need to compile new one from CVS.
Hmm, apparently the 'make install' had
On Fri, 2005-02-04 at 00:29 +, Armin Krieg wrote:
>
> I'm using a Radeon 9600XT and there are no error-messages in syslog
>
> and i hope i can give also another bug-report, although I think its a problem
> with the new dri-code...
> I'm using a cvs-snapshot of x.org and with the newer ker
26 matches
Mail list logo
