Announcement

Collapse
No announcement yet.

Radeon Gallium3D Still Long Shot From Catalyst

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rakot
    replied
    Originally posted by bridgman View Post
    We have also recently added two experienced developers (three actually, but since one was replacing Richard I'm only counting two) who IMO are and will be as productive or more over the next year or so than a half dozen developers hired and brought up to speed on the job. Just a thought...
    Out of curiosity, did you guys consider to make something like GSoC for developing some features of the driver? IMO it's very interesting idea to pay a developer to improve, e.g., power management.

    Leave a comment:


  • bridgman
    replied
    Originally posted by Qaridarium
    its sooooo simple: if c++ is a no go for the kernel then you have to rewrite it to push ALL the graphic stuff into the kernel.

    sure the other way is: give a fuck about linux(opensource) and spend all the "linux" money on closed source "Android"

    in my point of view android is just another excuse to not support linux on "Desktop"

    next time microsoft start there own linux version with directX and FUD and then they hurt linux from the inside.. LOL...
    Step back a minute... with every response you make the work required to move userspace drivers into the kernel is going up, but the benefits are staying the same (or going down because of the diversion of existing developers). This isn't looking good.

    The term "give a f*ck" in English actually means "caring", I think the term you're looking for is "don't give a f*ck".

    You're confusing me with the "Android is an excuse" comment. 30 posts ago you said that Android was Linux and therefore its market share should be counted as Linux. Now you're saying that working on Android is just an excuse not to support Linux on the desktop ?

    I don't understand the MS comment.
    Last edited by bridgman; 03-25-2012, 08:52 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by RussianNeuroMancer View Post
    You mean top-GPU in 8xxx series? Or something beyond?
    Correct, assuming we stay with the HD <gen>xxx model. Sea Islands and the 2013 APUs on the latest roadmap :

    http://www.anandtech.com/show/5491/a...admap-revealed

    Originally posted by Qaridarium
    i don't care about intel shit in an AMD tropic. the solution is easy just put the intel shit into the garbage. we need a AMD/VLIW compiler ! and not a intel JOKE. the intel compiler is not VLIW ! you only get 1/5 of the speed with amd hardware this is just an FUD attack from intel on AMD!
    Q, the GLSL compiler is up in the Mesa common layer and is used by all GPU hardware, not just Intel. It takes GLSL (and GL assembler IIRC), converts it to GLSL IR, which is then optionally converted to TGSI or Mesa IR if that's what the hardware driver accepts (radeon and nouveau take TGSI since they use a Gallium3D layer).

    The IR passed down uses short vectors for pixel and coordinate data, which can be converted efficiently to VLIW in the hardware layer. Scalar variables in the GLSL program are passed down to the hardware layer as scalars, and that's where VLIW hardware needs a fancier compiler in the HW driver layer to maximize efficiency.

    Anyways, it's in no way an "Intel compiler", except to the extent that the Intel devs were nice enough to take on the task of writing it.
    Last edited by bridgman; 03-25-2012, 07:36 PM.

    Leave a comment:


  • RussianNeuroMancer
    replied
    Originally posted by bridgman View Post
    for the next generation we are starting sufficiently early that we should be able to hide both development and review in the pre-launch window where it doesn't impact users or community developers
    You mean top-GPU in 8xxx series? Or something beyond?

    Leave a comment:


  • mattst88
    replied
    There's a serious inability on your part to participate in a reasonable discussion. I probably shouldn't bother responding, but I'll do it only once more given the lack of meaningful response.

    Originally posted by Qaridarium
    "The GLSL compiler, for instance, is C++ which is a no-go for the kernel."

    LOL there is no real GLSL compiler. you can rewrite this sad piece .
    the status for the GLSL compilers for the r600 are "Sad" and yes maybe we will never get a good VLIW compiler. this means its a death horse.
    The GLSL compiler, you know, the one that Intel wrote? http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl

    It's C++.

    You're incorrectly thinking about the piece of r600g that translates some IR to hardware instructions.

    Originally posted by Qaridarium
    "Then there's that you can't do floating-point operations in the kernel, which are obviously quite important for OpenGL."

    you miss an important step in your argument why should this be a no go?

    or do i have to ask linus ? LOL
    I can't tell if that's a particularly sad attempt to dodge a very real difficulty of moving user space code into the kernel, or if you actually don't understand.

    I'll assume it's the latter and waste a bit more of my time explaining it to you.

    From the kernel documentation (http://git.kernel.org/?p=linux/kerne...g.tmpl;hb=HEAD)

    Code:
    No floating point or MMX
          The FPU context is not saved; even in user
          context the FPU state probably won't
          correspond with the current process: you would mess with some
          user process' FPU state.  If you really want
          to do this, you would have to explicitly save/restore the full
          FPU state (and avoid context switches).  It
          is generally a bad idea; use fixed point arithmetic first.

    Leave a comment:


  • mattst88
    replied
    Originally posted by Qaridarium
    sure but your argument about the kernel source size is still bullshit.

    20 years ago the kernel source was so much smaller maybe we should use a time travelling engine to go back in time to be sure the kernel source is smaller...

    this is just bullshit!

    and hey don't write code this makes the kernel source bigger ans we all know this is "bad" LOL

    Bridgman bullshit logic at work..
    Size isn't the only factor to consider in something like this.

    I think what you're suggesting is to move all of the 3D stack into the kernel. This would include the GLSL compiler and a lot of other core-Mesa components. The GLSL compiler, for instance, is C++ which is a no-go for the kernel. Then there's that you can't do floating-point operations in the kernel, which are obviously quite important for OpenGL.

    Also there's the issue of security -- moving thousands of lines of code into kernel space...

    Leave a comment:


  • bridgman
    replied
    That is a *great* idea !

    Leave a comment:


  • darkbasic
    replied
    I figured out how to make radeon better than catalyst: every time quaridarium writes some bullshit, instead of wasting your time replying you should write a couples of lines of code. At such a pace I'm pretty sure radeon will double catalyst's performance in no more than a month.

    Leave a comment:


  • idontlikebridgman
    replied
    I'm sure if bridgman wasn't in the way all the time, r600g would be in a much better state. I wish this kid would just go away..
    Last edited by idontlikebridgman; 03-25-2012, 02:56 PM.

    Leave a comment:


  • bridgman
    replied
    That's like putting my pickup truck in my pocket so it's always there when I need it

    The open source userspace stack is >10x the size of the kernel driver, and the proprietary userspace stack is >50x and approaching the size of the entire Linux kernel. I don't think there would be a lot of joy among the kernel developers if we tried to move all that into kernel space.

    The multimedia API framework is quite different between Android and X/Wayland. They may converge over time but right now they are very different.
    Last edited by bridgman; 03-25-2012, 02:52 PM.

    Leave a comment:

Working...
X