Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
>> I reviewed the softpipe code and I think I found a bug in it vs the original >> paper. >> I've created an MR >>https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11917 >>with my proposed fix. >>I'd really appreciate it if you could take a look. Hi Dave, It seems that the current softpipe code is different to the original implementation: https://gitlab.freedesktop.org/mesa/mesa/-/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162 The line was changed in the following commit which changed a lot of the code and readings from the description I think the change in the behavior was not intended: https://gitlab.freedesktop.org/mesa/mesa/-/commit/2135aba8d99d5b0b5f73d97d4aac6a25d69de57c You MR is correct; it restores the original behavior. Please also move the comment for that line to the new/original position. Regards, Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
> The texture has been taken from the wikipedia page > https://en.wikipedia.org/wiki/Anisotropic_filtering#/media/File:Anisotropic_filtering_en.png > > The following images show results for both settings: > > image with anisotropic filtering (16) > https://pasteboard.co/JNyFRkr.png > > image without anisotropic filtering > https://pasteboard.co/JNyFlWb.png > > Andreas Hey Andreas, I've been away from this topic for a while, but I finally got back to it, and I'm trying to pass the Vulkan/GL cts tests. I reviewed the softpipe code and I think I found a bug in it vs the original paper. I've created an MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11917 with my proposed fix. I'd really appreciate it if you could take a look. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
> I've fixed all the issues in that area, and I believe llvmpipe and
> softpipe mostly produce the same or very similiar results.
>
> I'm not overly impressed though by the texture quality at least the
> furmark trace shows as very blurry.
>
> Also the Vulkan CTS expects linear aniso to operate differently to how
> this has done it.
>
> Andreas, can you comment on this trace?
>
https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/
>
> I'm pretty sure softpipe looks the same locally for the same trace,
> and it just seems overly blurry.
1) Is it blurry in all cases you have tried or are there test cases
where it is better?
I've only noticed it with furmark, but I don't have a lot of test
cases, the GL CTS passes, the Vulkan CTS does look blurry and fails
but it's unlikely that is due to the blur.
2) Are the results better compared to linear?
I'm not sure, better is pretty subjective measure here,
3) Is the reference image produced with another anisotropy
implementation or with linear?
The reference image is produced with whatever llvmpipe path was taken
before this, which I assume is linear.
If 2) is not what you expect, then maybe the softpipe version is not
correct (anymore).
In general, I remember that results are a bit more blurry (compared to
linear) in the non-anisotropy case, ie. when textures are displayed
undistorted at 100%. But this doesn't seem to be the case in the trace
image here.
I'd be interested in any test data you have or any output, afaics the
llvmpipe output pretty much matches the softpipe output and if the
softpipe output is currently acceptable then we should merge the MR to
equalise them, and then fix any subsequent things on top in parallel.
I'd like to solve the VK CTS issue which does a linear vs anisotropic
compare and expects only a moderate amount of difference and we seem
to exceed the difference threshold.
I've created and attached a simple test case. Note that this is a java
application using the fixed function pipeline and is based on bindings
to osmesa/classic swrast, as we are not using softpipe at all. But it is
very simple and should not require much work to adapt it to another
language/environment (hopefully).
Just change maxAnisotropy to either 16 or 1 to switch between using
anisotropic filtering or not.
The texture has been taken from the wikipedia page
https://en.wikipedia.org/wiki/Anisotropic_filtering#/media/File:Anisotropic_filtering_en.png
The following images show results for both settings:
image with anisotropic filtering (16)
https://pasteboard.co/JNyFRkr.png
image without anisotropic filtering
https://pasteboard.co/JNyFlWb.png
Andreaspackage test;
import java.awt.image.BufferedImage;
import java.awt.image.DataBufferByte;
import java.io.File;
import java.io.IOException;
import java.nio.Buffer;
import java.nio.ByteBuffer;
import java.util.HashMap;
import java.util.Iterator;
import javax.imageio.ImageIO;
import javax.media.opengl.GL;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.glu.GLU;
public class AnisotropyTest implements GLEventListener
{
public static int IMAGE_WIDTH=1280;
public static int IMAGE_HEIGHT=960;
HashMap textures=new HashMap();
TextureLoader loader=new TextureLoader();
/**
* Set to 0 or 1 to turn off anisotropic filtering.
* Set to 16 for highest anisotropic filtering quality.
*/
protected float maxAnisotropy=16;
public AnisotropyTest()
{
}
protected void bindTexture(GL gl, String textureName)
{
Object o=textures.get(textureName);
if(o==null)
{
BufferedImage bi=loader.loadTexture(textureName);
if(bi==null) return;
DirectBufferedImage image=(DirectBufferedImage)bi;
int format;
switch(image.getDirectType())
{
case DirectBufferedImage.DIRECT_RGB: format=GL.GL_RGB;
break;
case DirectBufferedImage.DIRECT_RGBA: format=GL.GL_RGBA;
break;
default:
throw new RuntimeException(
"bindTexture: unknown coloring type
"+image.getDirectType());
}
int texName[]=new int[1];
makeTexture(gl, bi, format, texName);
textures.put(textureName, texName[0]);
}
else
{
int texture=((Integer)o).intValue();
gl.glBindTexture(GL.GL_TEXTURE_2D, texture);
}
}
private void makeTexture(GL gl, BufferedImage image, int format, int
texName[])
{
gl.glGenTextures (1, texName, 0);
gl.glBindTexture (GL.GL_TEXTURE_2D, texName[0]);
gl.glTexParameterf(GL.GL_TEXTURE_2D,
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Mon, 8 Feb 2021 at 19:04, Andreas Fänger wrote: > > > Am 08.02.2021 05:14, schrieb Dave Airlie: > > On Wed, 3 Feb 2021 at 02:58, Michel Dänzer wrote: > >> > >> On 2021-02-02 5:55 p.m., Michel Dänzer wrote: > >> > On 2021-02-02 6:44 a.m., Dave Airlie wrote: > >> >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: > >> >>> > >> >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger > >> >>> wrote: > >> > >> >> don’t know why the current softpipe/swrast implementation > >> >> shouldn’t be conformant. > >> > >> > Interesting I hadn't known we had a correct impl in mesa, the > >> > features.txt has said "softpipe and llvmpipe advertise 16x > >> > anisotropy but simply ignore the setting" > >> > so I never dug any deeper. I'll consider a port of this to llvmpipe > >> > at some point, making it efficient might be tricky. > >> > >> It seems that features.txt hasn't been updated regarding this > >> functionality; softpipe has "real" anisotropy since 2011. > >> > >> > I'll consider a port of this to llvmpipe at some point, making it > >> > efficient might be tricky. > >> That would be great. As anisotropic filtering is often an option > >> which can be set by a user, I guess most people turn it off to get > >> higher framerates. But in our use case, high quality renderings are > >> required, so we accept the longer render times to get the best > >> quality; hopefully a llvmpipe port would be faster than the old > >> swrast implementation (we are only using the fixed rendering > >> pipeline/no shaders in conjunction with the OpenMP patch for > >> speeding up GL_POLYGON_SMOOTH_HINT) > >> > >> Andreas > >> >>> > >> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 > >> >>> > >> >>> Is my first pass at writing the code for this I've no idea if this is > >> >>> anyway correct, but I'm just letting everyone know I've started > >> >>> working on it, and mipmap_tunnel doesn't look immediately wrong. > >> >> > >> >> Olay the code in the MR above seems to work in most cases now and > >> >> seems to operate like softpipe. > >> >> > >> >> However I'm seeing a trace failure > >> >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ > >> >> > >> > > >> > The floor at the bottom left of the Actual image definitely looks odd, > >> > there's a hard line between the rock patterns. > >> > >> Not to mention the wall tiles having different sizes, with a hard line > >> as well. > >> > >> Definitely looks like a bug to me, which wouldn't be noticeable with > >> special test textures made up of different solid colours per mip > >> level. > > > > I've fixed all the issues in that area, and I believe llvmpipe and > > softpipe mostly produce the same or very similiar results. > > > > I'm not overly impressed though by the texture quality at least the > > furmark trace shows as very blurry. > > > > Also the Vulkan CTS expects linear aniso to operate differently to how > > this has done it. > > > > Andreas, can you comment on this trace? > > https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/ > > > > I'm pretty sure softpipe looks the same locally for the same trace, > > and it just seems overly blurry. > > 1) Is it blurry in all cases you have tried or are there test cases > where it is better? I've only noticed it with furmark, but I don't have a lot of test cases, the GL CTS passes, the Vulkan CTS does look blurry and fails but it's unlikely that is due to the blur. > 2) Are the results better compared to linear? I'm not sure, better is pretty subjective measure here, > 3) Is the reference image produced with another anisotropy > implementation or with linear? The reference image is produced with whatever llvmpipe path was taken before this, which I assume is linear. > > If 2) is not what you expect, then maybe the softpipe version is not > correct (anymore). > > In general, I remember that results are a bit more blurry (compared to > linear) in the non-anisotropy case, ie. when textures are displayed > undistorted at 100%. But this doesn't seem to be the case in the trace > image here. I'd be interested in any test data you have or any output, afaics the llvmpipe output pretty much matches the softpipe output and if the softpipe output is currently acceptable then we should merge the MR to equalise them, and then fix any subsequent things on top in parallel. I'd like to solve the VK CTS issue which does a linear vs anisotropic compare and expects only a moderate amount of difference and we seem to exceed the difference threshold. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Am 08.02.2021 05:14, schrieb Dave Airlie: On Wed, 3 Feb 2021 at 02:58, Michel Dänzer wrote: On 2021-02-02 5:55 p.m., Michel Dänzer wrote: > On 2021-02-02 6:44 a.m., Dave Airlie wrote: >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: >>> >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger >>> wrote: >> don’t know why the current softpipe/swrast implementation >> shouldn’t be conformant. > Interesting I hadn't known we had a correct impl in mesa, the > features.txt has said "softpipe and llvmpipe advertise 16x > anisotropy but simply ignore the setting" > so I never dug any deeper. I'll consider a port of this to llvmpipe > at some point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. > I'll consider a port of this to llvmpipe at some point, making it > efficient might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas >>> >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 >>> >>> Is my first pass at writing the code for this I've no idea if this is >>> anyway correct, but I'm just letting everyone know I've started >>> working on it, and mipmap_tunnel doesn't look immediately wrong. >> >> Olay the code in the MR above seems to work in most cases now and >> seems to operate like softpipe. >> >> However I'm seeing a trace failure >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ >> > > The floor at the bottom left of the Actual image definitely looks odd, > there's a hard line between the rock patterns. Not to mention the wall tiles having different sizes, with a hard line as well. Definitely looks like a bug to me, which wouldn't be noticeable with special test textures made up of different solid colours per mip level. I've fixed all the issues in that area, and I believe llvmpipe and softpipe mostly produce the same or very similiar results. I'm not overly impressed though by the texture quality at least the furmark trace shows as very blurry. Also the Vulkan CTS expects linear aniso to operate differently to how this has done it. Andreas, can you comment on this trace? https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/ I'm pretty sure softpipe looks the same locally for the same trace, and it just seems overly blurry. 1) Is it blurry in all cases you have tried or are there test cases where it is better? 2) Are the results better compared to linear? 3) Is the reference image produced with another anisotropy implementation or with linear? If 2) is not what you expect, then maybe the softpipe version is not correct (anymore). In general, I remember that results are a bit more blurry (compared to linear) in the non-anisotropy case, ie. when textures are displayed undistorted at 100%. But this doesn't seem to be the case in the trace image here. Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Wed, 3 Feb 2021 at 02:58, Michel Dänzer wrote: > > On 2021-02-02 5:55 p.m., Michel Dänzer wrote: > > On 2021-02-02 6:44 a.m., Dave Airlie wrote: > >> On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: > >>> > >>> On Thu, 7 Jan 2021 at 21:11, Andreas Fänger > >>> wrote: > > >> don’t know why the current softpipe/swrast implementation > >> shouldn’t be conformant. > > > Interesting I hadn't known we had a correct impl in mesa, the > > features.txt has said "softpipe and llvmpipe advertise 16x > > anisotropy but simply ignore the setting" > > so I never dug any deeper. I'll consider a port of this to llvmpipe > > at some point, making it efficient might be tricky. > > It seems that features.txt hasn't been updated regarding this > functionality; softpipe has "real" anisotropy since 2011. > > > I'll consider a port of this to llvmpipe at some point, making it > > efficient might be tricky. > That would be great. As anisotropic filtering is often an option > which can be set by a user, I guess most people turn it off to get > higher framerates. But in our use case, high quality renderings are > required, so we accept the longer render times to get the best > quality; hopefully a llvmpipe port would be faster than the old > swrast implementation (we are only using the fixed rendering > pipeline/no shaders in conjunction with the OpenMP patch for > speeding up GL_POLYGON_SMOOTH_HINT) > > Andreas > >>> > >>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 > >>> > >>> Is my first pass at writing the code for this I've no idea if this is > >>> anyway correct, but I'm just letting everyone know I've started > >>> working on it, and mipmap_tunnel doesn't look immediately wrong. > >> > >> Olay the code in the MR above seems to work in most cases now and > >> seems to operate like softpipe. > >> > >> However I'm seeing a trace failure > >> https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ > >> > > > > The floor at the bottom left of the Actual image definitely looks odd, > > there's a hard line between the rock patterns. > > Not to mention the wall tiles having different sizes, with a hard line > as well. > > Definitely looks like a bug to me, which wouldn't be noticeable with > special test textures made up of different solid colours per mip level. I've fixed all the issues in that area, and I believe llvmpipe and softpipe mostly produce the same or very similiar results. I'm not overly impressed though by the texture quality at least the furmark trace shows as very blurry. Also the Vulkan CTS expects linear aniso to operate differently to how this has done it. Andreas, can you comment on this trace? https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7150044/gputest/furmark.trace/ I'm pretty sure softpipe looks the same locally for the same trace, and it just seems overly blurry. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On 2021-02-02 5:55 p.m., Michel Dänzer wrote: On 2021-02-02 6:44 a.m., Dave Airlie wrote: On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: don’t know why the current softpipe/swrast implementation shouldn’t be conformant. Interesting I hadn't known we had a correct impl in mesa, the features.txt has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting" so I never dug any deeper. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 Is my first pass at writing the code for this I've no idea if this is anyway correct, but I'm just letting everyone know I've started working on it, and mipmap_tunnel doesn't look immediately wrong. Olay the code in the MR above seems to work in most cases now and seems to operate like softpipe. However I'm seeing a trace failure https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ The floor at the bottom left of the Actual image definitely looks odd, there's a hard line between the rock patterns. Not to mention the wall tiles having different sizes, with a hard line as well. Definitely looks like a bug to me, which wouldn't be noticeable with special test textures made up of different solid colours per mip level. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On 2021-02-02 6:44 a.m., Dave Airlie wrote: On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: don’t know why the current softpipe/swrast implementation shouldn’t be conformant. Interesting I hadn't known we had a correct impl in mesa, the features.txt has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting" so I never dug any deeper. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 Is my first pass at writing the code for this I've no idea if this is anyway correct, but I'm just letting everyone know I've started working on it, and mipmap_tunnel doesn't look immediately wrong. Olay the code in the MR above seems to work in most cases now and seems to operate like softpipe. However I'm seeing a trace failure https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ The floor at the bottom left of the Actual image definitely looks odd, there's a hard line between the rock patterns. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote: > > On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: > > > > >> don’t know why the current softpipe/swrast implementation shouldn’t be > > >> conformant. > > > > >Interesting I hadn't known we had a correct impl in mesa, the features.txt > > >has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore > > >the setting" > > >so I never dug any deeper. I'll consider a port of this to llvmpipe at > > >some point, making it efficient might be tricky. > > > > It seems that features.txt hasn't been updated regarding this > > functionality; softpipe has "real" anisotropy since 2011. > > > > > I'll consider a port of this to llvmpipe at some point, making it > > > efficient might be tricky. > > That would be great. As anisotropic filtering is often an option which can > > be set by a user, I guess most people turn it off to get higher framerates. > > But in our use case, high quality renderings are required, so we accept the > > longer render times to get the best quality; hopefully a llvmpipe port > > would be faster than the old swrast implementation (we are only using the > > fixed rendering pipeline/no shaders in conjunction with the OpenMP patch > > for speeding up GL_POLYGON_SMOOTH_HINT) > > > > Andreas > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 > > Is my first pass at writing the code for this I've no idea if this is > anyway correct, but I'm just letting everyone know I've started > working on it, and mipmap_tunnel doesn't look immediately wrong. Olay the code in the MR above seems to work in most cases now and seems to operate like softpipe. However I'm seeing a trace failure https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/7033860/humus/Portals.trace/ that worries me that maybe the softpipe code isn't great, I'm going to try and reproduce the traces on softpipe locally to see how they look. I'd appreciate any testing that can be given to this code by preexisting users. Dave. > > Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Thu, 7 Jan 2021 at 21:11, Andreas Fänger wrote: > > >> don’t know why the current softpipe/swrast implementation shouldn’t be > >> conformant. > > >Interesting I hadn't known we had a correct impl in mesa, the features.txt > >has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore > >the setting" > >so I never dug any deeper. I'll consider a port of this to llvmpipe at some > >point, making it efficient might be tricky. > > It seems that features.txt hasn't been updated regarding this functionality; > softpipe has "real" anisotropy since 2011. > > > I'll consider a port of this to llvmpipe at some point, making it efficient > > might be tricky. > That would be great. As anisotropic filtering is often an option which can be > set by a user, I guess most people turn it off to get higher framerates. But > in our use case, high quality renderings are required, so we accept the > longer render times to get the best quality; hopefully a llvmpipe port would > be faster than the old swrast implementation (we are only using the fixed > rendering pipeline/no shaders in conjunction with the OpenMP patch for > speeding up GL_POLYGON_SMOOTH_HINT) > > Andreas https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8804 Is my first pass at writing the code for this I've no idea if this is anyway correct, but I'm just letting everyone know I've started working on it, and mipmap_tunnel doesn't look immediately wrong. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
>> don’t know why the current softpipe/swrast implementation shouldn’t be >> conformant. >Interesting I hadn't known we had a correct impl in mesa, the features.txt has >said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the >setting" >so I never dug any deeper. I'll consider a port of this to llvmpipe at some >point, making it efficient might be tricky. It seems that features.txt hasn't been updated regarding this functionality; softpipe has "real" anisotropy since 2011. > I'll consider a port of this to llvmpipe at some point, making it efficient > might be tricky. That would be great. As anisotropic filtering is often an option which can be set by a user, I guess most people turn it off to get higher framerates. But in our use case, high quality renderings are required, so we accept the longer render times to get the best quality; hopefully a llvmpipe port would be faster than the old swrast implementation (we are only using the fixed rendering pipeline/no shaders in conjunction with the OpenMP patch for speeding up GL_POLYGON_SMOOTH_HINT) Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
AFAIK, anisitropic filtering is almost uselessly underspecified, so pretty much anything should pass the CTS tests. But visual quality does affect applications, so we should probably aim for something reasonable. On Thu, 2021-01-07 at 19:41 +1000, Dave Airlie wrote: > On Thu, 7 Jan 2021 at 18:49, Andreas Fänger > wrote: > > > > Hi Dave, > > > > > > > > don’t know why the current softpipe/swrast implementation shouldn’t > > be conformant. > > Interesting I hadn't known we had a correct impl in mesa, the > features.txt has said > "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the > setting" > > so I never dug any deeper. I'll consider a port of this to llvmpipe > at > some point, making it efficient might be tricky. > > Dave. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Thu, 7 Jan 2021 at 18:49, Andreas Fänger wrote: > > Hi Dave, > > > > don’t know why the current softpipe/swrast implementation shouldn’t be > conformant. Interesting I hadn't known we had a correct impl in mesa, the features.txt has said "softpipe and llvmpipe advertise 16x anisotropy but simply ignore the setting" so I never dug any deeper. I'll consider a port of this to llvmpipe at some point, making it efficient might be tricky. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Hi Dave, don’t know why the current softpipe/swrast implementation shouldn’t be conformant. If that helps, here are the original patches which might give you a quick overview of what was required to get it working in softpipe and swrast back then (of course, the code is different now due to other changes) https://gitlab.freedesktop.org/mesa/mesa/-/commit/f4537f99cc83cb8133f66dc97c613e95dc0fe162 https://gitlab.freedesktop.org/mesa/mesa/-/commit/8a98aabe0bcea42cfdc982001ae4876e3d9b1214 Andreas Von: Dave Airlie Gesendet: Donnerstag, 7. Januar 2021 09:37 An: Andreas Fänger Cc: mesa-dev ; mesa-us...@lists.freedesktop.org Betreff: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa On Thu, 7 Jan 2021, 17:31 Andreas Fänger, mailto:a.faen...@e-sign.com> > wrote: Hi Dave, sounds good. Is there a particular reason not to port the softpipe anisotropic filter implementation (or from swrast, they are almost identical)? Wouldn’t that be easier to implement as it is based on the gallium infrastructure already? I hadn't really looked at mesa I had thought the aniso impl weren't conformant, I'll look again next week when I get back to work. Dave. Andreas Von: mesa-dev mailto:mesa-dev-boun...@lists.freedesktop.org> > Im Auftrag von Dave Airlie Gesendet: Donnerstag, 7. Januar 2021 05:56 An: Brian Paul mailto:bri...@vmware.com> > Cc: mesa-dev mailto:mesa-dev@lists.freedesktop.org> >; mesa-us...@lists.freedesktop.org <mailto:mesa-us...@lists.freedesktop.org> Betreff: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa I have some plans nothing firm to add some sort of aniso to llvmpipe. I was considering porting code from swiftshader, maybe I can bump it up the priority list. Dave. On Tue, 5 Jan 2021, 06:02 Brian Paul, mailto:bri...@vmware.com> > wrote: Forwarded Message Subject:[Mesa-users] Issues with removal of classic OSMesa Date: Thu, 31 Dec 2020 12:56:04 +0100 From: Andreas Fänger mailto:a.faen...@e-sign.com> > To: mesa-us...@lists.freedesktop.org <mailto:mesa-us...@lists.freedesktop.org> Hi, I've just seen that classic OSMesa has been removed (again) from Mesa3D a few weeks ago with this commit "mesa: Retire classic OSMesa". We are still actively using classical OSMesa for high quality rendering of still images in a headless environment with no GPU support (server-based rendering on windows and linux) Unfortunately, none of the alternative software renderers provide all the features that we require, which is antialiasing and anisotropic filtering. The current state is (correct me if I'm wrong) * softpipe: anisotropic filtering is supported, no antialiasing * llvmpipe: no anisotropic filtering, has MSAA * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) We had hoped that classical OSMesa is only removed when there is a full replacement after the discussions in 2016 when OSMesa was about to be removed for the first time https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html and the commit that reverted the removal http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c Are there any plans to enhance the renderers so that at least one of them is providing both anisotropic filtering and antialiasing? As far as I know, anisotropic texture filtering is also one of the OpenGL 4.6 requirements. In 2016 I was told that there are only very few developers involved in llvmpipe and that chances are not high that someone is going to port the softpipe anisotropic filtering implementation as llvmpipe is much more complex. Is there any change in that situation? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
On Thu, 7 Jan 2021, 17:31 Andreas Fänger, wrote: > Hi Dave, > > > > sounds good. Is there a particular reason not to port the softpipe anisotropic > filter implementation (or from swrast, they are almost identical)? > Wouldn’t that be easier to implement as it is based on the gallium > infrastructure already? > I hadn't really looked at mesa I had thought the aniso impl weren't conformant, I'll look again next week when I get back to work. Dave. > > > Andreas > > > > *Von:* mesa-dev *Im Auftrag von *Dave > Airlie > *Gesendet:* Donnerstag, 7. Januar 2021 05:56 > *An:* Brian Paul > *Cc:* mesa-dev ; > mesa-us...@lists.freedesktop.org > *Betreff:* Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of > classic OSMesa > > > > > > I have some plans nothing firm to add some sort of aniso to llvmpipe. I > was considering porting code from swiftshader, maybe I can bump it up the > priority list. > > > > Dave. > > > > On Tue, 5 Jan 2021, 06:02 Brian Paul, wrote: > > > > Forwarded Message > Subject:[Mesa-users] Issues with removal of classic OSMesa > Date: Thu, 31 Dec 2020 12:56:04 +0100 > From: Andreas Fänger > To: mesa-us...@lists.freedesktop.org > > Hi, > > I've just seen that classic OSMesa has been removed (again) from Mesa3D > a few weeks ago with this commit "mesa: Retire classic OSMesa". > > We are still actively using classical OSMesa for high quality rendering > of still images in a headless environment with no GPU support > (server-based rendering on windows and linux) > > Unfortunately, none of the alternative software renderers provide all > the features that we require, which is antialiasing and anisotropic > filtering. The current state is (correct me if I'm wrong) > > * softpipe: anisotropic filtering is supported, no antialiasing > > * llvmpipe: no anisotropic filtering, has MSAA > > > > > > * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) > > We had hoped that classical OSMesa is only removed when there is a full > replacement after the discussions in 2016 when OSMesa was about to be > removed for the first time > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html > > https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html > > and the commit that reverted the removal > > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c > > Are there any plans to enhance the renderers so that at least one of > them is providing both anisotropic filtering and antialiasing? > > As far as I know, anisotropic texture filtering is also one of the > OpenGL 4.6 requirements. > > In 2016 I was told that there are only very few developers involved in > llvmpipe and that chances are not high that someone is going to port the > softpipe anisotropic filtering implementation as llvmpipe is much more > complex. Is there any change in that situation? > > > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Hi Dave, sounds good. Is there a particular reason not to port the softpipe anisotropic filter implementation (or from swrast, they are almost identical)? Wouldn’t that be easier to implement as it is based on the gallium infrastructure already? Andreas Von: mesa-dev Im Auftrag von Dave Airlie Gesendet: Donnerstag, 7. Januar 2021 05:56 An: Brian Paul Cc: mesa-dev ; mesa-us...@lists.freedesktop.org Betreff: Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa I have some plans nothing firm to add some sort of aniso to llvmpipe. I was considering porting code from swiftshader, maybe I can bump it up the priority list. Dave. On Tue, 5 Jan 2021, 06:02 Brian Paul, mailto:bri...@vmware.com> > wrote: Forwarded Message Subject:[Mesa-users] Issues with removal of classic OSMesa Date: Thu, 31 Dec 2020 12:56:04 +0100 From: Andreas Fänger mailto:a.faen...@e-sign.com> > To: mesa-us...@lists.freedesktop.org <mailto:mesa-us...@lists.freedesktop.org> Hi, I've just seen that classic OSMesa has been removed (again) from Mesa3D a few weeks ago with this commit "mesa: Retire classic OSMesa". We are still actively using classical OSMesa for high quality rendering of still images in a headless environment with no GPU support (server-based rendering on windows and linux) Unfortunately, none of the alternative software renderers provide all the features that we require, which is antialiasing and anisotropic filtering. The current state is (correct me if I'm wrong) * softpipe: anisotropic filtering is supported, no antialiasing * llvmpipe: no anisotropic filtering, has MSAA * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) We had hoped that classical OSMesa is only removed when there is a full replacement after the discussions in 2016 when OSMesa was about to be removed for the first time https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html and the commit that reverted the removal http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c Are there any plans to enhance the renderers so that at least one of them is providing both anisotropic filtering and antialiasing? As far as I know, anisotropic texture filtering is also one of the OpenGL 4.6 requirements. In 2016 I was told that there are only very few developers involved in llvmpipe and that chances are not high that someone is going to port the softpipe anisotropic filtering implementation as llvmpipe is much more complex. Is there any change in that situation? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
I have some plans nothing firm to add some sort of aniso to llvmpipe. I was considering porting code from swiftshader, maybe I can bump it up the priority list. Dave. On Tue, 5 Jan 2021, 06:02 Brian Paul, wrote: > > > Forwarded Message > Subject:[Mesa-users] Issues with removal of classic OSMesa > Date: Thu, 31 Dec 2020 12:56:04 +0100 > From: Andreas Fänger > To: mesa-us...@lists.freedesktop.org > > Hi, > > I've just seen that classic OSMesa has been removed (again) from Mesa3D > a few weeks ago with this commit "mesa: Retire classic OSMesa". > > We are still actively using classical OSMesa for high quality rendering > of still images in a headless environment with no GPU support > (server-based rendering on windows and linux) > > Unfortunately, none of the alternative software renderers provide all > the features that we require, which is antialiasing and anisotropic > filtering. The current state is (correct me if I'm wrong) > > * softpipe: anisotropic filtering is supported, no antialiasing > > * llvmpipe: no anisotropic filtering, has MSAA > > > * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) > > We had hoped that classical OSMesa is only removed when there is a full > replacement after the discussions in 2016 when OSMesa was about to be > removed for the first time > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html > > https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html > > and the commit that reverted the removal > > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c > > Are there any plans to enhance the renderers so that at least one of > them is providing both anisotropic filtering and antialiasing? > > As far as I know, anisotropic texture filtering is also one of the > OpenGL 4.6 requirements. > > In 2016 I was told that there are only very few developers involved in > llvmpipe and that chances are not high that someone is going to port the > softpipe anisotropic filtering implementation as llvmpipe is much more > complex. Is there any change in that situation? > > > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Hi, llvmpipe could implement line and polygon smoothing by rasterizing in MSAA and passing the coverage to SampleMaskIn in the fragment shader, but doing Z/S tests and color writes and everything else single-sampled. Then, FragColor.a *= bitcount(SampleMaskIn) / (float)num_samples. It's roughly what OpenGL requires. There is at least one other gallium driver that does that. Marek On Mon, Jan 4, 2021 at 3:02 PM Brian Paul wrote: > Hi Andreas, > > I'm forwarding your message to the mesa-dev list for better visibility. > > BTW, when you say "antialiasing" below, what exactly do you mean? > > -Brian > > > Forwarded Message > Subject:[Mesa-users] Issues with removal of classic OSMesa > Date: Thu, 31 Dec 2020 12:56:04 +0100 > From: Andreas Fänger > To: mesa-us...@lists.freedesktop.org > > Hi, > > I've just seen that classic OSMesa has been removed (again) from Mesa3D > a few weeks ago with this commit "mesa: Retire classic OSMesa". > > We are still actively using classical OSMesa for high quality rendering > of still images in a headless environment with no GPU support > (server-based rendering on windows and linux) > > Unfortunately, none of the alternative software renderers provide all > the features that we require, which is antialiasing and anisotropic > filtering. The current state is (correct me if I'm wrong) > > * softpipe: anisotropic filtering is supported, no antialiasing > > * llvmpipe: no anisotropic filtering, has MSAA > > * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) > > We had hoped that classical OSMesa is only removed when there is a full > replacement after the discussions in 2016 when OSMesa was about to be > removed for the first time > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html > > https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html > > and the commit that reverted the removal > > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c > > Are there any plans to enhance the renderers so that at least one of > them is providing both anisotropic filtering and antialiasing? > > As far as I know, anisotropic texture filtering is also one of the > OpenGL 4.6 requirements. > > In 2016 I was told that there are only very few developers involved in > llvmpipe and that chances are not high that someone is going to port the > softpipe anisotropic filtering implementation as llvmpipe is much more > complex. Is there any change in that situation? > > If there are no such plans, is there any chance of reverting this commit > again so that classical OSMesa is available for windows and linux in > mesa >20? > > Regards, > > Andreas Fänger > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [Mesa-users] Issues with removal of classic OSMesa
Classic swrast didn't have MSAA either, so it sounds like softpipe meets your requirements as stated. I suspect actually by MSAA you meant GL_POLYGON_SMOOTH_HINT, the weird old sometimes-it-gets-you-coverage-in-alpha-output knob. Since you're software rasterizing, I'd recommend that you instead render at a higher res and downscale-- I suspect this with llvmpipe would be faster overall, and you'd get better quality even with aniso disabled. I feel like removing swrast support for GL_POLYGON_SMOOTH_HINT is fairly legitimate -- intel doesn't support it either, and it is just supposed to be a hint for the pre-msaa world. We ought to sort out aniso for llvmpipe anyway, though I don't know much about implementing it, and the fact that conformance doesn't detect lack of any aniso is a big disappointment. I heard ajax was poking at resurrecting msaa for softpipe, which would clear out a lot of our conformance fails there, and might avoid the need for user code changes if 4x MSAA is enough. On Mon, Jan 4, 2021 at 12:01 PM Brian Paul wrote: > > Hi Andreas, > > I'm forwarding your message to the mesa-dev list for better visibility. > > BTW, when you say "antialiasing" below, what exactly do you mean? > > -Brian > > > Forwarded Message > Subject:[Mesa-users] Issues with removal of classic OSMesa > Date: Thu, 31 Dec 2020 12:56:04 +0100 > From: Andreas Fänger > To: mesa-us...@lists.freedesktop.org > > Hi, > > I've just seen that classic OSMesa has been removed (again) from Mesa3D > a few weeks ago with this commit "mesa: Retire classic OSMesa". > > We are still actively using classical OSMesa for high quality rendering > of still images in a headless environment with no GPU support > (server-based rendering on windows and linux) > > Unfortunately, none of the alternative software renderers provide all > the features that we require, which is antialiasing and anisotropic > filtering. The current state is (correct me if I'm wrong) > > * softpipe: anisotropic filtering is supported, no antialiasing > > * llvmpipe: no anisotropic filtering, has MSAA > > * openswr: no anisotropic filtering, has MSAA, no OSMesa interface (?) > > We had hoped that classical OSMesa is only removed when there is a full > replacement after the discussions in 2016 when OSMesa was about to be > removed for the first time > > https://lists.freedesktop.org/archives/mesa-dev/2016-March/109665.html > > https://lists.freedesktop.org/archives/mesa-users/2016-March/001132.html > > and the commit that reverted the removal > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=9601815b4be886f4d92bf74916de98f3bdb7275c > > Are there any plans to enhance the renderers so that at least one of > them is providing both anisotropic filtering and antialiasing? > > As far as I know, anisotropic texture filtering is also one of the > OpenGL 4.6 requirements. > > In 2016 I was told that there are only very few developers involved in > llvmpipe and that chances are not high that someone is going to port the > softpipe anisotropic filtering implementation as llvmpipe is much more > complex. Is there any change in that situation? > > If there are no such plans, is there any chance of reverting this commit > again so that classical OSMesa is available for windows and linux in > mesa >20? > > Regards, > > Andreas Fänger > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
