Announcement

Collapse
No announcement yet.

Port fglrx openGL stack to Gallium3D

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

  • #16
    Originally posted by rohcQaH View Post
    linux kernel: 12 mio LoC
    fglrx: 15 mio LoC (source)

    That thing is huge.

    But the comparison isn't toally fair. While the linux kernel includes drivers for a whole lot of hardware (not just GPUs), fglrx is more than a kernel module. Most of the driver is userspace stuff.
    well another thing is that fglrx is code share development, so many of those lines of code are not necesarilly linux specific i think, probably they can have some sort of compiler filter to compile for each os, not sure though, but if that is the case then probably the linux kernel is much bigger than the linux specific of fglrx, maybe

    Comment


    • #17
      Hell you are Good... 1A++++++ Good Job !

      the Opensource driver will have openGL4 and OpenCL and viedeo acceleration faster than FGLRX fix any of your bug!



      Originally posted by jrch2k8 View Post
      fair enough


      no way in hell


      well if you mean feature wise, aka at least the X or Y function is there and respond something good or wrong, yes ofc the OSS is pretty recent, that one is ovbious. now that it does the job and it do it perfectly or good enough, well no before ati was bought by amd, not 2 years ago, not 6 month ago, not today with the latest driver


      little regression???? for real??? you call fglrx little regression? you own an AMD card? have you tried crossfire?

      now seriously, i could call a glitch that maybe the got wrong certain function or well nvidia do some trcikery and got everyone using an X extesion in a non standart way so amd have to adapt it or figth it BUT

      * 2d slowliness is not a glitch, i mean really i have 2 4850x2 (3200 cores) and i can see how the pixel get rendered 1 by 1 lol, that's no a little regression
      * 3d well, fglrx is cool to hit 20000 in glxgears, everything else you can expect any sort of issues that goes from sigsegv, kernel panic (this are quite funny btw), running out of disc cuz the massive syslog warning from the kernel, wine is unusable even in some 2d apps, many native games fails to run (i give ya, this could be partly fault of the engine), shader get messed up depending the driver version (fglrx driver version choose process is as complex as select a good wine lol), composite well that is a beast of issues on his own that again go from massive slowness to massive memory leaks depending the driver version, that is not a simple regression.

      *crossfire, well if in X driver version works (some version do, some version crack the hell of the mother of the kernel panics) normally is massive slower than windows, make games more problematic than normal (well in ubuntu beta driver improved a bit, at least the kernel panic dont force me to remove the power plug of my pc and happen less often), either way crossfire is something you want disabled unless you tested it enough

      OpenCL, well is still beta i think, but im my testcases, well the library is there but it has too many issues. we were trying an opencl book example and it runned just fine everywhere aka (winX/mac/nvidia/AMD) but never in amd linux(the sdk provide a diff driver but you need to downgrade half distro to use it, i didint try it, at the end i just stopped caring). but well this is not a simple regression but i give you that having the source code of that library could accelerate OSS own's opencl development speed

      UVD, well is basically garbage without a nasty combo of version library's, but well if you get it to at least render, well is not even close to vdpau or OSS XV quality, beside in my case, hung my computer after 35ishm of playing hd content (at least for me dont worth the figth, for me is easier just to put a gtx240 in my htpc, wich is like 3m lol), another not a simple regression

      GL4, again could work as reference but is still very inmature and buggy, at least unigine heaven demo was very slow, aka my 8800gts 320 almost beated my quadfire with 3200 cores (i guess still need work cuz this api is too new), well i musts say is more like gl 3.3 cuz my card is 4xxx series, now i dont doubt maybe evergreen is a beast in gl4, aka the optimize it only to show off in evergreen, who knows

      well, you name advanced memory manager, i would say advanced memory leaker, but well at least has got better than the 9 series of fglrx, and in very powerful system is less noticeable (still i dont like my gfx to steal 1gb of my ram but wth i have 7gb more to work) (i mean i log without anything 3d and the memory for as long as i work is around 500mb, now if i activate let say compiz or kwin in 30m my ram is getting near the 2.2gb and so on until it finally get stuff slower and i have to restart the xorg, obviously i tried with different distros and the OSS driver and it doesnt happen )

      i dont say fglrx is completly worthless, i believe that hiring a nice QA manager they can improve a lot in the next years, my point is this bug'S arent few simple regression, this many bug are very heavy problem that even in the case of been released bu amd (which wont ever happen. btw. several thread about it), the community will have to wait a huge time to get something that worth the effort, up to this point i dont see the need of get fps parity with fglrx at the expense of all the time fixing those bugs, when the open stack can be much simpler to maintain and not that slow away from fglrx (when the optimization process get there obviously), and well opencl cant be that hard (is supposed to be royalty free from scracth so maybe get the docs should be easier for amd to release)

      Comment


      • #18
        Originally posted by jrch2k8 View Post
        well another thing is that fglrx is code share development, so many of those lines of code are not necesarilly linux specific i think, probably they can have some sort of compiler filter to compile for each os, not sure though, but if that is the case then probably the linux kernel is much bigger than the linux specific of fglrx, maybe
        imagine it: every line of code have this. #this line/part is only to bugfix the clousedsource windows system...

        the real overall code is just 10 lines

        Comment


        • #19
          Originally posted by crazycheese View Post
          Some facts from me, to support jrch2k8 points:
          On E5300,2x2gb ddr2-800, nvidia 9800gt green did 95000 points in non-composite and 80000 points in composite mode.
          Same hardware HD4650(I acknowledge its tons weaker) did 6000 points(but not to this extent!).
          Repeat after me: glxgears is not a benchmark. Don't try to use it as one, because its results are FUCKING INVALID.

          There, better now?

          In fact, fglrx performs identically to the Windows driver in OpenGL (sometimes slightly faster, too). The rest of your points are being addressed as we speak (better 2d acceleration, video acceleration).

          Bah.

          Comment


          • #20
            Originally posted by BlackStar View Post
            Repeat after me: glxgears is not a benchmark. Don't try to use it as one, because its results are FUCKING INVALID.

            There, better now?

            In fact, fglrx performs identically to the Windows driver in OpenGL (sometimes slightly faster, too). The rest of your points are being addressed as we speak (better 2d acceleration, video acceleration).

            Bah.
            thats a lie if you use windows you use dx11 and the catalyst is much faster in dx11 in the same 3D rendering scene compare to an openGL4 one!

            thats because there is no full-featured ogl4 driver right now...

            in my point of view they only try to kill openGL with there Windows-DirectX 'first' strategic!

            your OGL argument on windows is just a joge because all modern engines do have a nativ directX render path!

            in the end the openGL users are the losers at this game called the 3D war!

            Comment


            • #21
              Originally posted by BlackStar View Post
              Repeat after me: glxgears is not a benchmark. Don't try to use it as one, because its results are FUCKING INVALID.

              There, better now?

              In fact, fglrx performs identically to the Windows driver in OpenGL (sometimes slightly faster, too). The rest of your points are being addressed as we speak (better 2d acceleration, video acceleration).

              Bah.
              Yes, I have read this on unofficial ATI site, when I had the card im my hands.

              fglrx: OpenArena 40-60fps(fullhd,maxed out).

              nvidia: With 9800gt - 300fps(fullhd,maxed out).
              (for comparsion, 6800gt with gddr3 (asus v9999) on athlon xp 3200+ -> 120fps fullhd, maxed out)

              Technically 4650 is weaker than 9800, additionally 4650 - 128bit DDR2; 9800 - 256bit GDDR3. So I think this is because gpu staves for the lack of ram bandwidth.

              But then nvidia makes crap and closes drivers whilst ATI does A LOT for opensource drivers, so I bought hd4770(faster chip than 9800gt, 128bit GDDR5 on 4770==256bit GDDR3 on 9800; lower idle power consumption). I have it in my hware, Im trying to recompile lastest kernel to use it(typing this in vesa). Not much trouble, gentoo anyway.



              The trouble is if this issues will be if all that options you talk (vid accel, 2d - is already here I know, improved opengl) will be handled in fglrx. Then it will be as in nvidia, but later and worser. I have switched to amd 4770 only because of their opensource effort, yes I appreciate it that much.

              Comment


              • #22
                Originally posted by BlackStar View Post
                Repeat after me: glxgears is not a benchmark. Don't try to use it as one, because its results are FUCKING INVALID.

                There, better now?

                In fact, fglrx performs identically to the Windows driver in OpenGL (sometimes slightly faster, too). The rest of your points are being addressed as we speak (better 2d acceleration, video acceleration).

                Bah.
                mmm i can be wrong but as far i have tested, the relation of fglrx and catalyst is more like this

                DX9/10/10.1/11 >>>>>> WGL4 which >>>>>>>>>>>>>>> fglrx

                download the unigine demos(i think those are complex enough to see the diff) for both oses and running with both codepaths, at least in my hardware the difference is very noticeable

                windows7x64
                kubuntu 10.04 rc
                4850x2 x2 aka quadfire
                quadcore cpu

                now on the nvidia side, opengl in linux is like 10% slower than directx in windows, wich is completly acceptable for me

                Comment


                • #23
                  Originally posted by crazycheese View Post
                  yes I appreciate it that much.[/U]
                  amen brother, the only reason i didnt instantly rma my quadfire is cuz i heard in time about AMD FOSS work, so yes I appreciate it that much too

                  Comment


                  • #24
                    Originally posted by jrch2k8 View Post
                    amen brother, the only reason i didnt instantly rma my quadfire is cuz i heard in time about AMD FOSS work, so yes I appreciate it that much too
                    intel E5300-->amd athlon II x4 630(instead of intel i3-540)
                    s775 asrock p43me--> amd-based am3 gigabyte GA-MA785GMT-UD2H, instead on intel s1150 board
                    nvidia 9800gt-->powercolor hd4770

                    All because amd supports foss and nvidia regresses totally.

                    Intel does not provide performance 3d hardware and overall it is pricy for same performance, so sorry, intel.

                    And I would really appreciate AMD create linux counter, where you can register your hardware as running linux. As main desktop and home os, not as workstation one.

                    Comment


                    • #25
                      jrch2k8, what kind of performance difference (linux vs windows, amd vs nvidia) do you see running with a single GPU rather than a 4-GPU crossfire rig ?

                      Comment


                      • #26
                        Originally posted by bridgman View Post
                        jrch2k8, what kind of performance difference (linux vs windows, amd vs nvidia) do you see running with a single GPU rather than a 4-GPU crossfire rig ?
                        mmm, is true quadfire tends to be really crappy even on windows (maybe game engine fault mostly), but i didnt test it with only 1 gpu that time and well rigth now im using xorg 1.8 and kernel 2.6.34 since i choosed to only use the OSS driver. i could test it again when my new disk come in a couple of months with a clean install(i really dont wanna spend some quality time downgrading my distro to get fglrx working again )

                        Comment


                        • #27
                          @bridgman:

                          I think the key interesting idea from this thread is to make some kind of open source thing that sits in between fglrx and kernel/xorg/whatever in order to improve the ability to follow the bleeding edge with fglrx.

                          Right now, fglrx breaks whenever the kernel or xorg is changed.
                          The kernel part is generally manageable since that interface is open source. The big problem is that fglrx breaks whenever the xserver changes.

                          But right now we have an open source X driver that *works*, and follows the xserver. So what these guys want is to be able to take the existing SOLID open source parts and mix in certain chunks (the acceleration chunks) of fglrx in order to come up with an overall driver package that doesn't break every time someone sneezes.

                          Which is not a bad idea. Even if it would probably be extremely expensive to implement.

                          (note: I'm not interested in this -- I personally am happy with the progress and function of the open source drivers.)

                          Comment


                          • #28
                            Originally posted by bridgman View Post
                            jrch2k8, what kind of performance difference (linux vs windows, amd vs nvidia) do you see running with a single GPU rather than a 4-GPU crossfire rig ?
                            Why bother bridgman ? I know you are trying to be nice here, but the guy has no clue what he's talking about .... he's comparing DX11 to OpenGL4 on cards that are capable of neither (hint ... HD4850x2).

                            Also I do not think his Quadfire setup has any benefits over a single HD4850x2 since the CPU will be most likely not able to feed the cards properly. Yet he's expeting the holy grail and more ...

                            Comment


                            • #29
                              Originally posted by BlackStar View Post
                              Repeat after me: glxgears is not a benchmark. Don't try to use it as one, because its results are FUCKING INVALID.
                              Heh... You forgot to mention they should repeat this over and over, using a blunt object applied to the back of their head whilst saying it until the desire to use glxgears as a benchmark leaves their minds, hopefully for good...

                              There, better now?
                              I certainly feel better now...

                              In fact, fglrx performs identically to the Windows driver in OpenGL (sometimes slightly faster, too). The rest of your points are being addressed as we speak (better 2d acceleration, video acceleration).

                              Bah.
                              I would hesitate to say this is going to be happening in a timely manner. They've been saying things along these lines for many years now, unfortunately- while only putting a few people when compared to the Windows side of things for years now. It's not being ugly or accusing when I state this- only making a statement of fact. They can't make a business case (yet...though, if what I've been told in confidence actually HAPPENS, that may deeply change for the better by the end of this or middle of next year...) to justify doing massive cleanups on the codebase where they've made incorrect assumptions on the WinSys layer of things to use a Gallium3D term for things so everyone can relate here (Which is actually where many of your bugs are coming from...). Because of this, there's been many, many years of promises without fufilling many of them except many years later.

                              It's a good part of where the bitching about fglrx stems from, actually. If you didn't know what was going on and why- you'd be peeved that they couldn't get "simple" things right like fglrx does screw up on- and we won't get into Crossfire, etc. which is their baby and should've been there already in stable form in the minds of the community at large.

                              Comment


                              • #30
                                Originally posted by droidhacker View Post
                                Right now, fglrx breaks whenever the kernel or xorg is changed.
                                The kernel part is generally manageable since that interface is open source. The big problem is that fglrx breaks whenever the xserver changes.
                                The big problem for them would be that it's more of a moving target than the way they're doing things right now. The main reason that the FOSS driver works as well as it does is that it's in lock-step with the Gallium3D API edge because it's part and parcel of that project. For them, it's a fairly extensive re-write for the parts that are breaking like you state- only to get to an edge that does the same thing on them with the same level of regularity right at the moment.

                                Comment

                                Working...
                                X