Re: Rant (was Re: ATI Drivers.)
On Sun, 20 Jul 2003, Mike A. Harris wrote: On Sat, 19 Jul 2003, Fred Heitkamp wrote: If the server market is the biggest (and for Linux it is) then only 2D support if that is required. I'd bet even the big film studios don't use Linux to view the final rendering. They probably use a Mac (Apple OS of some kind) or a PC running Windows. Search google for Dreamworks SKG stories involving Linux. You'll be surprised. I will do that. But even if you count every cluster node running Linux rendering movie and TV frames as a separate machine, I'd still bet it's only a fraction of the total Linux server market. Fred Error Loading Explorer.exe You must reinstall Windows. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sun, 20 Jul 2003, Sven Luther wrote: Date: Sun, 20 Jul 2003 14:58:56 +0200 From: Sven Luther [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Rant (was Re: ATI Drivers.) I've responded to Sven off list, simply because the message was getting very long, and there are probably not many people interested in reading our conversation anymore, and it is also quite off the topic of XFree86 development. There wasn't anything inherently private about it however, so if anyone wanted to know my response, I'll be glad to email it to them. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Performance problems revisited
The 'Athlon related mystery' thread concluded by recommending the removal of O_SYNC on the open to /dev/mem to solve performance problems in SuSE's XFree86 packages [1]. I still have many users with similar performance problems, and I want to know how to better debug it. 1. A SuSE user with a Radeon 8500, P4 1.8, that gets 133fps with xvtest, but seemingly good performance from x11perf -shmput500 [2]. Installing the O_SYNC fix from SuSE did not improve performance! Also something similar with Gentoo xfree-4.3.0-r2. 2. An i815 with a Celeron 800, MX3S-T motherboard. Gets about 60fps using xvtest, 273 blits/sec with x11perf -shmput500 at 16bpp, using Gentoo xfree-4.3.0-r2. Does not use O_SYNC on /dev/mem. Would this have anything to do with it: (II) I810(0): xf86BindGARTMemory: bind key 0 at 0x (pgoffset 0) (WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed (Cannot allocate memory) (II) I810(0): No physical memory available for 4194304 bytes of DCACHE 3. A user with a SiS651, a P4 2.4G and Thomas' latest driver, using both DanielS's 4.3 packages and the standard 4.2.1 debian packages, gets terrible performance. Only 430fps from xvtest while Thomas, with similar hardware, gets 1800fps. ASUS Pundit. On this one we're completely stuck. No O_SYNC. 4. Vladimir Dergachev noted some odd performance statistics here [3]. Are there more hardware or BIOS configurations can I check that can change video memory performance? These XVIDEO drivers usually do nothing more than a memcpy(), at least for SiS and i815. My list: - MTRRs enabled (they almost always are). - Compare xvtest with shmput500 speed, if it shows a discrepancy, look at the driver source (but usually we learn nothing from that!) - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? - Use of O_SYNC. So far it seems just that SuSE release used it, and some users it didn't seem to help. What else? -Billy [1] This thread is not on mail-archive.com, which seems to have missed most of April/May of this year. [2] See http://bugs.xfree86.org/show_bug.cgi?id=414 with detailed logs. [3] http://www.mail-archive.com/devel%40xfree86.org/msg01756.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sun, 20 Jul 2003, Richard A. Hecker wrote: I encounter this all the time. If someone asks me Why does your product version x.y not support foo? and I delete their mail, they are none the wiser. They are unlikely to flame me, or to even know if I got it. I will add my own Rant here. Ignoring email from Joe Public who bought his 'Puter from Walmart' might work, but I feel 'Dissed' when a person insults my intelligence with this respose. It isn't an insult to intelligence at all. I don't delete every mail I get, but I don't respond to every one of them either. If I responded to every Red Hat customer or user question and every email I received from someone in the community asking for help or asking what is or isn't supported, I would never get any work done, and would likely not have a job. It is not my job at all in any way, to provide end user technical support via email, telephone, mailing lists, bugzilla or otherwise. Any response to a user or customer that I give, is done as a volunteer because I feel like it. Sometimes I have time to do that, and some times I do not. Sometimes I point people to the appropriate web page on our website or the XFree86 site or wherever, or point them to google, and sometimes I forward their email to someone else inside or outside the company depending on the situation. Other times I don't have the time and hit delete. If you received 30 messages a day asking you I cant get i845 video to work, would you respond to each of them by hand? Not likely. You might write an FAQ however. Been there, done that. Nobody reads or wants to read an FAQ, and you still get the questions, just as many of them. What's worse, is saying Did you read the FAQ? http://; no matter how it's worded is often blown off or even in some cases considered rude. I've had people read the first page of an FAQ, not find what they wanted, then email me, or nail me in IRC and waste my time, to be pointed to the FAQ, and tell them to read the table of contents nad find their question and then read the answer to be told I don't like to read. Should I cater to these people? If I delete their question, do you still think I am insulting their intelligence? I help enough people out there every day, for free, without it being part of my job, that I don't have any commitment to _anyone_ to answer every email sent to me directly and hand hold a person. That is definitely not my job. Really, if someone wants that level of commitment, purchase a support contract, and call your technical support liason and you can get that level of support. Volunteerism goes so far, and when the volunteer doesn't enjoy it, they're not obligated to give it. Is foo supported? Really it comes down to: Read the release notes. Read the XFree86 support documents on the XFree86 website. Read the Red Hat Hardware compatibility list. Ask on a mailing list, etc. Don't email mharris. ;o) grin time doing so. Also, your company is paying for your time, so if you're responding to 5000 users a day to listen to them argue, that is hardly worthy usage of your time. Fortunately, it is Saturday, so I can argue with you until Monday. After that, I'll have to delete your mails. ;o) My threshold was 300-500 daily emails. Less than 300 was a light day, and more than 500 kept me from finishing the work I was paid to do. I have no idea what your data point looks like but I suspect you use multiple addresses and understand how to sort things into various folders. I rarely respond and spend 10X to 20X more time reading than writing email. I would write more code if I did not get as much email but the spammers make that unlikely :( Your assumptions are fairly accurate. I'm on over 100 mailing lists, maybe more, I don't count anymore, and use 2 mail clients (pine) simultaneously across 5 mail accounts. I've no idea how much mail that is, but probably 5000-1 a day. I don't read them all of course, nor respond. I have prioritized mail folders so I get the most important stuff right away, less important stuff later, and the rest are generally archived for snooping through or searching when I'm bored or need to search for a problem or whatever as I prefer to archive lists locally that I use than to use the klunky web based unreliable search engines. If you cannot or choose to not respond, that is fine. But own up to your decision and do not pretend you never received the message. Actually, I've tried that too. I've responded to people as nice PR-speak as possible something to the effect of: Hi name, I'm sorry that I am unable to personally help you to find an answer to your problem, however I can try to direct you to other places where you might find help. Some things you may find useful are: $mailinglist1 $mailinglist2 $mailinglist3 $webURL1 $webURL2 $webURL3 I hope these resources are helpful to you, and that you're able to find an
Re: Performance problems revisited
On Mon, 2003-07-21 at 13:29, Billy Biggs wrote: 1. A SuSE user with a Radeon 8500, P4 1.8, that gets 133fps with xvtest, but seemingly good performance from x11perf -shmput500 [2]. The radeon driver uses the CP for image writes, does Option XaaNoScanlineImageWriteRect have a similar impact on x11perf -shmput500 performance? - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? No. I wonder if the video capture card could have something to do with it? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
Michel Dänzer ([EMAIL PROTECTED]): On Mon, 2003-07-21 at 13:29, Billy Biggs wrote: 1. A SuSE user with a Radeon 8500, P4 1.8, that gets 133fps with xvtest, but seemingly good performance from x11perf -shmput500 [2]. The radeon driver uses the CP for image writes, does Option XaaNoScanlineImageWriteRect have a similar impact on x11perf -shmput500 performance? I've added this question to the bug report. (414 on bugzilla). - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? No. I wonder if the video capture card could have something to do with it? It's idle when we test with 'xvtest'. -Billy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Any clues - TuxRacer Incorrect Rendering
On Thu, 2003-07-17 at 23:25, Chris Edgington wrote:
Working on my last known bug in the SM731 support in the siliconmotion
driver. Using the current siliconmotion driver and my newly modified driver
on the SM722 hardware, running TuxRacer from RH9 works fine. TuxRacer (or
probably more appropriately glut) uses the VidMode extension to set the mode
to 640x480x16. The driver has no dri component, so the rendering of the game
is extremely slow, but it works.
When I run my new driver on the SM731, everything X works fine -
acceleration, overlay, etc. However, when I run TuxRacer, after the modeset
happens to 640x480x16, the TuxRacer display is hosed. It looks like some
kind of framebuffer width or pitch problem.
Indeed, does the desktop look correctly when switching modes with
ctrl-alt-{+,-} or xvidtune?
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
More IPv6 RedHat 6.2 problems compiles but doesn't work
This is with RedHat 6.2. The latest IPv6 fixes allow X to compile, but remote connections no longer work on a machione without IPv6 configured. I've recompiled with XTRANSDEBUG set high (5 I think): % xbiff -display localhost:0 _X11TransOpenCOTSClient(tcp/localhost:0) _X11TransOpen(1,tcp/localhost:0) _X11TransParseAddress(tcp/localhost:0) _X11TransSelectTransport(tcp) _X11TransSocketOpenCOTSClient(tcp,localhost,0) _X11TransSocketSelectFamily(tcp) _X11TransSocketOpen(1,1) _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:0 Error: Can't open display: localhost:0 % strace shows socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 EAFNOSUPPORT (Address family not supported by protocol) For comparison, local connections succeed and report: % xbiff _X11TransOpenCOTSClient(local/:0) _X11TransOpen(1,local/:0) _X11TransParseAddress(local/:0) _X11TransSelectTransport(local) _X11TransSocketOpenCOTSClient(local,harrier,0) _X11TransSocketSelectFamily(local) _X11TransSocketOpen(4,1) _X11TransSocketOpen: returning for local _X11TransConnect(3,local/:0) _X11TransParseAddress(local/:0) _X11TransSocketUNIXConnect(3,harrier,0) ... ... -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Solution for 855GM video memory issue
This could easily be integrated in the driver (it would be much more easy to do than writing a separate program) but like you say in your disclaimer: we cannot guarantee that nothing bad happens. Therefore I don't think it is the way to go. However what I find more interesting is that you updated the BIOS with one form the Intel web site. Intel claims that this issue has been fixed with later versions of the BIOS, so that the driver can use a specific BIOS function to teach the BIOS of the changed size. Therefore - according to Intel - you should not need this program any more. Egbert. Christian Zietz writes: Hi, PLEASE CC any answers to [EMAIL PROTECTED] as I'm not subscribed to the list. first, my problem as summarized by David H. Dawes: It appears that some 855GM-based laptops only pre-allocate 1MB of video memory, and don't provide any BIOS configuration options for increasing this. Although the XFree86 driver will allocate more (if the correct agpgart kernel support is present), the mechanism used to inform the video BIOS of the additional allocation doesn't seem to be implemented on these laptops. This results in the video BIOS refusing to program video modes that require more than 1MB (actually 832KB). As far as I know there hasn't been any solution for this. So I spent my day digging through Intel datasheets and disassembling the Video BIOS and came up with a hack that works for me: The Video BIOS stores the memory size it thinks it is allocated at a certain location in RAM. This location is write-protected by default but can me made writable by setting the appropiate chipset registers. That's what I do and then I can set the memory size so XFree86 works with higher resolutions and color depths. Since I don't have the XFree86 sources to patch, I implemented this hack in a separate program called 855patch. It takes the desired video memory size in KB as argument. Note that it only tells the BIOS what memory size to expect but does NOT actually allocate the memory. So you'll have to set the VideoRAM option in the XF86Config Device section to at least the size you used when calling 855patch (more is fine) or your system will probably crash. The hack works nicely on my Dell Inspiron 500m laptop (Intel Video BIOS version 2945) and the mechanism I described is also implemented in version 2973 I downloaded from Intel.com. So I suggest you try it, if you have the problem described above. I'd be very glad if this snippet - if it works on other systems - found it's way to XFree86 sources. Disclaimer: Obviously I can't guarantee that it'll work for you. So don't blame me if something bad happens. Download: http://www.chzsoft.com.ar/855patch.c Christian Zietz, now able to run XFree86 in 1024x768x16bpp ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More IPv6 RedHat 6.2 problems compiles but doesn't work
Dr Andrew C Aitchison wrote (in a message from Monday 21) This is with RedHat 6.2. The latest IPv6 fixes allow X to compile, but remote connections no longer work on a machione without IPv6 configured. I've recompiled with XTRANSDEBUG set high (5 I think): % xbiff -display localhost:0 _X11TransOpenCOTSClient(tcp/localhost:0) _X11TransOpen(1,tcp/localhost:0) _X11TransParseAddress(tcp/localhost:0) _X11TransSelectTransport(tcp) _X11TransSocketOpenCOTSClient(tcp,localhost,0) _X11TransSocketSelectFamily(tcp) _X11TransSocketOpen(1,1) _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:0 Error: Can't open display: localhost:0 % strace shows socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 EAFNOSUPPORT (Address family not supported by protocol) Can you try with the '-nolisten inet6' option ? Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Mon, Jul 21, 2003 at 08:04:56AM -0400, Mike A. Harris wrote: On Sun, 20 Jul 2003, Richard A. Hecker wrote: I will add my own Rant here. Ignoring email from Joe Public who bought his 'Puter from Walmart' might work, but I feel 'Dissed' when a person insults my intelligence with this respose. It isn't an insult to intelligence at all. I don't delete every ...snip... Should I cater to these people? If I delete their question, do you still think I am insulting their intelligence? I did not suggest that you cater to these people. I just pointed out the offense I would take from such an insult. I would remember such an insult during any future dealings I had. Your assumptions are fairly accurate. I'm on over 100 mailing lists, maybe more, I don't count anymore, and use 2 mail clients (pine) simultaneously across 5 mail accounts. I've no idea how much mail that is, but probably 5000-1 a day. I don't read them all of course, nor respond. I have prioritized mail folders so I get the most important stuff right away, less important stuff later, and the rest are generally archived for snooping through or searching when I'm bored or need to search for a problem or whatever as I prefer to archive lists locally that I use than to use the klunky web based unreliable search engines. This makes sense. I basically agree with you. It comes down to the _priority_ of a message. Everyone has their own priority scheme. This might be a good place for me to bash [EMAIL PROTECTED] and [EMAIL PROTECTED] accounts. I simply pointed out that you can pretend a message never arrived but some people will see right through that excuse. Richard ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Low-Priced site for printing needs
55 Percent off all printer supplies! Please see my stores and feel what others have already, the best ink cartridges at a great price. We offer all brands including, HP, Epson, Canon, and Lexmark http://smart-pr1nt1ng-suppl1es.com/neb.html = wish to stop further sending of emails, http://e-inteligent-shopping.com/s20.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
On Mon, 21 Jul 2003, Billy Biggs wrote: The 'Athlon related mystery' thread concluded by recommending the removal of O_SYNC on the open to /dev/mem to solve performance problems in SuSE's XFree86 packages [1]. I still have many users with similar performance problems, and I want to know how to better debug it. 1. A SuSE user with a Radeon 8500, P4 1.8, that gets 133fps with xvtest, but seemingly good performance from x11perf -shmput500 [2]. Installing the O_SYNC fix from SuSE did not improve performance! Also something similar with Gentoo xfree-4.3.0-r2. 2. An i815 with a Celeron 800, MX3S-T motherboard. Gets about 60fps using xvtest, 273 blits/sec with x11perf -shmput500 at 16bpp, using Gentoo xfree-4.3.0-r2. Does not use O_SYNC on /dev/mem. Xv support on Intel graphics is limited to the refresh rate. 3. A user with a SiS651, a P4 2.4G and Thomas' latest driver, using both DanielS's 4.3 packages and the standard 4.2.1 debian packages, gets terrible performance. Only 430fps from xvtest while Thomas, with similar hardware, gets 1800fps. ASUS Pundit. On this one we're completely stuck. No O_SYNC. 4. Vladimir Dergachev noted some odd performance statistics here [3]. Are there more hardware or BIOS configurations can I check that can change video memory performance? These XVIDEO drivers usually do nothing more than a memcpy(), at least for SiS and i815. My list: - MTRRs enabled (they almost always are). MTRR support for Athlon is broken in some Linux older kernels. /proc/mtrr usually reports suspiciously broken data in this case though. - Compare xvtest with shmput500 speed, if it shows a discrepancy, look at the driver source (but usually we learn nothing from that!) Some drivers, like i810, cannot program the next frame until the one before last has finished. They burn the CPU if you send frames faster than the refresh rate. - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? It shouldn't matter. - Use of O_SYNC. So far it seems just that SuSE release used it, and some users it didn't seem to help. What else? The FastWrite capability of P4 processors greatly increases the CPU throughput to the framebuffer. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
On Mon, 21 Jul 2003, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): 2. An i815 with a Celeron 800, MX3S-T motherboard. Gets about 60fps using xvtest, 273 blits/sec with x11perf -shmput500 at 16bpp, using Gentoo xfree-4.3.0-r2. Does not use O_SYNC on /dev/mem. Xv support on Intel graphics is limited to the refresh rate. [...] - Compare xvtest with shmput500 speed, if it shows a discrepancy, look at the driver source (but usually we learn nothing from that!) Some drivers, like i810, cannot program the next frame until the one before last has finished. They burn the CPU if you send frames faster than the refresh rate. Thanks Mark, this explains the behavior. My application is a deinterlacer which outputs 59.94fps video, and this user is outputting to an HDTV which is at, of course, 59.94hz refresh. Do you think we can implement triple buffering to solve the problem in this case? I don't know enough about Intel hardware to say. While I'm at it, how hard do you think it would be to do triple buffering in the NVIDIA driver for this same problem? NVIDIA hardware can only double buffer. Using more buffers than two would require queuing them up and programming the new buffers in the interrupt handler. Are there more hardware or BIOS configurations can I check that can change video memory performance? These XVIDEO drivers usually do nothing more than a memcpy(), at least for SiS and i815. My list: - MTRRs enabled (they almost always are). MTRR support for Athlon is broken in some Linux older kernels. /proc/mtrr usually reports suspiciously broken data in this case though. How old are we talking about? I rarely see users with anything before 2.4.18. Not very old. I'd expect alot of people to have broken mtrr support in their kernels. - Use of O_SYNC. So far it seems just that SuSE release used it, and some users it didn't seem to help. What else? The FastWrite capability of P4 processors greatly increases the CPU throughput to the framebuffer. Ok, will help anyone with a P4 though? I don't seem to see that much difference in XVIDEO performance between the P4 2.4 I'm at and my P3 at home, and both happen to be using the mga driver. It won't help everyone. Similar to AGP, the video card needs to support it and it has to be enabled. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
Mark Vojkovich ([EMAIL PROTECTED]): While I'm at it, how hard do you think it would be to do triple buffering in the NVIDIA driver for this same problem? NVIDIA hardware can only double buffer. Using more buffers than two would require queuing them up and programming the new buffers in the interrupt handler. Can you query which buffer is being displayed? I'd just like to replace tearing with frame drops if possible, so changing which buffer is queued next would be sufficient. -Billy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
Win: I agree with the spirit of your statement, but I don't want the government involved in any part of what I do for a living or a hobby. I agree that M$'s size is a problem now, but I am certain that they will not be dominant forever. Large companies do fail, and they do get smaller. JC wim delvaux wrote: Sorry I interrupt but I wonder why the government does not see (want to see) that Microsoft in effect is completely blocking the market. Because of its market size no development into anything new can be performed if it does not run on windows and since that market is very large, companies do not see need or opportunity to go into other markets EXCEPT if the windows market is lost and/or full. W -- Jay Cotton [EMAIL PROTECTED] 408 635 0621 x11621 Sun Microsystems Inc. 2515 North First Street, MS USJC07-201 San Jose, CA 95131 Sun Microsystems Inc. - Software QICS/Globalization: X11 Engineering ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
On Mon, 21 Jul 2003, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): While I'm at it, how hard do you think it would be to do triple buffering in the NVIDIA driver for this same problem? NVIDIA hardware can only double buffer. Using more buffers than two would require queuing them up and programming the new buffers in the interrupt handler. Can you query which buffer is being displayed? I'd just like to replace tearing with frame drops if possible, so changing which buffer is queued next would be sufficient. I know which one is being displayed, but I can't override the one that is pending. If I get a PutImage request and there is already one buffer being displayed and one pending, I have three choices. 1) Drop the new request entirely. 2) Spin until a buffer is free. 3) Overwrite the data in the pending buffer. This will tear if the buffer switches while your are overwriting. I currently do #3 and there is a #if in the nv driver allowing you to switch to #2. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
Mark Vojkovich ([EMAIL PROTECTED]): On Mon, 21 Jul 2003, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): While I'm at it, how hard do you think it would be to do triple buffering in the NVIDIA driver for this same problem? NVIDIA hardware can only double buffer. Using more buffers than two would require queuing them up and programming the new buffers in the interrupt handler. Can you query which buffer is being displayed? I'd just like to replace tearing with frame drops if possible, so changing which buffer is queued next would be sufficient. I know which one is being displayed, but I can't override the one that is pending. If I get a PutImage request and there is already one buffer being displayed and one pending, I have three choices. 1) Drop the new request entirely. 2) Spin until a buffer is free. 3) Overwrite the data in the pending buffer. This will tear if the buffer switches while your are overwriting. I currently do #3 and there is a #if in the nv driver allowing you to switch to #2. Does the NVIDIA driver do something different since it can listen on the interrupt? Does it queue it up or something? -Billy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
On Mon, 21 Jul 2003, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): On Mon, 21 Jul 2003, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): While I'm at it, how hard do you think it would be to do triple buffering in the NVIDIA driver for this same problem? NVIDIA hardware can only double buffer. Using more buffers than two would require queuing them up and programming the new buffers in the interrupt handler. Can you query which buffer is being displayed? I'd just like to replace tearing with frame drops if possible, so changing which buffer is queued next would be sufficient. I know which one is being displayed, but I can't override the one that is pending. If I get a PutImage request and there is already one buffer being displayed and one pending, I have three choices. 1) Drop the new request entirely. 2) Spin until a buffer is free. 3) Overwrite the data in the pending buffer. This will tear if the buffer switches while your are overwriting. I currently do #3 and there is a #if in the nv driver allowing you to switch to #2. Does the NVIDIA driver do something different since it can listen on the interrupt? Does it queue it up or something? Nope. It does #3. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
Billy Biggs [EMAIL PROTECTED] wrote: Are there more hardware or BIOS configurations can I check that can change video memory performance? These XVIDEO drivers usually do nothing more than a memcpy(), at least for SiS and i815. My list: - MTRRs enabled (they almost always are). - Compare xvtest with shmput500 speed, if it shows a discrepancy, look at the driver source (but usually we learn nothing from that!) Have you checked how the actual assembler code for the memcpy() looks? I mentioned this before that some compilers (Watcom on DOS/Windows for instance) will optimise the copy by including code to pre-fill cache lines by doing reads from the destination memory. Reads from the video framebuffer are terribly slow using the CPU, so this can kill performance. I realise you have have checked this before, but it would be worth checking again since the prior problem was related to the use of O_SYNC so the memcpy() code would have had no effect. - Motherboard AGP chipset. Does this matter if the driver uses the CPU to copy? Can just loading agpgart help? CPU copies should be very fast direct to the linear framebuffer. One other thing I just thought of is to make sure that the memcpy() (or your own custom copy function) is always DWORD aligned on the destination. If you do unaligned writes to the framebuffer, you can also get quite a big performance hit (much more than for unaligned writes in system memory). Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
Sven Luther [EMAIL PROTECTED] wrote: Why do these companies not open source their complete drivers? Because they have intellectual property in their drivers that As if their concurent where not capable of reverse engineering the drivers. And if they did and they got caught, their company would essentially be destroyed. Proprietry software developers in general do *not* reverse engineer other companies intellectual property. Hell, just try selling software you have developed to IBM and deal with the huge battery of COO (Certificate O Ownership) issues before IBM will accept your product! These companies take intellectual property very seriously, indeed even more seriously now with the SCO lawsuit; now I am glad we have all the COO's in place already and I am sure IBM is too. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance problems revisited
Mark Vojkovich [EMAIL PROTECTED] wrote: The FastWrite capability of P4 processors greatly increases the CPU throughput to the framebuffer. You mean the FastWrite capability of the AGP bus/card in AGP4x/8x specs, or are you talking about something different and specific to P4 processors? Definately the AGP FastWrite when enabled on both the card and the bus will dramatically increase direct video memory write performance. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Driver for 69030
Title: Message Hello Everyone! Iam writing a driver for 69030 card. I have to support CIF and QCIF formats. 1. The format says that a frame rate of 30fps is required for both. 2.Each frame should have a. 144 lines and 176 pixels/line for QCIF. b.288 lines and 352 pixels/line for CIF. Now myinterpretation is that the second point above refers to the frame size and the driver implementation (video modes)has nothing to do with it. Is this interpretation of mine is correct? Second question is that ,how do I achive the frame rate of 30fps?I have programmed the BitBLT engine for the card,but that also puts only 64Kb data on screen in on shot,so always I need to divide the Image into 64KB parts. What else hardware need to be programmed to achive this???Can this be achived without programming the multimedia engine? How willl I test that what frame rate Iam getting Thanking u in advance regards, Nitin Mahajan mail:[EMAIL PROTECTED] Ph:51101667. Mobile : 9886099925 == The Lord gave us two ends -- one to sit on and the other to think with. Success depends on which one we use the most.
