Radeon support?

[staalmannen]

Hi I saw that you have drivers for intel and noveau. At least the noveau version is apparently partially based on xf86-video-noveau. Any plans on implementing a similar driver from xf86-video-ati ?

I just started playing with Velox but have to run on the "dumb" driver.

[michaelforney]

Unfortunately, I don't have any radeon hardware, so probably not in the near future.

I do plan on implementing an OpenGL backend. Hopefully I'll find some time for that soon.

[staalmannen]

Ok thanks. How involved are the changes to the noveau xf86 driver and could
I use this as a "template" if I wanted to attempt an xf86-video-ati port? I
have limited time and experiece, but if only minor changes are needed - I
might be able to try it.
Den 21 mar 2015 20:07 skrev "Michael Forney" notifications@github.com:

Unfortunately, I don't have any radeon hardware, so probably not in the
near future.

I do plan on implementing an OpenGL backend. Hopefully I'll find some time
for that soon.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[michaelforney]

It wasn't so much changes as figuring out the things necessary to implement the three rendering primitives, fill box, copy box, and render text from immediate. You can look at how the xf86-video-ati driver implements the corresponding X acceleration primitive.

You can start with with basic buffer management stuff using the libdrm_radeon API, and try to get an application running that fills a box. That's the tough part (and also very exciting to get working). Once you've done that, it is pretty smooth sailing. Basically, the idea is, you have some command buffer, and you need to figure out the bytes to put in there to do the rendering operation you want. Then, when you fill up the buffer, or in the renderer's flush function, you submit it to the GPU.

I was able to get the nouveau implementation working in just a few days. But this is pretty tricky stuff, and hard to debug.

[staalmannen]

Ok thanks! It might be over my ability but I will at least look at it :).
Out of curiosity - will the opengl driver be as performant / feature
complete as the dedicated drivers? If that is the case - will it replace
all others (bar the "dumb" fallback)?

If this is the case, I will not attempt a radeon port (but could test the
opengl on radeon).
Den 22 mar 2015 06:56 skrev "Michael Forney" notifications@github.com:

It wasn't so much changes as figuring out the things necessary to
implement the three rendering primitives, fill box, copy box, and render
text from immediate. You can look at how the xf86-video-ati driver
implements the corresponding X acceleration primitive.

You can start with with basic buffer management stuff using the
libdrm_radeon API, and try to get an application running that fills a box.
That's the tough part (and also very exciting to get working). Once you've
done that, it is pretty smooth sailing. Basically, the idea is, you have
some command buffer, and you need to figure out the bytes to put in there
to do the rendering operation you want. Then, when you fill up the buffer,
or in the renderer's flush function, you submit it to the GPU.

I was able to get the nouveau implementation working in just a few days.
But this is pretty tricky stuff, and hard to debug.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[michaelforney]

I haven't decided that yet. I've realized that I don't have the time and resources (and knowledge of GPU architectures) to maintain these wld drivers (even if they are just a few hundred lines). The two features I still want in wld are alpha-blending and anti-aliased font rendering (kinda hand-in-hand). It is probably not to hard do this for nouveau (from what I could tell), but for intel it would involve the 3D pipeline and reading the xf86-video-intel driver is pretty intimidating because it has lots of logic about when to use the 3D pipeline and when to use the BLT engine. In newer intel chips, the BLT rendering operations are done in a separate command ring, and from what I gather, switching back and forth isn't good for performance.

The OpenGL driver will provide the same features as the other dedicated drivers. In regard to performance, I imagine there won't be any noticeable difference. Mesa provides a much more complicated driver infrastructure, so the driver overhead is probably quite a bit larger, but the developers are also much more knowledgeable about this stuff and are probably able to make smarter decisions about how things should be implemented.

On the other hand, I'd really hate to lose out on how self-contained wld is, and the simplicity of its drivers. It is pretty cool to me to be able to create a smallish statically-linked binary containing my whole display server complete with hardware acceleration.

So, at least for a while, I expect to keep both options available. OpenGL would support a much larger set of hardware and would likely be more reliable. This would be a good choice for those with less of a concern for large dependencies and driver complexity.

I'm also curious about the upcoming Vulkan API from Khronos, and the intel driver implementation. It should be a bit lower-level than OpenGL, which would make it easier to reason about what the driver is doing under the hood.

[staalmannen]

A self-contained static binary is indeed very cool!

I will look at it and in the likely event that it is beyond my ability, I
will try to find someone with the will and the skill :)
Den 22 mar 2015 07:38 skrev "Michael Forney" notifications@github.com:

I haven't decided that yet. I've realized that I don't have the time and
resources (and knowledge of GPU architectures) to maintain these wld
drivers (even if they are just a few hundred lines). The two features I
still want in wld are alpha-blending and anti-aliased font rendering (kinda
hand-in-hand). It is probably not to hard do this for nouveau (from what I
could tell), but for intel it would involve the 3D pipeline and reading the
xf86-video-intel driver is pretty intimidating because it has lots of logic
about when to use the 3D pipeline and when to use the BLT engine. In newer
intel chips, the BLT rendering operations are done in a separate command
ring, and from what I gather, switching back and forth isn't good for
performance.

The OpenGL driver will provide the same features as the other dedicated
drivers. In regard to performance, I imagine there won't be any noticeable
difference. Mesa provides a much more complicated driver infrastructure, so
the driver overhead is probably quite a bit larger, but the developers are
also much more knowledgeable about this stuff and are probably able to make
smarter decisions about how things should be implemented.

On the other hand, I'd really hate to lose out on how self-contained wld
is, and the simplicity of its drivers. It is pretty cool to me to be able
to create a smallish statically-linked binary containing my whole display
server complete with hardware acceleration.

So, at least for a while, I expect to keep both options available. OpenGL
would support a much larger set of hardware and would likely be more
reliable. This would be a good choice for those with less of a concern for
large dependencies and driver complexity.

I'm also curious about the upcoming Vulkan API from Khronos, and the intel
driver implementation. It should be a bit lower-level than OpenGL, which
would make it easier to reason about what the driver is doing under the
hood.

—
Reply to this email directly or view it on GitHub
#3 (comment).