Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-14 Thread Sergey V. Udaltsov

> Please check the new package. Nothing really new, except that the things 
> you noticed (should) have been fixed. I've run the installation & 
> uninstalltion process fine. I didn't have time to really start X because 
> it's pretty late here (as you can see by the build time).
> 
Just tried. The installation was really smooth. But running was bad
enough. The screen got blank and I have to reboot the system
remotely:(((
In the XFree86.0.log:

(II) ATI(0): [drm] installed DRM signal handler
(II) ATI(0): [DRI] installation complete
Symbol drmMach64CleanupDMA from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol drmMach64InitDMA from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!

Fatal server error:
Caught signal 4.  Server aborting


When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".
Please report problems to [EMAIL PROTECTED]

Symbol drmMach64InitDMA from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!
Symbol drmMach64CleanupDMA from module
/usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved!

FatalError re-entered, aborting
Caught signal 11.  Server aborting

Any ideas?

Cheers,

Sergey


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread José Fonseca

On 2002.03.13 22:56 Sergey V. Udaltsov wrote:
> ...
> 
> > Luckily, the libs that came with your X 4.x should be just fine - less
> > stuff for download.
> That's better!
> 
> >  From what Frank said in the beggining there will be no AGP texturing,
> "In the beginning" - will it be tomorrow, next week or next 3 months?
> Just estimations - when we'll get our lovely binary snapshots..

 From what depends on me, as soon as the branch is usable is just a matter 
of two clicks and at the most 4 hrs later you'll have a snapshot! ;-)

> > only DMA, i.e., you'll experience a general speedup in preformance
> (number
> > of triangles per second), but you'll still be limited to the memory
> your
> > card have, so applications that make heavy use of textures (i.e. games)
> > will have most of the same problems if high-res textures or high
> > screen-resolutions are used.
> I see. And how long do you (or Frank) think it will take to do AGP
> texturing?
> 

I have no idea... AGP is supported in almost all DRI drivers so it 
shouldn't be difficult to get a base implementation, but bugs can be 
rather hard to find&fix sometimes

> I realize it is much easier to ask question "when?" than hack the real
> code, so don't bother too much answering me:)

I would be making the same question if I was you, nevertheless the answers 
would still be the same...

Please check the new package. Nothing really new, except that the things 
you noticed (should) have been fixed. I've run the installation & 
uninstalltion process fine. I didn't have time to really start X because 
it's pretty late here (as you can see by the build time).

http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020314-0123-i386-Linux.tar.bz2

> 
> Cheers,
> 
> Sergey
> 

Regards,

José Fonseca

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Sergey V. Udaltsov

> I'm hammering my head against the wall at this moment!! You're completely 
> right, all those files should be let alone! :P
:) Please keep your head in cool dry place. We really need it.

> Luckily, the libs that came with your X 4.x should be just fine - less 
> stuff for download.
That's better!

>  From what Frank said in the beggining there will be no AGP texturing, 
"In the beginning" - will it be tomorrow, next week or next 3 months?
Just estimations - when we'll get our lovely binary snapshots..
> only DMA, i.e., you'll experience a general speedup in preformance (number 
> of triangles per second), but you'll still be limited to the memory your 
> card have, so applications that make heavy use of textures (i.e. games) 
> will have most of the same problems if high-res textures or high 
> screen-resolutions are used.
I see. And how long do you (or Frank) think it will take to do AGP
texturing?

I realize it is much easier to ask question "when?" than hack the real
code, so don't bother too much answering me:)

Cheers,

Sergey

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread José Fonseca

On 2002.03.13 21:25 Sergey V. Udaltsov wrote:
> > I've changed my mach64's cvsbld and dripkg scripts to have separate
> > build trees (so there are no *.o anymore in the DRM dir), just install
> > the DDX drivers that belong to driver (so there is no r128, radeon
> along
> > with the ati driver), and just install the device dependent drivers (no
> > lib{GL,drm,Core}.a).
> Just downloaded it (actually from 16:55), and ...
> Well, there are problems with the installation procedure:
> 1. You pkginfo does not contain the 5th line, so the name of the DRM
> module is "" instead of "mach64". Easy to fix.
> 2. Well, you move libdr[m|i]. into dri-old.*, but you put nothing
> instead! So script gives errors and X gives a lot of unresolved symbols
> on startup (though starts). Should we use "original" libs or not? If yes
> - do not move them please.
> 3. Same situation with libGL* - the script is trying to do something
> with the missing directory GL and moving original files into dri-old.* -
> but where on Earth my glxinfo is going to find the correct version of
> the library (sorry, it really needs one - ask ldd:)? Please either leave
> them untouched or supply your own.
> 

I'm hammering my head against the wall at this moment!! You're completely 
right, all those files should be let alone! :P

I'll fix this ASAP. (Now I'm at home so I'll be able to test it myself).

> Probably, if all these libs are never actually changed, you could bundle
> some kind of corelibs.tar.bz2 and install it separately? Sorry, I do not
> know much about these things so my idea can be nonsense.

Luckily, the libs that came with your X 4.x should be just fine - less 
stuff for download.

> 
> Anyway, thanks for new tarballs. 1.5M - it is reasonable size for any
> driver! Look forward to try first tarballs from 0-0-3-dma branch. We
> will be able to use highres with 3D on this branch, won't we?
> 

 From what Frank said in the beggining there will be no AGP texturing, 
only DMA, i.e., you'll experience a general speedup in preformance (number 
of triangles per second), but you'll still be limited to the memory your 
card have, so applications that make heavy use of textures (i.e. games) 
will have most of the same problems if high-res textures or high 
screen-resolutions are used.

