On 04/19/2012 11:05 PM, Lucas Stach wrote:
Am Freitag, den 20.04.2012, 07:02 +0200 schrieb Thierry Reding:
*cut*
Yes, I think we should go the route that Jerome Glisse pointed out: get
in a basic KMS driver first and hide any accel ioctl under a staging
config option.
Everyone seems happy with that, I have no objections.
*cut*
I'm really interested how this turns out in the end. I hope we can get a
somewhat stable cooperation between NVIDIA and the community, like AMD
has established at the moment.
Well, we always strive to be better than AMD ;-)
But seriously, I don't think GPU technology would be where it is today
if NVIDIA and AMD didn't compete aggressively.
But our mobile division is more like TI, Qualcomm, Freescale and other
SoC vendors. Upstreaming changes for arch/arm has so far been a
different challenge than only updating drivers/gpu for x86. Mostly
because there are so many aspects to SoCs compared to a driver for a
graphics card or PC chipset. And it doesn't help that arch/arm is a real
mess of wildly different SoCs, and it lacks the stability and maturity
of the x86 code base. The state of ARM is every vendor's fault, every
chip generation can be a complete resign of one or more subsystems. x86
tends to be layers of extensions and enhancements from 1-3 vendors.
But even if Mobile doesn't consider AMD or Intel to be among the
competition, we certainly watch and listen to good open source
contributors and try to learn from their successes and mistakes. (and
our own mistakes, we're not perfect!)
What I'm trying to say is that Tegra's business needs are different, so
you should not be surprised to see different behavior from us. There are
a lot of difficult issues with open sourcing the work done by my desktop
colleagues. But those barriers don't apply to Tegra. Different product,
different market, different rules.
(My vote is NVIDIA starts using this DRM in-house and builds new
extensions on top of it, sharing patches on LKML when the hardware is
released)
That sounds like a good plan. Ideally you should even share the patches as
soon as they're ready. That'll give viewers some head start and you can fix
the code even before the hardware is released.
One thing I would like to have is upstream first. We have seen much
Tegra development in both the nv-linux and chromium trees, but those
things are going upstream extremely slowly. I can understand that this
strategy was beneficial for a fast bring up of the new Tegra hardware,
but the DRM driver shouldn't be time critical and so everything should
be done to meet upstream quality from the start.
-- Lucas
We have a team of interested engineers assigned to just that problem.
Fractured trees are not efficient for us internally either. We want
upstream to be our common repository for most changes. And internally we
have been stricter about conforming to Linux kernel coding conventions
in attempt to give ourselves less work when we get to upstreaming a
change. I'll be happy when I can tell my customers they can just grab
the latest Tegra updates from git.kernel.org
Hopefully our efforts will begin to convince you.
- Jon
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
