[Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Timothy Arceri]

On 10/09/18 11:01, Matt Turner wrote:
> On Sun, Sep 9, 2018 at 5:00 PM Timothy Arceri <tarceri at itsqueeze.com> wrote:
>> On 10/09/18 09:52, Matt Turner wrote:
>>> On Sun, Sep 9, 2018 at 4:41 PM Timothy Arceri <tarceri at 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.