Only once AGP texturing is implemented, the card will be able to use all 
system memory in AGP aperture for textures, depth&back buffers, etc.

> Cheers,
> 
> Sergey
> 

Regards,

José Fonseca

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Sergey V. Udaltsov

> I've changed my mach64's cvsbld and dripkg scripts to have separate
> build trees (so there are no *.o anymore in the DRM dir), just install
> the DDX drivers that belong to driver (so there is no r128, radeon along
> with the ati driver), and just install the device dependent drivers (no
> lib{GL,drm,Core}.a).
Just downloaded it (actually from 16:55), and ...
Well, there are problems with the installation procedure:
1. You pkginfo does not contain the 5th line, so the name of the DRM
module is "" instead of "mach64". Easy to fix.
2. Well, you move libdr[m|i]. into dri-old.*, but you put nothing
instead! So script gives errors and X gives a lot of unresolved symbols
on startup (though starts). Should we use "original" libs or not? If yes
- do not move them please.
3. Same situation with libGL* - the script is trying to do something
with the missing directory GL and moving original files into dri-old.* -
but where on Earth my glxinfo is going to find the correct version of
the library (sorry, it really needs one - ask ldd:)? Please either leave
them untouched or supply your own.

Probably, if all these libs are never actually changed, you could bundle
some kind of corelibs.tar.bz2 and install it separately? Sorry, I do not
know much about these things so my idea can be nonsense.

Anyway, thanks for new tarballs. 1.5M - it is reasonable size for any
driver! Look forward to try first tarballs from 0-0-3-dma branch. We
will be able to use highres with 3D on this branch, won't we?

Cheers,

Sergey

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Brian Paul

Michael Thaler wrote:
> 
> On Wed, Mar 13, 2002 at 04:33:10PM +, Jose Fonseca wrote:
> 
> I get 27.5 Frames in Unreal Tournement with WorldTextureDetail Medium
> and Skin Detail Medium.
> 
> If I also turn on Show Decals and Dynamic Lightning, I get around 25
> fps.
> 
> All with 640x480 Resoultion, Kernel 2.4.18 and a 650 MHz PIII SOny
> Vaio Laptop (Ati Rage Mobility P/M)
> 
> Pretty impressive, I guess the driver is not optimised at all and will
> even be faster in the future.

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

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Will Newton

On Wednesday 13 Mar 2002 6:21 pm, Jose Fonseca wrote:

> This also happens with me in some applications (glxgears quite often),
> and since mach64-0-0-2-branch. It seems that X doesn't get notified that
> that area is dirty, or the application draws another frame before
> quitting when it shouldn't.

Incidentally this also happens with XFRee86 4.1 and the tdfx driver.

(i.e. hit esc and the thing closes down OK, hit close gadget and it leaves 
dirt)

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Jose Fonseca

On Wed, 2002-03-13 at 18:03, Michael Thaler wrote:
> On Wed, Mar 13, 2002 at 04:33:10PM +, Jose Fonseca wrote:
> 
> > I would also like to point out that at this moment the
> > mach64-0-0-3-branch, from where this snapshot was taken, is perfectly
> > usable with almost the same level of functionality given by the previous
> > mach64-0-0-2-branch except some remaining glitches.
> 
> Thank you Jose. I installed the mach64-0-0-3 branch from CVS and
> compilied it. Everything went fine. I installed it and tested it with
> glxgears and Unreal Tournement.
> 
> glxgears showed around 280 Frames per second which is much faster then
> with the mach64-0-0-2 branch. (I think I got around 180 or less, I do
> not exactly remember). 
> 
> ut gave me about the same framerate then the mach64-0-0-2 branch, I
> think, but the textures look antialiased now. I still ran your
> UnrealTournement.ini with a resoltion of 640x480 but I will experiment
> and turn some stuff on and see how fast it is then.
> 

hmm.. not sure if there was anything that caused that texture
antialiasing...

> A bug I saw is the following. When I run glxgears and destroy the
> window, the window vanished, but the graphics inside the
> glxgears-window is painted on the windows behind. Moving the windows
> does not make the graphic disappear, but selecting text with the mouse
> does.
> 

This also happens with me in some applications (glxgears quite often),
and since mach64-0-0-2-branch. It seems that X doesn't get notified that
that area is dirty, or the application draws another frame before
quitting when it shouldn't.

