Slashdot Mirror


User: be-fan

be-fan's activity in the archive.

Stories
0
Comments
8,382
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 8,382

  1. Re:Plasma Project (KDE 4.x branch) on KDE's future: Plasma & SimpleKDE · · Score: 1

    What the fuck are you talking about? It's CVS branch in preperation for the KDE 4.0 release, not a fork!

  2. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 1

    I think what you're forgetting is, during these 50,000 cycles your app doesn't have to wait. Last time i checked DMA'ing was done mainly independent of the CPU, so your app can keep doing things in the mean time.

    It doesn't make a difference to your graphics performance. Having those 50,000 cycles free only helps you if you're CPU-bound. When drawing complex graphics, you're rarely CPU bound. In any case, even if you reduce the setup and context switch overhead to 0 cycles (and you do an upload say 120 times per second --- twice per frame), you're talking about a fraction of a percent of overall CPU time.

    Also it's not one context-switch but two: one to X and one from X.

    I took that into account. A single context switch is on the order of 1000 cycles, two is on the order of a "few thousand".

    Now you see a different picture: a couple of hundred cycles vs several thousand cycles.

    And it's all completely overshadowed by the real bottleneck, drawing things on the graphics card!

    And your part about synchronization .. please don't tell me you want to add another context-switch to X, just to synchronize every now and then?!

    The context-switch overhead is nothing. If you resize at 30 fps (I have it rate-limited because anything faster is wasted), you have roughly six context switches per frame (between the window manager, the client, and the X server). At 1000 cycles apiece, that's 180,000 cycles per second, which is noise.

    This is the kind of stuff why X needs to do many more things 'direct' via system calls. This synchronization can be implemented way more efficient with kernel primitives then with messages being sent back and forth.

    Let's see. Your tradeoff is less than a 1% performance gain for putting a million lines of code into the kernel. Brilliant!

  3. Re:Idealism not Realistic on China Planning For Sustainable Cities · · Score: 1

    In the Real World (TM), capitalism isn't the perfect model for sustainability. In a lot of places (think villages in third world countries), capitalism has no traction. The "leave everybody free to do what they want" idea doesn't create any forward progress. Capitalism has certain prerequisites (eg: law and order, the existance of a free market among large numbers of people), etc, that just aren't fulfilled in certain parts of the world. It seems to me that in retrospect, the Chinese communists are ultimately good for capitalism in China. The communist rule will inevitably fall away, but the national unity they created (unity being a prerequisite for a market), and the law and order they brought to China will survive.

    One only has to look at the post-Soviet world to realize that freedom is not a sufficient condition for capitalistic prosperity. Napoleon is a pretty good example of this idea at work. Napoleon, a dictator who ended the French Republic, was instrumental in industrializing France and turning it into a rich, prosperous nation. Prior to Napoleon, France's markets were fragmented, as there was no national unity. It's code of law was inconsistent, with merchants being taxed multiple times for the same goods within the country. Without Napoleon, things would have remained in that state, and capitalism could not have taken root in the country.

  4. Re:Sustainable for how long? on China Planning For Sustainable Cities · · Score: 1

    Isn't that what I just said? "Sustainable" means designing something that doesn't require constant external input to keep going. It doesn't mean something that can't be destroyed by natural events.

  5. Re:as they so succinctly put it themselves... on Women Control the DVR · · Score: 1

    Oxygen is a TV network for women. It's like less respectable version of Lifetime...

  6. Re:My Mom on Women Control the DVR · · Score: 2, Funny

    LOL. Ask you average man how to extract the video data off the hard drive...

  7. Re:this is obvious, isn't it? on Women Control the DVR · · Score: 1

    I thought it was women that were supposed to be illogical? One of the guys below did a pretty good job of showing why your argument was asnine, so I'll concentrate on this "it's not as wrong as society would like you to believe". That's a logically flawed point in and of itself. The fact that society might or might not have a particular bias one way or the other doesn't change the fact that your argument , objectively, makes no sense. There could even be a fast left-wing feminist conspiracy, and you'd still be wrong...

  8. Re:as they so succinctly put it themselves... on Women Control the DVR · · Score: 1

    Oxygen. TV for stupid people...

  9. Re:Boil water first... on China Planning For Sustainable Cities · · Score: 1

    That's not surprising. Singapore has incredibly clean water. It's much cleaner than anything you'll find most palces in the US.

  10. Re:These kind of initiatives are pointless on China Planning For Sustainable Cities · · Score: 1

    Actually, there is nothing to say that those choices are necessarily correct. A free society gives people the option to act in their rational self interest. That does not imply that the decisions people make are necessarily in their self interest. The fact that people are free to make their own choices does not prevent one from judging those choices.

  11. Re:These kind of initiatives are pointless on China Planning For Sustainable Cities · · Score: 1

    Actually, it's not quite so simple. In our society (and I'd argue that ours is a free society), we aren't completely free to lead the lifestyle we want. It's a product of economic theory that our government forces us to do certain things we don't want to, for our own good. For example, we invest in defense. Do you think people want to pay 4-6% of their paycheck funding the military? Do you think if, given the choice, they'd do so voluntarily? Hell no! But if we don't want to be taken over by Mexico, well, we have to spend that money, and the government has to make us do it.

    Now, that is not to say that the environment is necessarily like defense. While economic theory has defense pinned down pretty well as something that requires government intervention, it hasn't proven the same thing for the environment. However, there are a lot of similarities between the two cases, and it's certainly a possibility. It would be silly to dismiss the possibility outright.

  12. Re:Idealism not Realistic on China Planning For Sustainable Cities · · Score: 1

    I don't think you quite understand the meaning of "sustainable". The term "sustainability" has a very specific meaning in international development circles (it's technical jargon). It has nothing to do with "freezing something in time", but rather, refers to improvements that can be made and sustained within a society without external input. Ie: a sustainable health initiative is something that can improve a particular health indicator, without constantly requiring doners to fund the project.

  13. Re:We've seen this utopian horse-hockey before on China Planning For Sustainable Cities · · Score: 2, Insightful

    Do you actually have any idea what this guys ideas really are? He's not trying to shove anything down anybody's throat. He's doing exactly what you're suggesting, taking new technologies (and some old ones) to make our current way of life more sustainable. Eg: designing factories that have natural light and airflow to reduce cooling and heating costs, as well as to make workers happier. Formulating chemicals specially so the factories that produce them produce environmentally-safe "wastes". There is nothing "utopian" about it. His basic idea is "people should have what they have, and more, and it can be done sustainable with improved technology".

    If you're taking exception to the "sustainable village" bit, use your head. Much of China's population lives in villages. Making a better village fits right in with "living as you are now, except better and more sustainably".

  14. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 3, Interesting

    You said that X should use something like the DRI/DRM for all graphics ops, like Win2k, and DirectFB and Quartz 2D Extreme do. DRI/DRM is the OpenGL (3D) driver API. It doesn't just mean "kernel-mode graphics driver". Win2K and DirectFB don't use 3D driver APIs to do 2D operations. Quartz 2D Extreme does, and Microsoft's Avalon will.

    PS: DirectFB is a very dated architecture, as is DirectX. Modern graphics cards don't like apps to directly touch video memory or directly bang registers. Its touch to synchronize direct access with the GPU. They are built for the OpenGL ICD model, which depends on a protected kernel driver uploading command packets to the hardware. Indeed, "direct access" is going away in DX10, which will debut with Avalon.

  15. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 2, Informative

    It doesn't really matter. It's the buffer upload to the graphics card that costs tens of thousands to hundreds of thousands of clock cycles. The context switch only cost a few thousand clock cycles, so unless you're scenes are very simple (ie: your buffers are tens of kilobytes instead of hundreds of kilobytes or megabytes), then its not the context-switch that's the bottleneck. Of course, if your scenes are very simple, it doesn't really matter how fast your graphics are!

  16. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 4, Interesting

    Of course you're right. I know that's what's really going on. But that doesn't make my argumentation less true: running things "directly" via system calls is a lot faster then going via X.

    Yes, it's strictly faster. The question is, how much faster is it, and where is the bottleneck? A context switch is on the order of a few thousand cycles, while a system call is on the order of a few hundred cycles. Meanwhile, uploading a 100KB DMA buffer over the PCI-Express bus is on the order of 50,000 cycles. Even if you reduce the context-switch overhead to zero, you're still only improving performance by around 6%.

    Why do you think DRI/DRM is a lot faster than 'indirect' opengl?!

    Because indirect OpenGL is not hardware accelerated!

    If you don't beleive me, check the numerous articles about why w2k has this in the kernel (as opposed to winnt3.5/winnt4)

    Actually, NT4 put graphics in the kernel. Of course, Windows NT 3.x also had a much more micro-kernel design, so its hard to say where the performance improvement came from.

    why macosX now has quartx extreme 2d

    MacOS X has Quartz Extreme 2D because it allows hardware acceleration of 2D, not because it reduces client/server overhead.

    why dri/drm is so much faster.

    Because it's accelerated...

    I don't think you really understand what you're talking about. Having done some programming on the subject myself, I can say that the bottlenecks in X aren't really where people think they are. The top bottlenecks in X GUIs like KDE and GNOME are:

    1) Synchronization. Konqueror on my 2GHz P4 can relayout and redraw Slashdot at like 20fps. Should be enough for smooth resizing, right? Wrong! There is no synchornization between window manager and client in X. The window manager would redraw the window frame a hundred times per second, and not let the contents catch up. Once you fix that synchronization problem (eg: via the SYNC counter spec), it becomes very smooth. The truth of graphics is that no matter how fast it is, it will never look "smooth" without synchronization. X doesn't have support, by default, for that synchronization.

    2) Text layout. Pango (what GNOME uses for text layout) is glacially slow. That's why resizing gedit windows is slow, not because X can't draw things fast enough.

    3) Text compositing. Only a few drivers properly accelerate XRender. Other drivers have a software compositing fallback, which is glacially slow because it requires the CPU to read/write to video memory over the AGP/PCI-E bus.

  17. Re:HP is the walking dead on HP to Layoff 15,000 Employees · · Score: 3, Funny

    There is a recent HP commercial that I think is precious. They do this big commercial about the "HP Apple iPod" (ie: the product Apple developed and HP is merely reselling), then at the end the HP tagline chimes in: "HP - Invent".

  18. Re:*blink* *blink* on Debian Sid Moves to X.Org · · Score: 1

    PS> I don't suppose you know why GNOME is completely fubared in sid, do you? Somethinga bout libaspell15 not being installable?

  19. Re:*blink* *blink* on Debian Sid Moves to X.Org · · Score: 1

    LOL. I got bit by the same thing last night. THe libglu1-xorg thing is pissing me off, though, because gdm, startx, etc, depend on one version, while xine depends on another. I can't have them both isntalled simultaniously...

  20. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 3, Informative

    Except that's not what DRM/DRI does, nor what XFree86 does. When you call XDrawLine(), it just queues some things in a buffer and returns. When the buffer is full, there is one context switch to deliver all the buffered commands to the X server. This is actually what Windows does too, btw, except instead of having an X server, it has a "Win32 server" in kernel mode.

    DRM/DRI work similarly to X (and similarly to how OpenGL works on Windows). When you draw a primitive, it puts some things in a command buffer. When the buffer is full, an ioctl() on the graphics card DMAs the command buffer to the GPU, which then draws all the lines, triangles, etc.

    Doing a system call for each line would be painfully slow, since system calls cost you a lot of cycles. Even if you had the graphics card mapped directly into every process, so they could bang registers directly (which would be dangerous, but this is hypothetical), you'd still want to batch the primitives into a buffer, because small writes over the AGP bus are very slow. Now, once you're batching calls anyway, doing a kernel call to upload the buffer versus doing a context switch to upload the buffer doesn't make a whole lot of difference. Even if the latter is several times slower, you're not executing buffer flushes all that often anyway.

  21. Re:Under the hood ... on Debian Sid Moves to X.Org · · Score: 1

    Windows and DirectFB don't do anything like that right now, only Quartz 2D "Extreme" does.

  22. Re:No Price on Shrimp Bandages Clot Blood Faster · · Score: 1

    That's a silly statement. How much would you pay to save a human life (especially someone you don't know?) I presume you don't own any nice things, after all, how can you spend $25,000 on a car, when you could get one for $5000 and save dozens of peoples' lives with the remainder?

    Human life is only worth as much as it is worth to us. That worth can range from hundreds of thousands of dollars for people we know and love, to less than $10 for people we don't care about (ie: starving children in Africa). That's just how human beings are programmed.

  23. Re:A practical example on Open-source Licensing: BSD or GPL? · · Score: 1

    I think that's a perfect example of why GDB is licensed the way it is. The GNU debugger is meant for the GNU system. It's meant to make lives easier for people using GPL code, not other people. So it seems to me that its working precisely the way it is intended to work, and indeed, precisely how the authors want it to work. They have no interest in you using their code. They gain nothing from it. Ergo, the license doesn't let you use their code. It's exactly as it should be.

  24. Re:Outstanding on Longhorn to Require Monitor-Based DRM · · Score: 1

    Heh. I passed that mark in 1999. But I still have to use it because I maintain machines for family and friends :(

  25. Re:NVIDIA's other Tech on NVIDIA's Lead Scientist Interviewed · · Score: 1

    A study like that strikes me as kind of stupid. Of course the performance benefits aren't that great. Current games are written for current cards. If a certain technique performed poorly on previous cards, game developers wouldn't use it extensively. What I'd really like to hear is whether game developers find the technique useful enough, now that its accelerated, to use it more in games.