Renaming this bug.  Mesa supports gl_PointCoord and point size.

I ran fbo-gl_pointcoord with swrast and it _looks_ just like what the NVIDIA driver produces.  This might be a 1-pixel rasterization error or an FBO drawing/reading bug.

The problem is the piglit test is calling glPointSize(64) but swrast has a max point size of 60 (MAX_POINT_SIZE = 60 in config.h).

The piglit test needs to be fixed so that it checks the max supported point size and adjusts itself accordingly.

Is that something that you can do, Yuanhan?

(In reply to comment #2)
> The problem is the piglit test is calling glPointSize(64) but swrast has a max point size of 60 (MAX_POINT_SIZE = 60 in config.h).
> 
> The piglit test needs to be fixed so that it checks the max supported point size and adjusts itself accordingly.
> 
> Is that something that you can do, Yuanhan?

Hi Brian, 
 Thanks for your help. I will send the patch that adds the max point size check for it.

(In reply to comment #1)
> Renaming this bug.  Mesa supports gl_PointCoord and point size.
> 
> I ran fbo-gl_pointcoord with swrast and it _looks_ just like what the NVIDIA driver produces.  This might be a 1-pixel rasterization error or an FBO
> drawing/reading bug.

Last time I tried, rendering glpointcoord(a case I wrote instead of the piglit case) with software rast is ok(except the max point size issue as you stated), but failed while rendering to fbo. And I just confirmed that. So, It's a fbo relative issue.

(In reply to comment #4)
> (In reply to comment #1)
> > Renaming this bug.  Mesa supports gl_PointCoord and point size.
> > 
> > I ran fbo-gl_pointcoord with swrast and it _looks_ just like what the NVIDIA driver produces.  This might be a 1-pixel rasterization error or an FBO
> > drawing/reading bug.
> 
> Last time I tried, rendering glpointcoord(a case I wrote instead of the piglit
> case) with software rast is ok(except the max point size issue as you stated),
> but failed while rendering to fbo. And I just confirmed that. So, It's a fbo
> relative issue.

I took a little time to check this issue again. And figured out why the rendering is totally failed on my side(black screen): as I stated, I used another case instead of the piglit case written by Zhao Jian.  And that's the problem: I use glReadPixels then glDrawPixels to redirect the result to win sys framebuffer, but Zhao Jian use glBlitFramebuffer instead.

So, it sounds a bug relative to glReadPixels and glDrawPixels which just happened with swrast? (I'm busy at something else; I may look at this issue one day).

Anyway, I guess Zhao jian can help to mark this bug as _INVALID_.

Thanks,
Yuanhan Liu

Created attachment 57508 [details] [review]
The testcase I wrote to test pointcoord

1. Test it Using glDrawPixels

   $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
   
   Nothing rendered


2. Test it Using glBlitFramebuffer

   $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
   
   It _showhow_ works.

Thanks,
Yuanhan Liu

(In reply to comment #6)
> Created attachment 57508 [details] [review] [review]
> The testcase I wrote to test pointcoord
> 
> 1. Test it Using glDrawPixels
> 
>    $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
> 
>    Nothing rendered
> 
> 
> 2. Test it Using glBlitFramebuffer
> 
>    $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
> 
>    It _showhow_ works.
> 
> Thanks,
> Yuanhan Liu

Hi Brian and Yuanhan, 
 Thanks for you looking into this issue. I have updated the piglit test(fbo-gl_pointcoord), and it _seems_ work well that it passed on the auto test. But when test manually with LIBGL_ALWAYS_SOFTWARE set, I find it displayed inverted in Y direction while no error message output. So in software raster, it seems it is correct in framebuffer but failed when displayed to the output. It works well with HW accerlateion driver. Any suggestion? 

Thanks
zhaojian (In reply to comment #6)
> Created attachment 57508 [details] [review] [review]
> The testcase I wrote to test pointcoord
> 
> 1. Test it Using glDrawPixels
> 
>    $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
> 
>    Nothing rendered
> 
> 
> 2. Test it Using glBlitFramebuffer
> 
>    $ LIBGL_ALWAYS_SOFTWARE ./pointcoord --use-fbo
> 
>    It _showhow_ works.
> 
> Thanks,
> Yuanhan Liu

Hi Brian and Yuanhan, 
 Thanks for you looking into this issue. I have updated the piglit test(fbo-gl_pointcoord), and it _seems_ work well that it passed on the auto test. But when test manually with LIBGL_ALWAYS_SOFTWARE set, I find it displayed inverted in Y direction while no error message output. So in software raster, it seems it is correct in framebuffer but failed when displayed to the output. It works well with HW accerlateion driver. Any suggestion? 

Thanks
zhaojian

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/310.