Beers & Interviews With X.Org Developers?

[whizse]

Everybody:
Will somebody start working on the long-awaited
-OpenGL 3

There's plenty of work being done on GL3...

[Veerappan]

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?

Well, my uneducated heathen opinion is that the OpenCL state tracker with CL code to accelerate video is the way to go. Partially, it's because I'm hoping to write a thesis project which creates an OpenCL VP8 decoder based on the current public VP8 decoder from WebM Project. The other reason I think it's a good idea is that it would be a very portable solution. The video decoders could be written once in any OS and hopefully with minimal effort could be run on Linux/BSD/OpenSolaris/Mac/Windows. This last bit might help to attract more developers on the video decoder projects, which is good for everyone.

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

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

Agreed. Thank you Michael, and please convey that thanks to the people you meet at the summit as well. I am glad to be able to contribute beer money as a token of thanks

Questions for the developers:
1) How long, if ever, do you think it will be until we can transition the entire set of drivers to KMS and remove the UMS paths. Is this desirable?

2) Long term, is it likely that new graphics architectures will be coded for Gallium and not even have a classic Mesa driver created?

3) What is the status of the Xorg State Tracker, and will we see a point where no chip-specific X.org drivers will need to be created anymore once a Gallium driver exists for a chip?

4) Even if the X.org State Tracker is usable for a given chip, are there still reasons to create a chip-specific X.org driver (Features/Performance/etc)?

5) How stable is the Gallium API at this point?

6) I know that it has been stated multiple times that at that point writing documentation for prospective new developers was pointless because it would be obsolete soon. Any estimates how long until this isn't the case (if ever)?

[karl]

Sandybridge stuff is already available from git.

Maybe my question was not clear enough. I'm not interested in some "stuff". I'm interested in precise functionality like:
- 2d: will current generation of desktop (gnome/kde and apps) "just work"?
- 3d: will I be able to play games (including ones using wine, let's say SC2) w/o any issues?
- power saving: will the power used by the gfx be in line with power usage from a windows system?
- video accel: will something like vlc be able to use the gfx (or in case of SB the specialized decode block) to accel. video decode? what about video encode, will something like handbrake be able to use the h/w block from SB to accel. video encode?

[whizse]

Maybe my question was not clear enough. I'm not interested in some "stuff". I'm interested in precise functionality like:
- 2d: will current generation of desktop (gnome/kde and apps) "just work"?
- 3d: will I be able to play games (including ones using wine, let's say SC2) w/o any issues?
- power saving: will the power used by the gfx be in line with power usage from a windows system?
- video accel: will something like vlc be able to use the gfx (or in case of SB the specialized decode block) to accel. video decode? what about video encode, will something like handbrake be able to use the h/w block from SB to accel. video encode?

Video _encoding_ would be interesting to get an opinion on, as for the rest of the stuff, this is more or less (with the exception of bugs and regressions) already the case with current Intel stuff, so I doubt anything will change.

[HokTar]

There's plenty of work being done on GL3...

Well, I'm not so sure about plenty. Not to mention that all of the things you are referring to is in mesa not gallium. A separate gallium state tracker would help a lot because you don't need to go through all the mesa paths - as far as I understand...

Well, my uneducated heathen opinion is that the OpenCL state tracker with CL code to accelerate video is the way to go. Partially, it's because I'm hoping to write a thesis project which creates an OpenCL VP8 decoder based on the current public VP8 decoder from WebM Project. The other reason I think it's a good idea is that it would be a very portable solution. The video decoders could be written once in any OS and hopefully with minimal effort could be run on Linux/BSD/OpenSolaris/Mac/Windows. This last bit might help to attract more developers on the video decoder projects, which is good for everyone.

As for vp8:
-- I would rather use the ffmpeg implementation because it said to be much faster
-- nextgen video cards will have vp8 decoding implemented in hardware and since it does not have any drm it can be used by foss drivers (hopefully) - which is nice btw
-- it will still not resolve our current problem with h264 files...
-- When will you start working on this project? Good luck!

[whizse]

Well, I'm not so sure about plenty. Not to mention that all of the things you are referring to is in mesa not gallium. A separate gallium state tracker would help a lot because you don't need to go through all the mesa paths - as far as I understand...

Considering how much is marked as DONE in GL3.txt + the branch Luca announced containing float textures and render targets + the initial (and promised) work on 1.30 in glsl2 I would consider OpenGL3 support well under way.

Having a separate state tracker seems more like one of those things that would be nice to have, but far from a necessity, but I might be wrong.

[marek]

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.

There is always work to do in the compiler.

He also mentioned that mesa code takes more than 50% of gpu time so those paths should be dropped/optimized.

I meant CPU time, not GPU time. Both the CPU and the GPU should ideally run in parallel, and the slower one determines performance, because they must wait for each other every frame. For example, the Quake 3 engine performance is mostly CPU-limited.

[Veerappan]

As for vp8:
-- I would rather use the ffmpeg implementation because it said to be much faster
-- nextgen video cards will have vp8 decoding implemented in hardware and since it does not have any drm it can be used by foss drivers (hopefully) - which is nice btw
-- it will still not resolve our current problem with h264 files...
-- When will you start working on this project? Good luck!

I'm aware of the ffmpeg implementation, and I may borrow some of their ideas, but at the moment I'm just planning to use the pure-C source for the VP8 decoder, and I'm hoping to find a way to get the OpenCL implementation to keep itself. I haven't really looked at the ffmpeg source yet, but I had figured that they were working on optimizing the assembly bits and not the C. I very well may be wrong, and might have to check into if it's allowed to copy back the ffmpeg changes into the VP8 repo due to possible license issues.

If it turns out that future video cards have VP8 decoding in the drivers that would be great. For now, I am assuming that Nvidia and ATI will continue as they have been with regards to OSS drivers (no documentation for the video decode bits to protect the DRM parts). I have a feeling that if Flash starts to support VP8, they might wrap the VP8 video in an encryption layer to appease the likes of Hulu/Netflix/etc.

And yes, it will not resolve the h.264 issues, but it might help someone figure out how to do the same for H.264. And at this point, I'd rather avoid the possible patent issues I might run into by doing an H.264 decoder, and concentrate on the VP8 solution instead which at least has a possibility of being royalty-free.

As to the start date, it starts as soon as I find an advisor for the project. I've completed my proposal and am working on finding someone to supervise the project. While I'm waiting, I'm working on setting up some of the infrastructure and fleshing out the rest of my design.

[HokTar]

I wish the best for you and of course for your project!

I also hope that this will give a boost for the gallium opencl state tracker's development as well. With this piece of code regular people could use the latter for something useful, too.

[Veerappan]

I wish the best for you and of course for your project!

I also hope that this will give a boost for the gallium opencl state tracker's development as well. With this piece of code regular people could use the latter for something useful, too.

Thanks, and I agree. With this code, acceleration for VP8 would immediately be available for Mac OS, Windows (AMD/Nv and CPU via AMD Stream), and Linux/BSD/etc would work as well when the right run-time library was present. Of course, this is entirely dependent upon my actually finishing the project ;-)