On 10/09/18 11:01, Matt Turner wrote:
On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri <tarc...@itsqueeze.com> wrote:
On 10/09/18 09:52, Matt Turner wrote:
On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri <tarc...@itsqueeze.com> wrote:
On 10/09/18 09:22, Ian Romanick wrote:
On 09/08/2018 06:37 AM, Jason Ekstrand wrote:
Is there going to be an accompanying series on the piglit list? I don't
see anything there immediately.
Which is one of the major reasons we decided we'd never implement this
extension in Mesa. To test it to the quality levels that we expect, it
would literally take 1,000+ test cases.
As I said in the other thread refusing to implement this extension is
only going to hurt Mesa users and continue the "just use Nvidia if you
want things to work narrative". AMD have also indicated they would be
adding support for this extension in radeonsi. I'm willing to write
tests if they are not up to your quality levels the feel free not to
enable the extension in your driver.
There are so many things wrong with the last statement.
Can you be more specific?
The suggestion that if *common* *core* code isn't good enough we can
just not turn on the extension in our driver is offensively
shortsighted.
This is not at all what I was implying please see my other replies.
We're all working on a hugely important and successful free software
project. One area where it gets its strength is from people from
different companies, countries, interests, backgrounds, etc working
together. That common code saves huge amounts of work for others who
turn the feature on later. I benefit if you add a feature that I
wanted to enable, and vice versa.
But if a feature is implemented in a not so great way or without
sufficient tests, then it might not actually save future developers
time because they'll trip over the sharp edges left behind. Maybe
we'll decide it was actually a bad idea to implement it in the first
place. My point is that there's a (potentially great) cost involved
with supporting new functionality.
Intel really drove GL3+ feature development, and we were pretty
meticulous about getting the details right. Paul and Ken diff'd GL
specs to avoid another catastrophe like missing a one-character change
causing months of unplanned work (0 -> 4 samples required in GL 3.0).
We filed and got spec bugs fixed. People contributed GL CTS tests and
worked with others in Khronos. We probably could have cut some corners
and saved some time if our objective was simply to bump the GL version
number as fast as possible. But it wasn't -- it was to build the best
GL driver stack for i965 hardware and to do it in a way that would
enable others an easier bring up path. Again, because it's really
important to us that the work we do benefits the greater community.
I won't go into detail, but we would not still be working on Mesa
today if Mesa and the i965 driver was not very high quality.
My initial reaction to reading "feel free not to enable the extension
in your driver" is that that's not playing well with others.
Again see my last reply to Ian. This was meant in the same way as you
don't have to enable compat profile in your driver. Ian was quite
aggressive in his disapproval in his very first reply. As I said below
after reading this my initial reaction was that no testing was going to
be good enough for him to want to enable the extension for i965 to which
he has pretty much agreed. I was never implying that I wouldn't write
quality tests or code, I would have thought my actions over the past 6
years would have spoken to this and to all the points you raised above.
I think it's evident that we can find a way forward based on past
experiences (compatibility profile is supported in Mesa!).
I don't really know what you are trying to say here. I continued what
Marek's started while implemented a bunch of compat tests, just like
every other feature we add. You guys just decided not to follow I'm I
missing something?
There's a legitimate debate to have here, but not like this.
Ian made it pretty clear he didn't want a debate and had already made up
his mind.
"We decided years ago that we were not going to support this horrible,
underspecified steaming pile of an extension in Mesa. I am not
interested in going back on that decision now or, frankly, ever."
All I'm saying is I'm willing to write tests but I get the feeling
nothing will be good enough when I'm greeted with statements like the
one above.
I agree, but at the same time I'm not sure that you're accurately
estimating the amount of work an appropriate test suite is.
I mean, it's a really bad extension. I have a feeling that you might
start agreeing with Ian when you take a closer look :)
Yes its a very big extension and I'm not intending to implement the
entire extension at this point. The pieces I've implemented (besides the
matrix stuff which I would also write tests for since its their) pretty
much replicate the ARB extension except for if no object exists create
it, if 0 buffer use default etc, so testing should be straight forward
for this and a bunch of other feature in the extension.
And here's the thing, you sent patches to add this extension without
piglit tests. Were you hoping to commit this series without tests?
Without comments from Ian and Jason I fear that you would have gladly
pushed this.
I sent the series to gauge interest / gather feedback before wasting any
further time on something that might not be accepted as a partial
implementation. Since it was decided not to implement this extension in
the past I gathered there might be some pushback. If we agree to move
forward I intended to add all the other functions which basically just
need entry points to the same common code updated by this series as well
are the require piglit tests.
If we cannot implement the extension in stages I'm unlikely to be able
to commit to a full implementation in one go at this time.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
