On 05/30/2017 08:27 PM, Kenneth Graunke wrote:
> On Tuesday, May 30, 2017 5:40:26 PM PDT Ian Romanick wrote:
>> From: Ian Romanick <ian.d.roman...@intel.com>
>>
>> EXT_point_parameters is required, but it is not supported by radeon.
>>
>> Fixes piglit's egl-create-context-verify-gl-flavor test.
>>
>> Signed-off-by: Ian Romanick <ian.d.roman...@intel.com>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>> src/mesa/drivers/dri/radeon/radeon_screen.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/radeon/radeon_screen.c
>> b/src/mesa/drivers/dri/radeon/radeon_screen.c
>> index 79e3889..aeb2d02 100644
>> --- a/src/mesa/drivers/dri/radeon/radeon_screen.c
>> +++ b/src/mesa/drivers/dri/radeon/radeon_screen.c
>> @@ -782,7 +782,11 @@ __DRIconfig **radeonInitScreen2(__DRIscreen *psp)
>> __DRIconfig **configs = NULL;
>>
>> psp->max_gl_compat_version = 13;
>> +#if defined(RADEON_R200)
>> psp->max_gl_es1_version = 11;
>> +#else
>> + psp->max_gl_es1_version = 10;
>> +#endif
>>
>> if (!radeonInitDriver(psp)) {
>> return NULL;
>>
>
> Is there some reason it can't have a stupid no-op implementation of
> EXT_point_parameters? The driver sets min/max point size to 1.0,
> which appears to be allowed by ES 1.1 AFAICT...which means any fading
> or attenuation between those values would be...1.0.
>
> Or am I missing something?That is probably doable. I hadn't thought about it, really. I can try that and... shudder... see what GLES1 conformance says. I haven't even run that yet. R100 can implement EXT_point_parameters, and it looks pretty straightforward. For now, I just wanted to make things stop failing. > As for the rest, patches 2-5 are: > Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
