[Mesa-dev] OpenCL in Mesa3d
Hello, I'm wanna ask about how I use Mesa as OpenCL implementation. Is it possible? If yes, how it work on Windows? Thank you! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting
+Thong. -Original Message- From: mesa-dev On Behalf Of Ilia Mirkin Sent: November 25, 2020 5:48 PM To: ML Mesa-dev ; Thai, Thong Subject: Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting Hi Thong, In this change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D49465babdb35d88ed8a283e925d6cd346255d50c&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135677095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g1pJUxsSM68kEjNZ6VDJGufaOF1Wwcezl1ehezq8mqo%3D&reserved=0 You appear to change the height of the underlying resource while doing a blit. This is never legal though -- the height of the resource is effectively immutable (and subject to various constraints). I'm not sure what issue you're having, but this is not the way to fix it. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135687091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ug6N9kvs1JzjDhHPpB%2F9ttrCaahVgm7NJ6Bk0zCxc4A%3D&reserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting
Hi Ilia, This was the issue I was trying to fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6736#note_626808 It's doing a blit from 1088px (the actual video is only 1080px) to 1440px. The blit code scales and uses both the 1080 box height and 1088 resource height, but I'm guessing the small difference is the problem I'm dealing with: u_bitcast_f2u(x_scale / src->width0), u_bitcast_f2u(y_scale / src->height0), p y_scale / src->height0 $4 = 0.000689338252 p y_scale / 1080 $6 = 0.00069461 I'm not sure how to properly fix it though... any ideas would be appreciated. Thanks, Thong Thai On 2020-11-30 10:52 a.m., Liu, Leo wrote: +Thong. -Original Message- From: mesa-dev On Behalf Of Ilia Mirkin Sent: November 25, 2020 5:48 PM To: ML Mesa-dev ; Thai, Thong Subject: Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting Hi Thong, In this change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D49465babdb35d88ed8a283e925d6cd346255d50c&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135677095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g1pJUxsSM68kEjNZ6VDJGufaOF1Wwcezl1ehezq8mqo%3D&reserved=0 You appear to change the height of the underlying resource while doing a blit. This is never legal though -- the height of the resource is effectively immutable (and subject to various constraints). I'm not sure what issue you're having, but this is not the way to fix it. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135687091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ug6N9kvs1JzjDhHPpB%2F9ttrCaahVgm7NJ6Bk0zCxc4A%3D&reserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting
Many (most?) codecs decode stuff in 16px increments. So even though the video is 1080 in height, the decoded surface is 1088. However the video decoder should know that only 1080 pixels are valid. The src/dst regions should account for this. I suspect that there's an issue in the vl_compositor_cs logic which might not account for ... something? It's trying to scale texture coordinates, so using the full texture width/height is clearly right for scaling. However perhaps the thing being scaled is wrong if it's in the coordinate system of the destination surface rather than the video texture. It's a bit hard to follow the shaders without pseudocode like there is in vl_compositor_gfx. Perhaps writing such pseudocode will make the problem more apparent? Cheers, -ilia On Mon, Nov 30, 2020 at 12:35 PM Thong Thai wrote: > > Hi Ilia, > > This was the issue I was trying to fix: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6736#note_626808 > > It's doing a blit from 1088px (the actual video is only 1080px) to > 1440px. The blit code scales and uses both the 1080 box height and 1088 > resource height, but I'm guessing the small difference is the problem > I'm dealing with: > >u_bitcast_f2u(x_scale / src->width0), >u_bitcast_f2u(y_scale / src->height0), > > p y_scale / src->height0 > $4 = 0.000689338252 > > p y_scale / 1080 > $6 = 0.00069461 > > I'm not sure how to properly fix it though... any ideas would be > appreciated. > > Thanks, > > Thong Thai > > On 2020-11-30 10:52 a.m., Liu, Leo wrote: > > +Thong. > > > > -Original Message- > > From: mesa-dev On Behalf Of Ilia > > Mirkin > > Sent: November 25, 2020 5:48 PM > > To: ML Mesa-dev ; Thai, Thong > > > > Subject: Re: [Mesa-dev] frontends/va/postproc: Use the actual image height > > when blitting > > > > Hi Thong, > > > > In this change: > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D49465babdb35d88ed8a283e925d6cd346255d50c&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135677095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g1pJUxsSM68kEjNZ6VDJGufaOF1Wwcezl1ehezq8mqo%3D&reserved=0 > > > > You appear to change the height of the underlying resource while doing a > > blit. This is never legal though -- the height of the resource is > > effectively immutable (and subject to various constraints). I'm not sure > > what issue you're having, but this is not the way to fix it. > > > > Cheers, > > > >-ilia > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cleo.liu%40amd.com%7C92b8ad99a46447208c3008d891943b09%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637419413135687091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ug6N9kvs1JzjDhHPpB%2F9ttrCaahVgm7NJ6Bk0zCxc4A%3D&reserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting
Doh, sorry. I just found out, the problem is not with the height0 and scaling, it's with the y offset calculation: (blit_info->src.box.y + 0.5) / (float)src->height0 Everything seems to work if I revert the offending code that modifies height0, and just use this for the y offset: blit_info->src.box.y I'll look into a bit more... Thanks for the help, Thong Thai On 2020-11-30 1:07 p.m., Ilia Mirkin wrote: Many (most?) codecs decode stuff in 16px increments. So even though the video is 1080 in height, the decoded surface is 1088. However the video decoder should know that only 1080 pixels are valid. The src/dst regions should account for this. I suspect that there's an issue in the vl_compositor_cs logic which might not account for ... something? It's trying to scale texture coordinates, so using the full texture width/height is clearly right for scaling. However perhaps the thing being scaled is wrong if it's in the coordinate system of the destination surface rather than the video texture. It's a bit hard to follow the shaders without pseudocode like there is in vl_compositor_gfx. Perhaps writing such pseudocode will make the problem more apparent? Cheers, -ilia On Mon, Nov 30, 2020 at 12:35 PM Thong Thai wrote: Hi Ilia, This was the issue I was trying to fix: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F6736%23note_626808&data=04%7C01%7Cthong.thai%40amd.com%7C4d9cd68ad841465f4d8508d8955ac609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637423564389321354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eP4K8SCqvmr6E2ebfZKfMtbtKoboSTv8eXTzZdn8lto%3D&reserved=0 It's doing a blit from 1088px (the actual video is only 1080px) to 1440px. The blit code scales and uses both the 1080 box height and 1088 resource height, but I'm guessing the small difference is the problem I'm dealing with: u_bitcast_f2u(x_scale / src->width0), u_bitcast_f2u(y_scale / src->height0), p y_scale / src->height0 $4 = 0.000689338252 p y_scale / 1080 $6 = 0.00069461 I'm not sure how to properly fix it though... any ideas would be appreciated. Thanks, Thong Thai On 2020-11-30 10:52 a.m., Liu, Leo wrote: +Thong. -Original Message- From: mesa-dev On Behalf Of Ilia Mirkin Sent: November 25, 2020 5:48 PM To: ML Mesa-dev ; Thai, Thong Subject: Re: [Mesa-dev] frontends/va/postproc: Use the actual image height when blitting Hi Thong, In this change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D49465babdb35d88ed8a283e925d6cd346255d50c&data=04%7C01%7Cthong.thai%40amd.com%7C4d9cd68ad841465f4d8508d8955ac609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637423564389331348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=i5nSRYtxTMmp8C8Y%2FfF1xXcoPq5u9ZGYbNgeNbuqb1w%3D&reserved=0 You appear to change the height of the underlying resource while doing a blit. This is never legal though -- the height of the resource is effectively immutable (and subject to various constraints). I'm not sure what issue you're having, but this is not the way to fix it. Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cthong.thai%40amd.com%7C4d9cd68ad841465f4d8508d8955ac609%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637423564389331348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3ZaXKDZcHEYZPiRTRHe3Q1ZqZEwZgskrSE%2FqQVIZjkI%3D&reserved=0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [ANNOUNCE] mesa 20.3.0-rc3
Hi list, Mesa 20.3-rc3 is now available for general consumption. This is a few days late thanks to the US Thanksgiving holiday. I think we're pretty close to having .0 this week, just one issue left on the tracker. Dylan git tag: mesa-20.3.0-rc3 https://mesa.freedesktop.org/archive/mesa-20.3.0-rc3.tar.xz SHA256: c6c92406aec01a2dd6844aa32a90ea77d2959d939445311037a8a11fd3cb91bc mesa-20.3.0-rc3.tar.xz SHA512: f0114ee938c1041b345c052716e4582ec6fcda27b7625e9dab511282ba3676439c79a77514421dc669b737150169e0e01e3355e94db9a5f65c5c50cdaac898bd mesa-20.3.0-rc3.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-20.3.0-rc3.tar.xz.sig signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl4_gears - SPIR-V and shader module reflection
On 11/30/20 3:38 PM, Michael Clark wrote: Hi again, On 11/24/20 9:43 PM, Michael Clark wrote: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders I decided to use this app to experiment with some of the new OpenGL features in particular the ability to share shader modules between OpenGL and Vulkan. Be nice because we will have portable binaries... subsequently added: - gl3_gears - moved vertex array objects here and downgraded gl2_gears - gl4_gears - added uniform buffer objects and SPIR-V shader modules OpenGL 4.x SPIR-V attribute reflection branch is here: - https://github.com/michaeljclark/glkitty/tree/opengl4-experiment gl4_gears is decidedly experimental and there issues with attribute reflection that need to be resolved. NVIDIA OpenGL 450 implementation has bugs with reassignment of attribute locations when using the #version 450 shader dialect with explicit location, used by the SPIR-V shader modules, so a different set of locations is used in comparison to vk1_gears. likewise Mesa has a somewhat alternate behavior and also appears buggy. It's really a bit messy, especially given I still want to perform reflection but now the shaders have mandatory location attrs. that seems to me like a backwards step for hot reloading of experiments. See the #define in: shaders/gears.vert#L3-L5 - GENERIC_VULKAN - set by default to enable vk1_gears - NVIDIA_OPENGL - set to run gl4_gears with nvidia-450 - MESA_OPENGL - set to run gl4_gears with Mesa 20.0.8 similarly there is a USE_SPIRV define near the top of gl4_gears.c which currently has only been tested to work with NVIDIA OpenGL 450 need to spend some time reading ARB_gl_spirv.txt. it seems reflection is becoming optional instead of intrinsic, which is a step backwards for OpenGL, although I can see why OpenGL ES, of potentially large games, may want to statically link offsets, but previously I could rely on dynamic evaluation of shader module attribute names. It makes life easy for the developer/user of these APIs. noticing I might be able to compile separate SPIR-V modules: #ifdef GL_SPIRV which is also not ideal because now I don't have portable binaryies given its silly (now manual) linkage. it seems reflection is optional for SPIR-V, and the attribute reflection is not yet? working in Mesa? also it seems if I find the attribute I can't relink it. there is a whole set of new APIs to explore. just an fyi on a gl4_gears that could be an interesting test cast for mesa-demos as this port of gears is still pure C. I am actually working in C++, but tend to like to isolate dependencies when working on small tests for context initialization and what not... anyway keep up the good work!!! i'm surprised how close Mesa is to supporting all of the latest APIs. the next step was exploring bindless... I managed to get a solution that works with NVIDIA Vulkan and OpenGL drivers as well as the Mesa Drivers in Ubuntu. I did this by disabling reflection and just scanning the re-assigned in a reverse lookup from the name, which is ironic. It seems that reassigning the indices does not work on some drivers. I was doing that because of NVIDIA driver's dislike for 0. It begs the question of where OpenGL, OpenGL ES and GLSL are headed. I am quite interested in the position of Intel and freedesktop on the SPIR-V draft: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt location seems like redundant boiler plate to me. It seems natural to see the declarations like a struct and use declaration order if location is not present. This would not affect Vulkan in any substantive way, as it would be an "re-addition" versus a "subtraction" of reflection to the OpenGL suite of APIs. I am a proponent of concise and hot-reload. Supposedly necessary but unnecessary complexity. Like an artist protecting his encrypted SPIR-V assets so they can make a crust on the web, instead of asm.js and text-only for certain assets. And of course (location = ?) does not make sense there. I understand the need. It just seems there are some mutually exclusive forces at play. Why can't I have a binary module and export the names of functions and struct members, Vulkan would need some utility interfaces outside of the driver to find the strings in the SPIR-V, but it seems straight forward given the constraint has been "added", with both OpenGL and OpenCL traditionally being relatively low-level interfaces with introspection and reflection. Just so you are aware of one independent developer's position. I would like to reflect on function arity and make JIT dispatch proxies so that C can transparently call GLSL code with fixed sized arrays. The GLSL is the safe subset of the language at the moment
Re: [Mesa-dev] gl4_gears - SPIR-V and shader module reflection
On 12/1/20 11:27 AM, Michael Clark wrote: On 11/30/20 3:38 PM, Michael Clark wrote: Hi again, On 11/24/20 9:43 PM, Michael Clark wrote: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders I decided to use this app to experiment with some of the new OpenGL features in particular the ability to share shader modules between OpenGL and Vulkan. Be nice because we will have portable binaries... subsequently added: - gl3_gears - moved vertex array objects here and downgraded gl2_gears - gl4_gears - added uniform buffer objects and SPIR-V shader modules OpenGL 4.x SPIR-V attribute reflection branch is here: - https://github.com/michaeljclark/glkitty/tree/opengl4-experiment gl4_gears is decidedly experimental and there issues with attribute reflection that need to be resolved. NVIDIA OpenGL 450 implementation has bugs with reassignment of attribute locations when using the #version 450 shader dialect with explicit location, used by the SPIR-V shader modules, so a different set of locations is used in comparison to vk1_gears. likewise Mesa has a somewhat alternate behavior and also appears buggy. It's really a bit messy, especially given I still want to perform reflection but now the shaders have mandatory location attrs. that seems to me like a backwards step for hot reloading of experiments. See the #define in: shaders/gears.vert#L3-L5 - GENERIC_VULKAN - set by default to enable vk1_gears - NVIDIA_OPENGL - set to run gl4_gears with nvidia-450 - MESA_OPENGL - set to run gl4_gears with Mesa 20.0.8 similarly there is a USE_SPIRV define near the top of gl4_gears.c which currently has only been tested to work with NVIDIA OpenGL 450 need to spend some time reading ARB_gl_spirv.txt. it seems reflection is becoming optional instead of intrinsic, which is a step backwards for OpenGL, although I can see why OpenGL ES, of potentially large games, may want to statically link offsets, but previously I could rely on dynamic evaluation of shader module attribute names. It makes life easy for the developer/user of these APIs. noticing I might be able to compile separate SPIR-V modules: #ifdef GL_SPIRV which is also not ideal because now I don't have portable binaryies given its silly (now manual) linkage. it seems reflection is optional for SPIR-V, and the attribute reflection is not yet? working in Mesa? also it seems if I find the attribute I can't relink it. there is a whole set of new APIs to explore. just an fyi on a gl4_gears that could be an interesting test cast for mesa-demos as this port of gears is still pure C. I am actually working in C++, but tend to like to isolate dependencies when working on small tests for context initialization and what not... anyway keep up the good work!!! i'm surprised how close Mesa is to supporting all of the latest APIs. the next step was exploring bindless... I managed to get a solution that works with NVIDIA Vulkan and OpenGL drivers as well as the Mesa Drivers in Ubuntu. I did this by disabling reflection and just scanning the re-assigned in a reverse lookup from the name, which is ironic. It seems that reassigning the indices does not work on some drivers. I was doing that because of NVIDIA driver's dislike for 0. It begs the question of where OpenGL, OpenGL ES and GLSL are headed. I am quite interested in the position of Intel and freedesktop on the SPIR-V draft: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt location seems like redundant boiler plate to me. It seems natural to see the declarations like a struct and use declaration order if location is not present. This would not affect Vulkan in any substantive way, as it would be an "re-addition" versus a "subtraction" of reflection to the OpenGL suite of APIs. I am a proponent of concise and hot-reload. a readdition. I had written addition, and realized it is not an addition, so added re- but missed the context. i was a little rushed. Supposedly necessary but unnecessary complexity. Like an artist protecting his encrypted SPIR-V assets so they can make a crust on the web, instead of asm.js and text-only for certain assets. And of course (location = ?) does not make sense there. I understand the need. It just seems there are some mutually exclusive forces at play. Why can't I have a binary module and export the names of functions and struct members, Vulkan would need some utility interfaces outside of the driver to find the strings in the SPIR-V, but it seems straight forward given the constraint has been "added", with both OpenGL and OpenCL traditionally being relatively low-level interfaces with introspection and reflection. Just so you are aware of one independent developer's position. I would like to r
