Slashdot Mirror
Hardware Based XRender Slower than Software Rendering?
Neon Spiral Injector writes "Rasterman of Enlightenment fame has finally updated the news page of his personal site. It seems that the behind the scenes work for E is coming along. He is investigating rendering backends for Evas. The default backend is a software renderer written by Raster. Trying to gain a little more speed he ported it to the XRender extension, only to find that it became 20-50 times slower on his NVidia card. He has placed some sample code on this same news page for people to try, and see if this is also experienced on other setups."
last time I checked all graphix cards need drivers to enable their acceleration.
He didn't really get too far into that, but it would be interesting to see how feasible it is to do all the 2D rendering using OpenGL, encapsulated by some layer, like his Evas.
Has anyone done that? Any interesting results? One would think that there's a lot of potential here...
I have used both ATI and NVIDIA,(and 3dfx, and matrox, but staying relevant). Generally the NVIDIA cards I have owned have been vastly outperformed by the ATI cards right off the bat, without tweakage. (This is under Linux, mind you) Even with tweakage, in my experience, you rarely get the full potential from your card.
I hate sigs.
Is XRender really accelerated? I thought that most Render operations were still unaccelerated on most video cards, and how and if they could be accelerated was still an open question. Maybe the real problem here is Render's software rendering code?
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
The fact that he's working on it again. A sudden change of heart, apparently. I can remember slashdotters posting hate about this guy because he was claiming the Linux desktop was dead; claims like E having failed and that being his way of taking it.
Happy New Year, it's 1984!
graphics cards work quickly because they cut every corner that can possibly be cut. It makes sense that they would run computer software slower.
I'm more interested in using them for specific calculations. Imagine if one of these things was accidentally embued with the ability to factor gigantic numbers. The AGP slot is just an excuse to keep us from beowulfing them over PCI-X
You can't judge a book by the way it wears its hair.
Irix.
IrisGL or OpenGL (I think OpenGL is based on IrisGL, so Irix probably now uses OpenGL) is used extensively in Irix, for both 2D and 3D.
A solution to the problem with music today
This is when I predict Xrender will be complete and Linux will be set to compete with OSX and Windows Longhorn in terms of rendering.
I suggest that Rasterman just forget about Xrender and use directfb or opengl.
If you use Linux, please help development of Autopac
Here is the entry from the driver README:
Following that option, this one is noted:
It may be big and bloated, but at least it's slow.
I'm an American. I love this country and the freedoms that we used to have.
Is this the same person who some time ago said that: "Windows has won. Face it. The market is not driven by a technically superior kernel, or an OS that avoids its crashes a few times a day. Users don't (mostly) care. They just reboot and get on with it. They want apps. If the apps they want and like aren't there, it's a lose-lose. Windows has the apps. Linux does not. Its life on the desktop is limited to nice areas (video production, though Mac is very strong and with a UNIX core now will probably end up ruling the roost). The only place you are likely to see Linux is the embedded space." Slashdot article is also available here: http://slashdot.org/articles/02/07/20/1342205.shtm l?tid=106
Err...Keith Packard ditched XFree86 to start his own fork, xwin...
And you're right...it does take longer to get complicated stuff done in free software land than it does when you've got how many guys being paid to do it.
"You tried your best and failed miserably. The lesson is...never try. Heh!" -Homer
What Apps can I not run under Linux?
My browser works, most of my games work, Photoshop works, Microsoft word works,
Do your research, Wine, Transgaming, Crossoveroffice
If you use Linux, please help development of Autopac
I actually have a mod point and I'm not going to spend it here. I'd give an underrated if it wasn't so long. I know that's the joke and parts _are_ funny, but more shock value than than witty commentary, IMO.
Hey and at least this comment will make someone browse at -1.
Acquiescence leads to obliteration
Also the only reason its taking so long is because they wont fork, theres millions of developers who Redhat, Suse, Lindows etc would love to pay to develop Xrender, you think Keith Packard is the only developer in the world qualified to do this? No hes not, and neither is Carl Worth, but until there is a fork, everything goes through this core group of developers who decide everything.
Its a management issue moreso than lack of developers or lack of money, believe me if Transgaming can get money, Xfree could get about x10 that amount of money, Mandrake has 15,000 subscribers paying $60 a year or something.
This isnt about money, its not about lack of programmers, its about management, the developers argue and fight over stupid stuff on mailing lists, theres only two developers working on Xrender and these developers seem over worked because they are doing so many other projects.
Its more complicated than it seems.
Xwin is not an official fork, at least I was told that it wasnt a fork, it was more of a threat of a fork, I am wishing and hoping they DO fork and then accept money somehow so we can pay developers to write this very important code.
If you use Linux, please help development of Autopac
There has been some work on using graphics cards for computation. The tough part is figuring out how to rephrase your algorithm in terms of what the GPU can handle. You'd expect matrix math to work out but people have tried to implement more interesting algorithms too. :-)
- AmitWhat, so now they've got rendering backends in Evangelions?
Normally, he would answer some questions or comments posted about something he has written, but he will be out of town for at least a few days.
I highly doubt he meant for this to get wide-spread exposure beyond developers of Enlightenment or X. Since it has, this is a good opportunity. I'll make this clear for anyone that didn't catch it, raster WANTS XRENDER TO BE FASTER! If there is a way to alter configuration or to recode the benchmark to do so, he wants to know about it.
Rather than posting questions about his configuration (which he can't answer right now), grab the benchmarks that he put up and get better results.
Now back to your regularly scheduled trolling...
There's an example from back in the 80's that still probably serves as a good engineering reference for people working on hardware/software driver issues.
In those days of yore (only in the computer industry can one refer to something 20 years ago as "yore"...) there was the Commodore 64. It retains it's place as a pioneering home computer in that it offered very good (for the time) graphics and sound capability, and an amazing 64K of RAM, in an inexpensive unit. But then came its bastard son...
The 1541 floppy disk drive. It became the storage option for a home user once they became infuriated enough with the capabilites of cassette-tape backup to pony up for storage on a real medium. Unfortunately, the 1541 was slow. Unbelievably slow. Slow enough to think, just maybe, there were little dwarven people in your serial interface cable running your bits back and forth by hand.
Now, a very unique attribute of the 1541 drive was that it had its own 6502 processor and firmware. Plausibly, having in effect a "disk-drive-coprocessor" would accelerate your data transfer. It did not. Not remotely. Running through a disassembly of the 6502 firmware revealed endless, meandering code to provide what would appear, on the surface, to be a pretty straightforward piece of functionality: send data bits over the data pin and handshake it over the handshake signal pin.
As the market forces of installed base and demand for faster speed imposed themselves, solutions to the 1541 speed problem were found by third party companies. Software was released which performed such functions as loading from disk and backing up floppies as speeds that were many, many times faster than the 1541's base hardware and firmware could offer.
The top of this particular speed-enhancement heap was a nice strategy involving utilizing both the Commodore 64's and the 1541's processors, and the serial connection, optimally. Literally optimally. Assembly routines were written to run on the both 64 and the 1541 side to exactly synchronize the sending and receiving of bits on a clock-cycle by clock-cycle basis. Taking advantage of the fact both 6502's were running at 1 Mhz, the 1541's code would start blasting the data across the serial line to the corresponding 64 code, which would pull it off the serial bus within a 3-clock-cycle window (you could not write the two routines to be any more in sync than a couple 6502 instructions). This method used no handshaking whatsoever for large blocks of data being sent from the drive to the computer, and so, in an added speed coup, the handshaking line was also used for data, doubling the effective speed.
The 1541 still seems pertinent as an example of a computer function that one would probably think would best be done primarily on a software level (running on the Commodore 64), but was engineered instead to utilize a more-hardware approach (on the 1541), only to be rescued by better software to utilize the hardware (on both).
There's probably still a few design lessons from the "ancient" 1541, for both the hardware and the software guys.
~ Whence do you come, slayer of men, or where are you going, conqueror of space?
The numbers being reported for this benchmark are at best questionable--yeah, like that's new. The imlib image is composed off-screen and then rendered at the last moment to the display. The Xrender, non-off screen, version has the penalty of having to upgrade the physical display so frequently. If you make imlib2 render the image to the screen *every* draw, you end up getting results very similar to the Xrender on-screen display. Now, the fact that the Xrender off-screen display is so poor *is* a concern.
As far as I know, only the Matrox G400 card has good hardware render accelaration. NVidia's support is still experimental and rather poor. Render is still considered experimental, and speed is not yet considered to be very important. Full accelerated support is planned for XFree86 5.
I worked on 2D & 3D libs a while back for a graphics company. Among the biggest problems at the time was that each different output device had its own feature set, implemented slightly differently. Every designer had their own ideas of what would be 'cool' in their graphics engine, which tended to follow the latest progress in the field.
General purpose graphics libraries such as ours ended up spending most of the time dealing with the cool features than the features saved. For example, if a plotter had a 2D perspective transform built in, was it better to do the 3D projection ourselves and just feed it untransformed vectors, or map the 3D in such a way as to allow the 2D processing of the plotter to help out? This might require pre-computing sample data.
Also, since the plotter had 2D transforms we have to do a lot more work including reading the plotter's status and inverting the plotter's transform matrix to make sure that the resulting output didn't end up outside the plotter's viewport.
A code analysis found that over 90% of the code and 90% of the processing time was spent preventing and dealing with input errors and handling compatibility issues.
Nowadays, it's harder in many ways with a wide variety of hardware based texturing and other rendering - do we do the lighting model ourselves, or let the HW do it? It may depend on whether we're going for speed and 'looks' or photometric correctness.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Anybody else read that as "XBender"?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
When was the last time you used Linux? In 2000? Its changed ALOT since 2000.
If you use Linux, please help development of Autopac
and I noticed something strange. For those of you who can't or won't try Rasterman's benchmark yourself, the program runs six different tests, each of which uses a different scaling technique. Each of the six tests is run on the three different test platforms: XRender onscreen, XRender offscreen, and Imlib2. Imlib2 is also written by Rasterman, and is part of Enlightenment.
Here are the test scores from one of the rounds -
*** ROUND 3 ***
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 196.868 sec.
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 196.347 sec.
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 6.434 sec.
Now for the strange thing. For the first platform, I watched as the program drew the enlightenment logo thousands of times in the test window, as you would expect. For the second test, it took about the same amount of time, but drew offscreen, again, as the test's name would indicate. However, for the imlib2 test, it also didn't draw anything in the test window.
I got the impression (perhaps wrongly?) that Imlib2 would actually draw to the screen as well. Since it doesn't change the screen, I have no way of telling if imlib2 is doing any drawing at all.
So, I'm digging into the benchmark's code... I'll let you guys know what I find.
This reminds me of the experience of WindowFX, a 3d transparency/animation tool made by Stardock. They included hardware 'acceleration' as a settable option, but for most cards it was anything but an option, ran at 1fps.
The exception being the G400, then the Radeon, and only very recently (on Windows) the GeForce. It's entirely an issue of how well the drivers are implemented, and since many of these 2d acceleration functions aren't widely used they're often overlooked in favor of the (traditionally) common case. I'd expect that NVidia hasn't been lobbied so heavily to make it's Linux drivers support these functions, as it took months for Stardock to lobby them to alter the Windows drivers to do the same.
I guess the answer is that I'm not surprised to hear something like this, and there is hope even if it's small hope that it will get better.
A lot of people are questioning the results claimed by Rasterman; however try downloading the thing and running it for yourself. I see the same trend that Rasterman claims when I do it.
My system: Athlon 800, nVidia 2-GTS.
Drivers: nVidia driver, 1.0.4363 (Gentoo)
Kernel: 2.4.20-r6 (Gentoo)
X11: XFree86 4.3.0
I've checked and:
The benchmark consists of rendering an alphablended bitmap to the screen repeatedly using Render extension (on- and off-screen) and imlib2. Various scaling modes are also tried.
When there's no scaling involved, the hardware Render extension wins; it's over twice as fast. That's only the first round of tests though. The rest of the rounds all involve scaling (half- and double-size, various antialiasing modes). For these, imlib2 walks all over the Render extension; we're talking three and a half minutes versus 6 seconds in one of the rounds; the rest are similar.
I'm not posting the exact figures since the benchmark isn't scientific and worrying about exact numbers isn't the point; the trend is undeniable. Things like agpgart versus nVidia's internal AGP driver should not account for the wide gap.
Given that at least one of the rounds in the benchmark shows the Render extension winning, I'm going to take a stab at explaining the results by suggesting that the hardware is probably performing the scaling operations each and every time, while imlib2 caches the results (or something). The results seem to suggest that scaling the thing once and then reverting to non-scaling blitting would improve at least some of the rounds; this is too easy, however, since while it helps the application that knows it's going to repeatedly blit the same scaled bitmap, not all applications know this a priori.
- Andrew
client/server setup is a superior way of designing a windowing environment.
.. I don't know for certain, I hope it uses Mach kernel messages.
X11 uses unix sockets (or optionally slower, less secure TCP) and shared memory.
Win32 uses shared memory and messaging.
MacOS X
QNX Photon uses qnx kernel messages and shared memory.
The real difference is the layer at which the windowing system exists. in the case of X11, MacOS X and Photon. the windowing system is just another process.
In Win32 it's a kernel thread (as far as I know). But still, you're sending messages from one place to another and constructing windows based on them.
Client/Server is the natural way to build a multi-application graphical environment.
Of course there are "fake" environments which amount of an embedded video driver and some library to draw widgets. (most DOS gui apps are like this).
“Common sense is not so common.” — Voltaire
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
How this got modded as Interesting and not Flamebait is beyond me. As far as Raster's coding skill goes, Let's see you write something akin to Enlightenment, or edje or evas, or any number of other apps and libraries. Now, in true open source spirit, did you even install his test app and submit results to help make anything better?
The problem is in *sending* the graphics commands to the hardware. If you're manually sending quads one at a time, I found that for 16x16 squares on screen, it's faster to do it in software than on a GEForce 2 (that was what I had at the time - this was a few years back). Think about it:
:)
== Hardware ==
Vertex coordinates, texture coordinates and primative types are DMA'd to the video card. The video card finds the texture and loads all the information into it's registers. It the executes triangle setup, then the triangle fill operation - twice (because it's drawing a quad).
== Software ==
Source texture is copied by the CPU to hardware memory, line by line.
Actual peak fill rate in software will be lower than hardware - but if your code is structured correctly (textures in the right format, etc) - there's no setup. The hardware latency looses out to the speed of your CPU's cache - the software copy has the same complexity as making the calls to the graphics card.
The trick is to *batch* your commands. Sending several hundred primatives to the hardware at the same time will blow software away - especially as the area to be filled increases. Well.. most of the time, but it really depends on what you're doing.
XRender is a new extension with only a reference implementation in XFree86. The point is to experiment with an API prior to freezing it. I know this may come as news to people who have grown up on Microsoft software, but real software developers first try out various ideas and then later start hacking it for speed. It would be quite surprising, actually, if it were faster than a hand-tuned client-side software implementation.
It will be a while until XRender beats client-side software implementations. Furthermore, you can't just take a client-side renderer and hack in XRender calls and expect it to run fast--code that works efficiently with a client-server window system like X11 needs to be written differently than something that moves around pixels locally.
I ran the benchmark on a VIA MVP3 motherboard with AMD K6-3+ 400 MHz CPU and GeForce2 MX 400 vide card. With RenderAccel option enabled, the unscaled test runs two times faster with XRender, but when that option is set to "false" in XF86Config, the results are as follows:
Test: Test Xrender doing non-scaled Over blends
Time: 16.234 sec.
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 16.108 sec.
Test: Test Imlib2 doing non-scaled Over blends
Time: 1.932 sec.
That was with hardware acceleration disabled. I was surprised that enabling the hardware acceleration speeds the first test up by that much (up to 32 times actually).
I also confirm the previous posters' findings that Imlib2 tests don't draw anything onscreen.
After installing imlib2, and running render_bench's 'make', it gives me the following:
cc -g -I/usr/X11R6/include `imlib2-config --cflags` -c main.c -o main.o
main.c: In function `xrender_surf_new':
main.c:67: `PictStandardARGB32' undeclared (first use in this function)
main.c:67: (Each undeclared identifier is reported only once
main.c:67: for each function it appears in.)
main.c:67: warning: assignment makes pointer from integer without a cast
main.c:69: `PictStandardRGB24' undeclared (first use in this function)
main.c:69: warning: assignment makes pointer from integer without a cast
main.c: In function `xrender_surf_blend':
main.c:153: `XFilters' undeclared (first use in this function)
main.c:153: `flt' undeclared (first use in this function)
main.c:154: `XTransform' undeclared (first use in this function)
main.c:154: parse error before `xf'
main.c:156: `xf' undeclared (first use in this function)
main.c: In function `main_loop':
main.c:439: `XFilters' undeclared (first use in this function)
main.c:439: `flt' undeclared (first use in this function)
make: *** [main.o] Error 1
It seems to do this at the same speed, whether or not I have render acceleration enabled.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
I still believe in the answer that was always given for id games when asked when they'll release the product.. "When it's done." I think that applies to opensource even more.
Besides we shouldn't be competing with MacOS or Windows. We don't need to clone those OS's or desktops. We need to create our own desktop that is unique. Make it work.. don't make it just to attract Windows and Mac users.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
needless to say most english speaking people know that the "x" letter is pronounced the same way as "cs" or "ks"... so I figured it would be redundant to type to letters when I could very easily do half the work and type one letter.
Replying to this post completely negates what I was trying to accomplish with my "x" trick, but I thought you'd like to know.
Sounds like he has investments, or some other finiancial interests, in embedded linux. It really isn't realistic to say desktop linux is over at a time when it's never been so popular. Maybe "desktop linux profits" aren't so hot, but linux wasn't designed to make money with anyways. And maybe "desktop linux as #1 popular desktop" isn't seeming very likely either. But I see no reason why whithin the next few years we can't get a decent amount of application, games, and hardware support for linux. I'm doing fine right now, and since I never had ties to msoffice, photoshop etc, the native linux solutions currently available a fine for me. It's just people habits and windows app training that traps most of them. Also, as an nvidia card owner, linux gaming is good enough to fill all my gamings needs. There is a big difference between "windows has won", and "linux has lost".
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
Sounds like he has investments, or some other finiancial interests, in embedded linux.
Indeed.
Maybe "desktop linux profits" aren't so hot, but linux wasn't designed to make money with anyways.
On the contrary, I allege that lots of money are going to be made on Linux desktops. Support, mass deployment, customization, life cycle extension... so the money will be made in corporate space, and that's the way it should be. That's where the money in Linux servers is made at the moment.
Also, as an nvidia card owner, linux gaming is good enough to fill all my gamings needs.
The thing is, gaming doesn't matter all that much, again because of the corporate focus. I'm looking forward to the time when every OpenGL game will have Linux binaries on the same CDs. But meanwhile, home users can just dual boot to their war3z windows installations.
Save your wrists today - switch to Dvorak
Yup. And of course XRender knows that, and has decided to punish him.
Not only does he want a good wm and some good libraries, he want's those libraries to be portable to embedded devices, epsecially since that's where he thinks part of the future for Linux is. The drawing library, Evas, has been ported to a number of devices.
// file: mice.h
#include "frickin_lasers.h"
On my linux/itanium system (using NVIDIA's 1.0.4431/IA64 driver), xrender is always much faster than imlib. Here are the reults:
Test: Test Xrender doing non-scaled Over blends
Time: 0.085 sec.
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 0.095 sec.
Test: Test Imlib2 doing non-scaled Over blends
Time: 4.893 sec.
Test: Test Xrender doing 1/2 scaled Over blends
Time: 0.028 sec.
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends
Time: 0.033 sec.
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 1.344 sec.
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 0.328 sec.
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 0.370 sec.
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 28.058 sec.
Test: Test Xrender doing 2* nearest scaled Over blends
Time: 0.323 sec.
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends
Time: 0.370 sec.
Test: Test Imlib2 doing 2* nearest scaled Over blends
Time: 20.745 sec.
Test: Test Xrender doing general nearest scaled Over blends
Time: 0.780 sec.
Test: Test Xrender (offscreen) doing general nearest scaled Over blends
Time: 0.855 sec.
Test: Test Imlib2 doing general nearest scaled Over blends
Time: 45.613 sec.
Test: Test Xrender doing general smooth scaled Over blends
Time: 0.611 sec.
Test: Test Xrender (offscreen) doing general smooth scaled Over blends
Time: 0.849 sec.
Test: Test Imlib2 doing general smooth scaled Over blends
Time: 74.811 sec.
And the results were pretty much the same. Using render was several magnitudes slower on tests 2 - 7. I have a GeForce1 with 1.0.4349 nvidia driver and haven't had the same trouble others have with this option on so I run with this extension on all the time.
t up...
Here are the results for the interested:
Available XRENDER filters:
nearest
bilinear
fast
good
best
Se
*** ROUND 1 ***
Test: Test Xrender doing non-scaled Over blends Time: 0.190 sec.
Test: Test Xrender (offscreen) doing non-scaled Over blends Time: 0.303 sec.
Test: Test Imlib2 doing non-scaled Over blends Time: 0.697 sec.
*** ROUND 2 ***
Test: Test Xrender doing 1/2 scaled Over blends Time: 10.347 sec.
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends Time: 10.231 sec.
Test: Test Imlib2 doing 1/2 scaled Over blends Time: 0.315 sec.
*** ROUND 3 ***
Test: Test Xrender doing 2* smooth scaled Over blends Time: 207.028 sec.
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends Time: 205.275 sec.
Test: Test Imlib2 doing 2* smooth scaled Over blends Time: 5.695 sec.
*** ROUND 4 ***
Test: Test Xrender doing 2* nearest scaled Over blends Time: 164.460 sec.
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends Time: 166.281 sec.
Test: Test Imlib2 doing 2* nearest scaled Over blends Time: 4.119 sec.
*** ROUND 6 ***
Test: Test Xrender doing general nearest scaled Over blends Time: 313.187 sec.
Test: Test Xrender (offscreen) doing general nearest scaled Over blends Time: 310.261 sec.
Test: Test Imlib2 doing general nearest scaled Over blends Time: 11.444 sec.
*** ROUND 7 ***
Test: Test Xrender doing general smooth scaled Over blends Time: 477.511 sec.
Test: Test Xrender (offscreen) doing general smooth scaled Over blends Time: 474.695 sec.
Test: Test Imlib2 doing general smooth scaled Over blends Time: 17.290 sec.
(reformatted to get past the lameness filter)
I'm happy I made the jump, but for most people they're just too scared to try another OS. Windows barely works for them - to try another "hacker" OS is too adventurous/hard. I have a bunch of people on Mozilla now....and they see it's good. Eventually they'll switch after one propblem too many in Windows.
..........FULL STOP.
If you're getting unusual AND nice results, we should know WHY! What kernal, drivers (Nvidia?) Linux version, Graphics card, processor, etc. Maybe we are all missing something obvious. tell us like in a scientific paper, the exact details, so we can VERIFY your results, and maybe YOU could help out the whole community.
..........FULL STOP.
Java 2D (the graphics backend, also used by swing) has been hardware accelerated on windows since ~1.4 by use of directx.
Now it seems that java 1.5 will use opengl on linux to achieve the same (or even better...;) graphics performance as seen on windows.
i.e.: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB .cgi?action=display;board=jogl;num=1060784520;star t=0#6
Decided to give it a try for my Matrox G400, but unfortunately, as soon as I ran his program, it died with a memory fault. It was apparently checking which XRENDER filters were available, then promptly died. All output I got was:
Available XRENDER filters:
Memory fault
This was on Debian sid. Anyone else get something similar?
Six sick
He said that over a year ago, however, when desktop Linux wasn't looking so hot. A large part of his point was that the desktop itself would be going away in the future, except as hackers' and enthusiasts' systems. In fact, he went on to state that if this is the case, Linux has a huge advantage over Windows, since Linux is not nearly as tied into the desktop as Windows is, and will have an easier time adapting to such a setting. So he ported his canvas library to run on embedded as well, without axing it for the desktop. Sounds to me like a wholly reasonable thing to do.
Six sick
Make it work.. don't make it just to attract Windows and Mac users.
If an operating system doesn't have market share, developers of device drivers will tend to ignore it.
Will I retire or break 10K?
-1 Weak joke?
Got time? Spend some of it coding or testing
The 16MB Banshee EvilQueen sitting across the room maps three copies of its 16MB into main RAM (so 48MB total, plus maybe another 4MB for a busy X server); apparently each copy is mapped in a different way optimised for different ops.
Got time? Spend some of it coding or testing
Somebody mentioned below that imlib is probably caching the image, whereas Xrender is doing the transformation everytime. So I thought I'd try the same caching approach with Xrender.
The first time the scale test is called, I rendered the image to an offscreen buffer with the correct transformations set. Then after that I just XRenderComposite to the screen from the offscreen buffer. The results (NVidia 4496, RenderAccel=true, geforce2 MX,athlon XP 1800+) for one test are:
*** ROUND 2 ***
Test: Test Xrender doing 1/2 scaled Over blends - caching implementation
Time: 0.126 sec.
Test: Test Xrender doing 1/2 scaled Over blends - original implementation
Time: 6.993 sec.
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 0.191 sec.
Which shows Xrender taking two-thirds the time of imlib.
My guess is that imlib is probably caching something. This is supported by the fact that Xrender is faster for the non-scaled composition in the original code.
Unless I'm mistaken, XRender is utilizing the 2D acceleration features of a graphics card for scaling, alpha blending, anti-aliasing, etc. It's not trying to do 2D graphics over 3D. Although if you think linux shouldn't be doing that then you really shoulod look at Microsoft, they're moving to an entirely 3D desktop for longhorn.
Who's saying they are/did?
BTW, there's also something called the Stencil Buffer, which is not completely accessible in most 2D API's. It's very useful for your third aspect listed under 2D, "clip output." In that way, using a 3D API would be much more dynamic and faster than using the 2D API.
Basically, the 2D-only API's are limited because some hardware acclerated features on the card are only available by using a 3D-enabled API, like OpenGL. Why waste some of the abilities of the card?
It just depends on what's most appropriate for the task at hand.
This ends up being even more true if you do any sort of complex compositing (eg: alpha blending, hardware accelerated mpeg / video, openGL windows, etc, etc). Enlightenment uses alpha channels, it would be fater to composite in hardware than software. These sorts of operations are not accelerated at all on the 2d path, and have to be done in software.
Go check out Quartz Extreme at http://www.apple.com/macosx/jaguar/quartzextreme.h tml (excuse the space in html).
Having used Xfree86 and Quartz extreme on the same graphics hardware, I can tell you there's no comparison. Quartz is much faster and much more capable.
http://slashdot.org/articles/02/07/20/1342205.shtm l?tid=106
Happy New Year, it's 1984!
That's right, nobody has written anything akin to Enlightenment or edie or evas, and thank god. If Mr. Haitzler's coding skill were as good as it is claimed to be, maybe all those rewrites over the years wouldn't have been necessary. Meanwhile WindowMaker, which is almost as old, sails along with code that's clean as a whistle. Here again we see the responsibility-avoidance mentality of the open source advocate who, in response to criticism, has nothing better to say than "it's your fault for not helping" or "you couldn't do any better anyway."
Is always an operation you want to avoid.
In addition to the OS switching among processes, the OpenGL driver has to perform context switching for the graphic hardware's registers, DMA addresses, etc.
Plus, modern hardware drivers are optimized for games, i.e. full-screen programs. How much context-switching performance do you need? Thus, less development effort, less performance.
The RenderAccel support in the NVIDIA drivers is not complete. That's why its disabled by default. From the benchmark results, it seems that Render wins when there is no scaling involved, and loses badly when there is scaling involved. This suggest an obvious answer --- scaling is not accelerated on the Render implementation on NVIDIA cards! As a result, when scaling is used, the card falls back on a software implementation that is obviously not as good as imlib2's very optimized software implementation. Now, why would NVIDIA bother with Render support if no scaling can be used? Because the only real user of Render at the moment is Xft, which uses it to composit AA text! Of course, the glyph bitmaps are not scaled, because that would reduce sharpness. So NVIDIA released a half-assed Render implementation (they do not, to be fair, that its incomplete, and disable it by default) so the common case of AA-text would get a speed-up!
A deep unwavering belief is a sure sign you're missing something...
Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.
:-)
That's not accurate. Quartz is really made of two parts: Quartz 2D and the Quartz Compositor.
The Quartz Compositor is reponsible for compositing all the layers (desktop, windows, layers inside windows) on-screen. It offers Porter-Duff compositing, which was developped at Pixar more than 15 years ago. See this post from Mike Paquette for details. Mr Paquette is one of the main developpers of Quartz. Quartz Extreme is "simply" an OpenGL implementation of Porter-Duff compositing and modern graphic cards offer the primitives needed to do that very efficiently.
The Quartz 2D layer is what offers drawing primitives following the Postscript drawing model. The same drawing model is used with PDF (no surprise), Java2D and SVG (and Microsoft's GDI+ ?). This part is not HW accelerated. I am sure Apple is working on it, but it wouldn't surprise me if new HW will be required to make this possible. There is a strong incentive for card manufacturers to offer acceleration, since Longhorn is supposed to use GDI+ extensively. I doubt that such acceleration will fit in the traditionnal OpenGL/Direct3D rendering pipeline.
The Apple JVM team implemented HW accelerated Java2D drawing in their 1.3.1 JVM. Their 1.4 JVM doesn't offer it (1.4.1 was a massive rewrite for them, 1.3.1 was more of a quick port to OS-X using some of their "old" carbon code). There were quite a few problems when HW acceleration was used. I hope they can and will wait for a system-wide Quartz-2D HW acceleration, it seems ludicrous to have the JVM team spend resources on an effort that will be wasted once Quartz2D is accelerated.
See Apple Marketing page, another post from Mike Paquette, and the presentation from Apple at SIGgraph about Quartz Extreme and OpenGL.
If that post doesn't end-up rated +5 informative, I don't know what will !
The network layer in X11 isn't an issue. By default applications use unix domain sockets. Which is about as light-weight as windows messaging.
.. Well honestly the fastest widget library is everyone's least favorite... Xaw .. .If you want to include all the 3rd party libraries as part of X and somehow blame it on X, then I really have no defense. Of course I could write a cool widget library tomorrow and then you could only complain about how everyone wasn't using my ultra fast/easy library.
In your post, you seem to really be talking about the way a particular implementation of X11 is. XFree86.
The X protocol is VERY fast to parse and extremely expandable. The bad part is that it is quite verbose. X protocol does have high-level functions, but not in the same way you think of them. Take the PostScript extensions for example. You can set up the set of vector operations to draw some button in postscript, send it to the server and draw it 50 times over in different places. Of course nobody uses these "new" (3 year old) extensions.
Libraries that are a drag? Are you refering to things like QT, GTK, Motif, etc?
X's accelleration is broken down into a set of primative operations. X doesn't take advantage of every possible accelleration that your hardware has. It tends to only support things that the X protocol is capable of expressing in a single command. But that's XFree86, there are other X11s that run on other hardware. I assume PC graphics cards' 2D accelleration are design to be easy to interface into Win32, rather than being highly generalized. I've never written a win32 driver before so I don't really know.
“Common sense is not so common.” — Voltaire
I have no desire to kill Windows or MacOS or win all their customers over. I want a tool designed specific to my needs. That's how Linux got to be so good in the first place. Changing our methodology to try to win your average users will hurt us in the end. If there is a feature of Windows or MacOS you truely like then add it but don't go out of your way to clone those interfaces. If those users like what you've done they'll use your interface.. if not maybe they'll stick to what they already know. It does little good to have choices in which tool you use if all the tools are exactly alike.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
So the simple solution would be to make your own devices.. something that i already becoming quite popular. If you design it and license it free of cost you'll have somebody willing to manufacter and sale it.. and obviously if you design it then you can make the device drivers for it. ;)
There is something to be said for your argument in the short term but I don't think that cloning Windows is going to get Linux the user base it needs to get these drivers. Instead we need to be lobbying the large companies that have a Linux interest for their support.. IBM, HP, etc.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
rename the benchmark 3dmark2003.exe
But a GUI is not composed of (overlapping) polygons.
This ends up being even more true if you do any sort of complex compositing (eg: alpha blending,
Alpha blending is a mistake for GUIs.
hardware accelerated mpeg / video
Windows does fine accelerated video, even with cards with 2d functionality only.
openGL windows, etc, etc).
Rendering OpenGL within a Window has nothing to do with the 3d hardware(especially the Window part). You can render 3d using the video card's 3d engine, but the rest of the GUI (which is composed of windows) does fine with 2D.
Enlightenment uses alpha channels, it would be fater to composite in hardware than software.
Translucency is wrong in a GUI. Believe me.
These sorts of operations are not accelerated at all on the 2d path, and have to be done in software.
You only mentioned two: alpha blending, which is irrelevant to GUIs, and hardware MPEG decompression, which has nothing to do with 3d.
Go check out Quartz Extreme at http://www.apple.com/macosx/jaguar/quartzextreme.h
tml (excuse the space in html).
I read it. Plain BS. Here is why:
Quartz uses the integrated OpenGL technology to convert each window into a texture, then sends it to the graphics card to render on screen
And why is that ? just to have drop shadows and translucency ? I certainly don't want translucency, as it is a pain in the ass to work with translucent windows...Windows have very nice antialiasing (ClearType)...I don't need anything else, and I certainly don't need to make each window a texture and waste all the memory.
The graphics processor focuses on what it does best -- graphics -- freeing the Power PC chip to do more operations in the same amount of time
I agree that custom chips should handle trivial things, but why 3D? this functionality should have been incorporated in the 2D engine.
The new Quartz delivers device-independent and resolution-independent rendering of anti-aliased text, bitmap images and vector graphics
Windows does that already.
addition, Quartz can both save and print transparency and the Preview application honors PDF file security. A "Save as PDF" button in the Print dialog streamlines PDF creation
What does a graphic engine have to do with file security ???
Jaguar adds more high-quality fonts to the already exquisite collection, so those who use non-Roman languages such as Arabic, Hebrew and Thai can communicate in their native tongue
Nothing Windows does not have a long time now.
Basically, you don't seem to know how a gui works. Since I have made a complete Window System, I can tell you that it's a big waste of resources to redraw things in a texture, then use 3D to compose the screen.
Of course, you are a proud Mac owner. I can understand that(I just don't understand why you were modded as 4).
Having used Xfree86 and Quartz extreme on the same graphics hardware, I can tell you there's no comparison. Quartz is much faster and much more capable.
Then blame XFree86, don't throw it on the lack of 3D under Linux. XFree86 does not have as a good font rendering as Windows or MacOS, and that is a problem. The other stuff you are mentioning is kiddie's stuff(alpha blending, although impressive, it's like giving candies to children: good for psychological reasons, bad for anything else).
You've obviously not configured many things if you think Windows is overall easier than Linux. Clicking your way through pretty menus is a lot more effort than paging through a config file. Either way if you don't know what the options mean you're most likely going to get less than optimal results. :)
Not that I'm against making things easy to configure.. I just don't think Windows manages to live up to that hope. As for myself I'm mostly interested in making tools that makes it easy to configure and manage large numbers of machines from a single interface on a single machine. Even ssh'ing into different machines is a pain if you have to do it to often. Also I like to have server options abstracted so that they are the same regardless of the product be used to provide the service. ie I want to be able to configure all web servers with the same config spec, all email servers, etc.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I hope you never need any csenon gas or play the ksylophone
8)
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
dontcha know 8)
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Although you have this unreasonable user id and I might sound as a troll I just have to reply to this;
:-)
There is no "way" of writing "proper" code. There is no path leading to good code. Only hinches and guess work.
You know why?
Because computer programming is not a science. Its not a set of building blocks from which you can construct one uniform way of doing stuff. it's not electronics, it's not house building. it's the alchemist job. Turning junk into gold.
You, in some level, claim to have some sort of a key or a solution, you are the code alchemist. a guru pertaining to have the answer.
There is no answer and there wan't be in the near future. As with gold made out of junk - chemist today knows how to do it, it costs about 100 times the gold produces, but there is a way.
Someday, probably after we will be gone for good someone will find the way, giving a tool with which good programs will be born but this way is far far away in the future and all we can do now is decide which of the alchemists we want to be - the one giving false hope or the one actually coding.
I hope this wasn't too bad.
I'll give myself +5 insightful for this one
Total disagreement, for the most part. 1) Extensive changes were made to the 'standard' windows-style GL implementation to make this possible. First and foremost, the complete virtualization of VRAM and some rather brainy texture management inside the implementation, to enable windows with backing stores to be easily shifted into/out of VRAM. 2) 2D composition is a *large* part of windowing systems' work. Moving a window becomes moving a textured quad; screen position no longer comes into play, nor does blitting large volumes of data when windows open, close, or otherwise move. Eliminating that first element of composition, at the window level, means that you can eliminate the cost of operations that users *expect* to be responsive. Regardless of how you feel about *anything* else, these two elements make possible what is a much more fluid windowing environment as a result. The ability to do anything else - whether we're talking about transparency effects, scaling window contents, or general eye-candy, are usability issues. What this does do is enable a whole new set of possible UI features. I'm not going to argue with you - you're entitled to your opinion. Perhaps you'll change your mind once Longhorn comes along and you're using it on your desktop; maybe you'll still think it's pointless then. I'll say this though: Any user who's ever enabled and disabled Quartz Extreme on their desktop mac will see the difference - and it doesn't matter whether you turn off transparency and shadowing effects to see that difference. Move that window, and you'll see it.
-- A mind is a terrible thing.
But it can't be done on X-Windows!!! It's easy to do it on the Mac, because the Mac only has ONE LEVEL of windows. Whereas in X-Windows each little rectangle is a Window. Surely you don't expect every little button on the screen to be its own texture. You will need huge amount of VRAM for that.
That's why I say that it is impractical. Just because the window moves a little bit smoother, it just does not justify the use of 3D, especially under X-Windows.
No - we're talking about compositing here; you can pretty much make every little rectangle a separate bitmap and, quite frankly, get away with it if your GL implementation does the same kind of texture optimization that Apple went through. After all, they're already all little bitmaps, in many cases, being held around in memory and then composited. Smart AGP/VRAM usage means that having to worry about where this stuff is becomes a lot less important. What you're doing is representing a 3D screen - even if you're removing all of the dimensionality of perspective from that. 3D hardware does this a lot better than just 'average', and Quartz Extreme users are the first to get it; Microsoft users of Longhorn will see something like it next, two generations behind where Mac users will be by the time Longhorn hits their desktops. Building a strong compositing engine using 3D operations is not only efficient, it's practical and effective. I have no doubt that, even if you're unwilling to come round now to the idea, you'll change your tune in two years - at which point, you'll be there alongside everyone else screaming that Windows has been doing this for years now, so it's time to change XFree86. The GL work *alone* to make this kind of thing efficient and work well isn't insurmountable, but it's a great deal of work. The community can choose to see the benefits that these changes to GL would allow on Linux, and virtualize texture memory on all supported cards, or wait until everyone else's implementations are already doing it. Someone wanted to know why Apple didn't get it added to 2D hardware accelerators: Simple. Apple, with 3% marketshare, does not call the shots. Microsoft does. Rest assured, now that Microsoft has seen fit to follow Apple into the land of accelerated composition on 3D hardware, we may indeed see some cool stuff come out of hardware; but let's not pretend that anyone other than Microsoft is in a position to do that dictation.
-- A mind is a terrible thing.
i guess that turned out to be a waste of time