Announcement

Collapse
No announcement yet.

Beers & Interviews With X.Org Developers?

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

  • Beers & Interviews With X.Org Developers?

    Phoronix: Beers & Interviews With X.Org Developers?

    With the X Developers' Summit this week happening in Toulouse there are around 50 developers responsible for a majority of the work that goes on within the open-source Linux graphics scene from the open ATI and Intel drivers to the Wayland Display Server and planning of Mesa and DRI2, among many other topics. I'm sure many of you have questions for them (see the attendance list) whether it's about the future of their given project or views on a particular matter. If you do, ask them in this forum thread from the comments link below...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Video interviews are a great idea!

    Comment


    • #3
      All the new features going into X mobility and into the kernel is great. But what I really want is just plain old rock solid 2D graphics for everyday use in a office like environment. Perhaps the fault is with today's window managers (I use KDE), as they are just doing to many fancy things. While their intentions are good I just find myself frustrated getting decent 2D desktop performance in every day things like dragging windows and fast mouse response. Windows 7 on the same computer makes my Linux desktop look very slow in almost every aspect.

      So this is more of a comment as a user then a request for a question. And that comment is - above all make X rock solid and snappy for the everyday desktop.

      Thanks

      Comment


      • #4
        My question would be to Jerome Glisse - afaik he started a new shader compiler for r600g, but it got ripped out to not hinder the other developers in other areas of r600g. Now I'd be interested to hear if the new compiler is still actively developed, what's its status and when we could roughly expect it to be in a usable state ? Additionally it'd be nice to know if it would have more features than the current r600c compiler and how the compiled shaders would perform (read: performance improvements ?).

        Another thing I'd be interested in is how the s3tc case progresses, but I'm not sure if it's the right place to ask. Afaik there were some efforts to get clearance to use those patents in mesa, but I didn't read something about it in a long time. So a little light on the progress in that area would be welcome.

        Third is the OpenGL 3 State Tracker of course: what's its state ?

        Cheers and don't try to take away those pretty glasses on Oktoberfest :-)
        Luzipher

        Comment


        • #5
          I'm not exactly sure how to phrase it as a question, but I think it would be interesting to discuss how to attract more developers. Specifically to the Google SoC and X.org EVoC programmes.

          Comment


          • #6
            yeah, videos!

            did we ever get videos that one time when everyone was complaining about michael not using free formats?

            anyway, free format is preferred, but as long as we get some videos i'm happy

            Comment


            • #7
              For Intel devs: what level of support can we expect regarding 2d, 3d, power saving, video accel. for Sandy Bridge ?
              For AMD devs: same question regarding Bobcat (Ontario and Zacate), Llano and Bulldozer.

              Comment


              • #8
                Originally posted by karl View Post
                For Intel devs: what level of support can we expect regarding 2d, 3d, power saving, video accel. for Sandy Bridge ?
                For AMD devs: same question regarding Bobcat (Ontario and Zacate), Llano and Bulldozer.
                Sandybridge stuff is already available from git.

                Comment


                • #9
                  AMD paid devs:
                  It seems to me that AMD's (well, Mr Bridgeman's) strategy is to bring up a driver for the latest gpu family which *works* and let the community guys continue hacking it. I think it "usually" takes about 6-9 months to bring up a new driver. New generations are introduced approximately every 14 months.
                  Here comes my question: will Alex and Richard work on other stuff in the meantime? I mean something like how Intel folks wrote the shiny new glsl compiler.
                  Do you plan to add HD6xxx/r900 support into r600g or write an entirely new driver?
                  Is it not possible to have a closed libxvba library which could be loaded by the oss driver to provide hardware acceleration for video playback?
                  What about the hdmi audio code which Alex wrote? I think it has not yet been published and we still use what Rafal Milecki wrote? (If my memory server well.)

                  All AMD:
                  Are you planning to add new functionality to the drivers like HiZ, tiling and msaa? Is there anything that has not yet been added to r300g?
                  How far do you plan to go with optimizations? This concerns mainly r300g for obvious reasons. Marek wrote once that he is a bit out of ideas. He also mentioned that mesa code takes more than 50% of gpu time so those paths should be dropped/optimized. Are there any plans for this and if yes what are the foreseeable obstacles?
                  More generally: do you have a plan to identify and eliminate the bottlenecks?
                  What about xrandr 1.3 and 1.4 support?

                  Everybody:
                  Will somebody start working on the long-awaited
                  -OpenGL 3
                  -OpenCL (in this case continue)
                  -video decoding
                  Gallium state-trackers? We all long for OGL 3, that's obvious. But we also wish for hardware acceleration for video decoding. Here may very well be a possibility to reduce the necessary work since it has been said a couple of times that ffmpeg & co guys want to write opencl code to do this. Consequently, it might be better not to have a separate state tracker for just video stuff but have a good opencl one. What do you think? What would be the (dis)advantages of the two approaches?


                  Don't forget to say thanks for their hard work for me!

                  Michael:
                  Thank you for the coverage and also for this excellent idea!

                  Comment


                  • #10
                    Interested In Interviews?
                    No, I'm more interested in beers and I think X.org devs should have more of them.

                    Comment

                    Working...
                    X