ATI fixes rendering issues in their latest driver release

Get help with installing and running the Cafu Engine here. This forum is also for general questions and discussion of all aspects regarding the Cafu Engine.
Post Reply
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:
ATI fixes rendering issues in their latest driver release

Post by Carsten » 2004-09-04, 23:52

I just got information that the latest release of the ATI Radeon drivers finally contains a fix for an earlier driver bug that caused rendering issues with Ca3DE on ATI Radeon graphics boards.

It took ATI almost a year to get the issue fixed, but I'm happy that they eventually moved. After all, working with their Tech Support was a positive experience, especially when compared to enterprises of similar size and products. I was worried all the time that people misattributed the rendering bugs to the Ca3D-Engine when in fact the driver was broken, but that is finally settled now. 8)
Last edited by Carsten on 2004-09-05, 01:00, edited 1 time in total.
Best regards,
Carsten
Dodger
Posts:39
Joined:2004-08-23, 14:37
Location:Wuppertal/Germany
Contact:

Post by Dodger » 2004-09-05, 00:56

Hi Carsten,

great to hear that! Of course it was not CA3D Error.
Shame on the people who thought that :D ;)

Dodger
"Off all things I have lost, I miss my mind the least!"
Firefax
Posts:8
Joined:2004-08-28, 19:23
Contact:

It works with the new ati drivers

Post by Firefax » 2004-09-05, 12:21

Hi,
I tested Ca3de with the new Ati Drivers and Ca3de works fine. Right now, I have the version 4.8 (with Catalyst Control Center) installed. My Gfx Card is a Shappire Radeon 9800 Pro 128MB.
CYA
Firefax
User avatar
Advis
Posts:16
Joined:2004-08-21, 20:42
Location:England
Contact:

Post by Advis » 2004-09-05, 22:26

I don't own an ATI card but it's of my upmost interest that any games we develop don't have these issues, so it's a very positive thing.

Hopefully this might also present a speed increase, any evidence to suggest this?
Image
Joseph Scott - Digital Effect & Theory Team Leader.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Post by Carsten » 2004-09-06, 00:04

Update:
I got some screenshots from Firefax and his ATI Radeon 9800. Well, maybe the report above was too early: While the situation did indeed improve, the screenshots indicated a lower than expected frame-rate, and still not the proper lighting in all situations.
I still have to run additional own tests until I can say more. Maybe the issue is settled, maybe its not. I'll keep looking into it. Stay tuned.
Best regards,
Carsten
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Post by Carsten » 2004-09-06, 00:16

Advis wrote:Hopefully this might also present a speed increase, any evidence to suggest this?
No.

The problem that caused the rendering problems indeed is accompanied by too little FPS. That did not improve.

If you have an NVidia board, please note that the FPS with real-time lighting is generally slower than with lightmaps lighting, see this FAQ for more details.
Best regards,
Carsten
RAZOR
Posts:17
Joined:2004-08-23, 07:44
Location:New Zealand

Post by RAZOR » 2004-09-27, 04:52

I saw somewhere that with nvidia drivers opengl commands return immediately but with an ati driver they only return once the action has been performed, meaning you get 100% cpu usage when all your doing with the processor is sending stuff to the graphics card. Would that account for the bad performance?
No-one quite knows why I'm here...
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Post by Carsten » 2004-09-27, 10:50

RAZOR wrote:Would that account for the bad performance?
I doubt it. While I also observed that OpenGL on NVidia takes very little time for individual function calls, that time is consumed later on flushing and swapping the frame buffers, that is, finishing the rendering of a single frame takes relatively long compared to rendering it.

On the other hand, virtually all 3D real-time software consumes 100% CPU, and even if the OpenGL implementation behaved vastly different on NVidia and ATI drivers, the rendering code could not be changed in order to account for this.
Best regards,
Carsten
RAZOR
Posts:17
Joined:2004-08-23, 07:44
Location:New Zealand

Post by RAZOR » 2004-09-28, 15:06

[EDIT: RAZOR, I'm very sorry, as I've accidently edited your posting, rather than posting a quoted reply to it. Unfortunetly, I only realized this after I've been unable to recover your original message.
I'm very sorry!
Carsten]

Excreta occurs*. My post was mostly about how if the rendering was in a different thread then it wouldn't matter how long it took for opengl commands to return the game code would still be being processed, but thats a hell of a thing to do. I also said that if you have the flush and swap commands at the start of a new frame instead of at the end of an old frame then the cpu and graphics card work in parallel more. I think that was about it.

*For those who have never heard this saying before, especially the non naitive english speakers, it amounts to "sh** happens".
Last edited by RAZOR on 2004-09-29, 05:13, edited 1 time in total.
No-one quite knows why I'm here...
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Post by Carsten » 2004-09-28, 17:09

Up to you if you feel like playing around with it.
:-) Not really.
Next thing I'll do is changing the Ca3D-Engine to universally use and employ the new Ca3DE Material System ("MatSys"). The MatSys does already work in experimental mode in CaWE (looking very promising), and fully in the new ModelViewer. Thus, tomorrow I'll start making the engine use it, too, which will be a big step forward. All these items are not yet publicly available, but will be with the next release.

To get back to the original subject: I don't see much gain in having the rendering code in a separate thread from the master game loop, neither with the old rendering, nor in the light of the new MatSys. Threading doesn't buy anything in performance here, and - as you already mentioned - only introduces a lot of subtle sync'ing issues, which can be more expensive to resolve than anything threading ever buys. (Ca3DE never permits the CPU to be idling anyway, so there is nothing to gain from putting the rendering into a separate thread. ;) )
Best regards,
Carsten
User avatar
Shadow
Posts:195
Joined:2004-08-28, 06:00
Location:Minesota, USofA
Contact:

Post by Shadow » 2004-10-11, 22:43

yes i noticed that ca3d takes up a good deal of processor time. is there a way we could 'disable' un-needed functions of the engine? like if we have a single player game can we disable all mplayer stuff? or disable some of the advanced graphics rendering?
Image
PBX CONTINUES!!!
CLICK HERE!!
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Post by Carsten » 2004-10-12, 00:06

Shadow wrote:yes i noticed that ca3d takes up a good deal of processor time. is there a way we could 'disable' un-needed functions of the engine? like if we have a single player game can we disable all mplayer stuff?
Sorry, no. Multi-Player is indeed more expensive than Single-Player, but the real and most important bottle-neck is probably the graphics.
or disable some of the advanced graphics rendering?
Yes, that is possible. Please have a look here:
http://www.ca3d-engine.de/phpBB2/viewtopic.php?t=7
Maybe "r_style 4" is what you're looking for.
The upcoming Material System will probably permit even finer control over rendering features.
Best regards,
Carsten
User avatar
Advis
Posts:16
Joined:2004-08-21, 20:42
Location:England
Contact:

Post by Advis » 2004-10-12, 00:09

This material system just sounds so cool......stop it Carsten you are making me drool!
Image
Joseph Scott - Digital Effect & Theory Team Leader.
Post Reply

Who is online

Users browsing this forum: No registered users and 25 guests