> I will do some more testing with ut, turning stuff on and report what
> I will find.
> 
> Thank you and the others that worked on the mach64 for your excellent
> work!
> Michael


Jose Fonseca


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Michael Thaler

On Wed, Mar 13, 2002 at 04:33:10PM +, Jose Fonseca wrote:

I get 27.5 Frames in Unreal Tournement with WorldTextureDetail Medium
and Skin Detail Medium.

If I also turn on Show Decals and Dynamic Lightning, I get around 25
fps.

All with 640x480 Resoultion, Kernel 2.4.18 and a 650 MHz PIII SOny
Vaio Laptop (Ati Rage Mobility P/M)

Pretty impressive, I guess the driver is not optimised at all and will
even be faster in the future. So maybe I should install return to
caslte Wolfenstein:-)))

Thanks Jose and the others for your work!
Greetings,
Michael

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Michael Thaler

On Wed, Mar 13, 2002 at 04:33:10PM +, Jose Fonseca wrote:

> I would also like to point out that at this moment the
> mach64-0-0-3-branch, from where this snapshot was taken, is perfectly
> usable with almost the same level of functionality given by the previous
> mach64-0-0-2-branch except some remaining glitches.

Thank you Jose. I installed the mach64-0-0-3 branch from CVS and
compilied it. Everything went fine. I installed it and tested it with
glxgears and Unreal Tournement.

glxgears showed around 280 Frames per second which is much faster then
with the mach64-0-0-2 branch. (I think I got around 180 or less, I do
not exactly remember). 

ut gave me about the same framerate then the mach64-0-0-2 branch, I
think, but the textures look antialiased now. I still ran your
UnrealTournement.ini with a resoltion of 640x480 but I will experiment
and turn some stuff on and see how fast it is then.

A bug I saw is the following. When I run glxgears and destroy the
window, the window vanished, but the graphics inside the
glxgears-window is painted on the windows behind. Moving the windows
does not make the graphic disappear, but selecting text with the mouse
does.

I will do some more testing with ut, turning stuff on and report what
I will find.

Thank you and the others that worked on the mach64 for your excellent
work!
Michael

___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Jose Fonseca

On Wed, 2002-03-13 at 17:02, Thomas Dodd wrote:
> 
> 
> Jose Fonseca wrote:
> > I've changed my mach64's cvsbld and dripkg scripts to have separate
> > build trees (so there are no *.o anymore in the DRM dir), just install
> > the DDX drivers that belong to driver (so there is no r128, radeon along
> > with the ati driver), and just install the device dependent drivers (no
> > lib{GL,drm,Core}.a).
> > 
> > This should result in a (hopefully) more clean install, besides of a 1
> > Mb reduction in the download file.
> > 
> > ***NOTE***: If you have installed a previous snapshot please uninstall
> > _before_ installing this one due to eventual incompatibilities in libGL.
> > You can do that by using the install script from the previous snapshot
> > (sh install.sh restore) or, in alternative, reinstalling the X rpm (rpm
> > -Uvh --force XFree-...).
> 
> Does this also affect the other CVS builds. like r128?
> 
>   -Thomas
> 

No, it doesn't affect the other CVS builds. Not yet at least. It will
eventually happen after the libGL compatibility problem is fixed on the
trunk as well _and_ libGL is excluded from the binary snapshots, which
will necessarily happen by this order, and it will be posted on the
dri-devel list when it does.

Jose Fonseca


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] [Announce] New mach64 snapshot

2002-03-13 Thread Jose Fonseca

I've changed my mach64's cvsbld and dripkg scripts to have separate
build trees (so there are no *.o anymore in the DRM dir), just install
the DDX drivers that belong to driver (so there is no r128, radeon along
with the ati driver), and just install the device dependent drivers (no
lib{GL,drm,Core}.a).

This should result in a (hopefully) more clean install, besides of a 1
Mb reduction in the download file.

***NOTE***: If you have installed a previous snapshot please uninstall
_before_ installing this one due to eventual incompatibilities in libGL.
You can do that by using the install script from the previous snapshot
(sh install.sh restore) or, in alternative, reinstalling the X rpm (rpm
-Uvh --force XFree-...).

I would also like to point out that at this moment the
mach64-0-0-3-branch, from where this snapshot was taken, is perfectly
usable with almost the same level of functionality given by the previous
mach64-0-0-2-branch except some remaining glitches.

It's now the right time for testing, especially for regression bugs.
Please restrain from using excessive resolutions or any memory consuming
options in your OpenGL applications when testing to avoid problems with
lack of free onboard memory due to absence of AGP texturing - there is
nothing we can do about that right now and it would hide the existing
bugs that we can and want to fix.

The snapshot is available at
http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020313-1542-i386.tar.bz2

At this time there still is no changelog available. Binary packages will
continue to be made unconditionally on a 4hr interval. To track the
changes consider subscribing to the dri-patches mailing list (low
traffic about 20 msgs per week) since not all changes are posted here.
I'll eventually try to find a way to generate a changelog automatically
but it won't happen soon, sorry.

Regards,

Jose Fonseca


___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel