Re: Question about BITSET_WORD

All 32-bit operations are generally faster than 64-bit. If both happen to have the same performance per clock (that would have to be a deliberate hw design choice), 32-bit opcodes have likely lower power consumption, which allows a higher core frequency. That doesn't even scratch the surface. Expl

Re: Question about BITSET_WORD

Maybe there should be a comment regarding the performance and risk of change? -Brian On 8/21/24 07:54, Faith Ekstrand wrote: I've actually benchmarked this and 32bit is still faster on many modern CPUs. Also, I would be very surprised if we could change it without breaking the universe. I'm

Re: Question about BITSET_WORD

I've actually benchmarked this and 32bit is still faster on many modern CPUs. Also, I would be very surprised if we could change it without breaking the universe. I'm sure there are hard-coded 32s various places. ~Faith On Wed, Aug 21, 2024 at 8:13 AM Christophe JAILLET < christophe.jail...@wana

Question about BITSET_WORD

Hi, I'm new to this list, so sorry if it is not the correct place. I've started to looked at the source code of mesa and I wonder why in src/util/bitset.h we have: #define BITSET_WORD unsigned int This is as-is since at least 2015, probably 2011. Would it make sense to have it as a long

Re: Lavapipe performance question during interactive drawing

Hi Dave, Indeed after setting LP_DEBUG=fs I get a lot of repetitive printing during the interactive actions. After some more searching it finally seems that the problem is on our side, which forces some pipelines to be continuously re-created. Thanks everyone for your help, and I apologize for the

Re: Lavapipe performance question during interactive drawing

On Fri, 5 May 2023 at 21:30, George Karpathios wrote: > > Hi list, > > I'm using Lavapipe for Vulkan software rendering support in a modeling > application. I notice a large performance hit (with any Mesa version) in the > following scenario: The user clicks & drags the mouse in order to create

Re: Lavapipe performance question during interactive drawing

Anything as long as it exhibits the issue. On Fri, May 5, 2023 at 11:52 AM George Karpathios wrote: > Not sure, I may have to get approval first. Will see what I can do. If so, > are there any specific options you'd like enabled? Thanks > > Best regards, > George > > On Fri, May 5, 2023 at 5:33 

Re: Lavapipe performance question during interactive drawing

Not sure, I may have to get approval first. Will see what I can do. If so, are there any specific options you'd like enabled? Thanks Best regards, George On Fri, May 5, 2023 at 5:33 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Can you provide a gfxreconstruct of the scenario?

Re: Lavapipe performance question during interactive drawing

Can you provide a gfxreconstruct of the scenario? On Fri, May 5, 2023 at 10:32 AM George Karpathios wrote: > Hi Mike, > > Thanks for responding. I commented the call > to lvp_find_inlinable_uniforms() in lvp_pipeline.c but unfortunately it > didn't help this time. It may have gotten a bit worse

Re: Lavapipe performance question during interactive drawing

Hi Mike, Thanks for responding. I commented the call to lvp_find_inlinable_uniforms() in lvp_pipeline.c but unfortunately it didn't help this time. It may have gotten a bit worse actually. Best regards, George On Fri, May 5, 2023 at 3:08 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wr

Re: Lavapipe performance question during interactive drawing

Hi, Can you try commenting out the same lines from last time and see whether that affects anything? Mike On Fri, May 5, 2023 at 7:30 AM George Karpathios wrote: > Hi list, > > I'm using Lavapipe for Vulkan software rendering support in a modeling > application. I notice a large performance hi

Lavapipe performance question during interactive drawing

Hi list, I'm using Lavapipe for Vulkan software rendering support in a modeling application. I notice a large performance hit (with any Mesa version) in the following scenario: The user clicks & drags the mouse in order to create a simple shape (e.g. plane, cube, sphere) dynamically and the result

Re: Question: error when running [Virtio-GPU Venus->vtest]

 On 2022-11-08 18:35, Gert Wollny wrote: Hello, On Sun, 2022-11-06 at 11:33 -0800, Rob Clark wrote: On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor wrote: Dear Developers: I am referring to this document https://docs.mesa3d.org/drivers/venus.html#vtest  to develop vulkan related functions, but

Re: Question: error when running [Virtio-GPU Venus->vtest]

Hello, On Sun, 2022-11-06 at 11:33 -0800, Rob Clark wrote: > On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor > wrote: > > > > Dear Developers: > > > > I am referring to this document > > https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan > > related functions, but every time I r

Re: Question: error when running [Virtio-GPU Venus->vtest]

On Fri, Nov 4, 2022 at 1:42 AM Taylor Viktor wrote: > > Dear Developers: > > I am referring to this document > https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan related > functions, but every time I run vulkaninfo or vkcube some errors occur. > > virgl_test_server prints the fol

Question: error when running [Virtio-GPU Venus->vtest]

Dear Developers: I am referring to this document https://docs.mesa3d.org/drivers/venus.html#vtest to develop vulkan related functions, but every time I run vulkaninfo or vkcube some errors occur. virgl_test_server prints the following: gl_version 46 - core profile enabled vtest_client_dispatch_c

Re: Question about eglCreatePbufferSurface with empty attrib_list

AFAIK this was the pre-framebuffer-object / OES_surfaceless_context way of making a context current without (really) having a bound surface. That said I don't think Mesa actually implements that feature correctly, atm I think you'll get a BadValue from the xcb_create_pixmap call, but patches to fix

Question about eglCreatePbufferSurface with empty attrib_list

Hi, In spec, eglCreatePbufferSurface is allowed to be called with attrib_list is NULL or empty, which means EGL_WIDTH/EGL_HEIGHT for the surface is 0. And in mesa code, specific to android path, I cannot find the width/height could be updated to a normal value. Also the eglMakeCurrent call after

Re: Question

On Wed, 2022-03-16 at 19:04 -0700, Immortal Tassadar wrote: > Hello. I would like to know if you are still working in the windows > port of Zink? I can only really answer this in fairly vague terms, because I don't know what everyone else is working on, but: 1. There's currently basic Windows sup

Question

Hello. I would like to know if you are still working in the windows port of Zink?

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Mhm, that looks like it's something I should look into. How exactly are you triggering this and which kernel version are you using? Thanks, Christian. Am 14.09.21 um 03:47 schrieb Luc Ma: Yes, I did. It crashed the kernel as follows Sep 14 09:12:34 kernel: [  506.676925][ 4] [ T1045] Hardware

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Yes, I did. It crashed the kernel as follows Sep 14 09:12:34 kernel: [ 506.676925][ 4] [ T1045] Hardware name: WEIBU F20A8/F20A8, BIOS 0.1.3 2021-07-06_20:59:09 Sep 14 09:12:34 kernel: [ 506.685091][ 4] [ T1045] pstate: 8005 (Nzcv daif -PAN -UAO) Sep 14 09:12:34 kernel: [ 506.691001][ 4] [

Re: [Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

On 2021-09-13 14:40, Luc Ma wrote: > Hello, > > I recently tried multi-GPU support on the mesa gallium drivers(glx=dri). When > I exported the env `DRI_PRIME=1`, I found that it didn't work with two > different drivers loaded at the same time. > because there are different driver names in my cas

[Mesa-dev] Question about display_gpu and render gpu in dri3_create_screen

Hello, I recently tried multi-GPU support on the mesa gallium drivers(glx=dri). When I exported the env `DRI_PRIME=1`, I found that it didn't work with two different drivers loaded at the same time. because there are different driver names in my case. display_gpu driver name is "r600" while render

[Mesa-dev] Question in wsi_common_x11.c

Hello, In the following code why mage->base.row_pitches[0] is divided by 4 and passed as width to xcb_put_function() ? 26 static VkResult 25 x11_present_to_x11_sw(struct x11_swapchain *chain, uint32_t image_index, ... 15 14cookie = xcb_put_image(chain->conn, XCB_IMAGE_FORMAT_Z_PIXMAP,

Re: [Mesa-dev] question about MR8409 status

On 2/2/21 2:47 pm, Lionel Landwerlin wrote: Hi Andrii, Just assigned it to Marge. Sorry for the delay. Thanks a lot. -Lionel On 02/02/2021 13:57, asimiklit wrote: Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it w

Re: [Mesa-dev] question about MR8409 status

Hi Andrii, Just assigned it to Marge. Sorry for the delay. -Lionel On 02/02/2021 13:57, asimiklit wrote: Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it was simply forgotten or there are some issues with it I am not

[Mesa-dev] question about MR8409 status

Hello, Are there some issues/blockers which prevent MR8409 from being merged? This MR already has r-b and I suspect that it was simply forgotten or there are some issues with it I am not aware of. I don't have merge access that is why I am asking about it. Thanks, Andrii. __

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

Hi, I'd like to complement Jason's excellent answer with some code examples. ac_nir_to_llvm is used by two drivers, RADV and RadeonSI. Each of them have a driver-specific implementation of the shader ABI. For RADV's implementation, take a look at llvm_compile_shader in radv_nir_to_llvm.c and to

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

Possibly worth noting as another point for reference is that zink also uses variables. On Sun, Oct 11, 2020, 11:08 AM Jason Ekstrand wrote: > First off, I should point out that the AMD NIR -> LLVM translator is, > as far as I know, the only NIR back-end that consumes variables at > all. Most ba

Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

First off, I should point out that the AMD NIR -> LLVM translator is, as far as I know, the only NIR back-end that consumes variables at all. Most back-ends assume that all variable access is completely lowered away before the back-end ever sees it. How this is done depends on the variable mode.

[Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var

I see that visit_load_var() in ~/mesa/src/amd/llvm/ac_nir_to_llvm.c assumes that nir_variable used in this intrinsic can have few specific mods only. For example variable can not have nir_var_mem_shared , if such mod encountered it will execute unreachable() code. Is there any nir pass that need

Re: [Mesa-dev] CI for vallium question

On Sun, Aug 16, 2020 at 2:01 PM Dave Airlie wrote: > > meson-gallium builds all the gallium drivers but no vulkan drivers. > meson-vulkan builds all the vulkan driver but no gallium. > > I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so > I suppose the former is more suitable,

Re: [Mesa-dev] CI for vallium question

I think you should add vallium to whichever builds will be the least extended by adding vallium; I'm guessing that's going to be the gallium build? On 2020-08-16 at 23:01, Dave Airlie wrote: > meson-gallium builds all the gallium drivers but no vulkan drivers. > meson-vulkan builds all the vulk

[Mesa-dev] CI for vallium question

meson-gallium builds all the gallium drivers but no vulkan drivers. meson-vulkan builds all the vulkan driver but no gallium. I've changed the enable to be -Dvulkan-drivers=swrast to enable it, so I suppose the former is more suitable, but just looking for suggestions. Dave. _

[Mesa-dev] [Bug 110640] vlPostProc question

https://bugs.freedesktop.org/show_bug.cgi?id=110640 GitLab Migration User changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [Mesa-dev] A question about order of st_update_*p

OK. Would you mind give some link to some document what's the exact meaning of "dependence" in st/mesa since it's unrelated with gpu execution. Thanks. On Fri, Jul 26, 2019 at 1:27 PM Marek Olšák wrote: > > The order of GPU execution doesn't matter here. > > M. > > On Fri., Jul. 26, 2019, 16:11 L

Re: [Mesa-dev] A question about order of st_update_*p

The order of GPU execution doesn't matter here. M. On Fri., Jul. 26, 2019, 16:11 Lepton Wu, wrote: > I am confused, for example, according to: > > https://www.khronos.org/opengl/wiki/Geometry_Shader, it come after > Vertex shader, that mean, it depends on vertex shader, right? > So st_update_g

Re: [Mesa-dev] A question about order of st_update_*p

On Fri., Jul. 26, 2019, 15:58 Lepton Wu, wrote: > If shader A depends on shader B, should we put st_update_shaderB in > front of st_update_shaderA? > That's the current order. The order of GPU execution doesn't matter. M. > Now the order looks like reversed... > > On Fri, Jul 26, 2019 at 12

Re: [Mesa-dev] A question about order of st_update_*p

I am confused, for example, according to: https://www.khronos.org/opengl/wiki/Geometry_Shader, it come after Vertex shader, that mean, it depends on vertex shader, right? So st_update_gp should be after st_update_vp, but now it is in the front of st_update_vp. On Fri, Jul 26, 2019 at 1:07 PM Mar

Re: [Mesa-dev] A question about order of st_update_*p

If shader A depends on shader B, should we put st_update_shaderB in front of st_update_shaderA? Now the order looks like reversed... On Fri, Jul 26, 2019 at 12:34 PM Marek Olšák wrote: > > The order shouldn't matter, but there can be a reason behind it, e.g. if a > shader depends on the updat

Re: [Mesa-dev] A question about order of st_update_*p

The order shouldn't matter, but there can be a reason behind it, e.g. if a shader depends on the update of the following shader. Marek On Wed, Jul 24, 2019 at 7:19 PM Lepton Wu wrote: > In src/mesa/state_tracker/st_atom_list.h, > > Now it's this order: > > ST_STATE(ST_NEW_FS_STATE, st_update_fp

[Mesa-dev] A question about order of st_update_*p

In src/mesa/state_tracker/st_atom_list.h, Now it's this order: ST_STATE(ST_NEW_FS_STATE, st_update_fp) ST_STATE(ST_NEW_GS_STATE, st_update_gp) ST_STATE(ST_NEW_TES_STATE, st_update_tep) ST_STATE(ST_NEW_TCS_STATE, st_update_tcp) ST_STATE(ST_NEW_VS_STATE, st_update_vp) While code in src/mesa/state_

Re: [Mesa-dev] GitLab Merge Request stable workflow question

git send-email will cause it to also get sent to the stable ml so it wasn't clear to me that it would still work that way with a merge request. I saw my commit end up in the new stable releases though so I suppose that answers my question, i.e. cc in the message is sufficient for both ml

Re: [Mesa-dev] GitLab Merge Request stable workflow question

equest. I saw my commit end up in the new stable releases though so I suppose that answers my question, i.e. cc in the message is sufficient for both ml and mr submissions. Thanks - Chuck On Tue, May 7, 2019, 19:07 Marek Olšák wrote: > There is a document about this in docs/, but I think you

[Mesa-dev] [Bug 110640] vlPostProc question

https://bugs.freedesktop.org/show_bug.cgi?id=110640 Bug ID: 110640 Summary: vlPostProc question Product: Mesa Version: 18.0 Hardware: ARM OS: All Status: NEW Severity: normal Priority: medium

Re: [Mesa-dev] GitLab Merge Request stable workflow question

tem enough to > nominate it for inclusion in stable or does it still need to be separately > sent to the stable mailing list? > > The question is specifically wrt > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/806 since I'd > like to see the fix in the next stable

[Mesa-dev] GitLab Merge Request stable workflow question

When doing an MR via GitLab, is adding the Cc: mesa-stable item enough to nominate it for inclusion in stable or does it still need to be separately sent to the stable mailing list? The question is specifically wrt https://gitlab.freedesktop.org/mesa/mesa/merge_requests/806 since I'd like t

[Mesa-dev] [Question] nir_intrinsic_load_uniform use float const_offset now

Hi guys, When doing rebase from 18.3 to master branch, I found nir_intrinsic_load_uniform use float const_offset now. But most gallium drivers still treat it as int except freedreno. I don't know which commit did this, is this expected? Regards, Qiang

Re: [Mesa-dev] Mesa master branch vulkan/build question

That's packaged for bionic, might be worth creating your own PPA and base the pkgbuild on that - apologies if I'm getting the lingo wrong - I don't use Ubuntu myself Alternatively maybe check for other PPAs that might have them already packaged for you, I think Padoka and Oibaf might have what you

Re: [Mesa-dev] Mesa master branch vulkan/build question

On Thu, 2 Aug 2018 17:55:21 +0100 Mike Lothian wrote: > Which distro are you using? uBuntu-14.045 & uBuntu-16.04 Thanks, Guang > > On Thu, 2 Aug 2018 at 17:35 Guang Bai wrote: > > > This is the reason for me to look for helps from our mesa-dev > > community. Thanks, > > Guang > > > > On Thu,

Re: [Mesa-dev] Mesa master branch vulkan/build question

Which distro are you using? On Thu, 2 Aug 2018 at 17:35 Guang Bai wrote: > This is the reason for me to look for helps from our mesa-dev community. > Thanks, > Guang > > On Thu, 2 Aug 2018 17:10:16 +0100 > Mike Lothian wrote: > > > Yeah the lease stuff was added in the newer version of xcb-prot

Re: [Mesa-dev] Mesa master branch vulkan/build question

Hi It would be helpful if you posted the failure output, without it its difficult to diagnose I'm not seeing any issues with the master branch on the meson build Is this your first time building mesa, or has something suddenly stopped working? Cheers Mike On Thu, 2 Aug 2018 at 16:46 Guang Bai

[Mesa-dev] Mesa master branch vulkan/build question

All, I'm seeing build failures on mesa 18.2 & master branches with "--with-vulkan-drivers=intel" And also notice some web-posting that libxcb-xrandr 1.13 would be needed to get the build successful. What's the correct solution for my build issue? (I'm still new to mesa) Thanks! Guang __

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

ork.freedesktop.org/patch/160944/ >> https://patchwork.freedesktop.org/patch/188695/ >> >> So I have some question about it: >> your implementation seems to depend on platform (Android, wayland) support, >> for example call native_window_set_surface_damage() in A

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Qiang, Qiang Yu writes: >> > For lima implementation, I want to use the damage region (buffer >> > damage) provided >> > by EGL_KHR_partial_update to skip rendering of un-damaged region when >> > eglSwapBuffersXXX. And tell damage region (surface damage) to compositor >> > should >> > be lef

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

the deqp test case for partial_udpate, it also looks like the > intension was for the rendering to be restricted to only those rectangles. > > Side question: We could also send the damage to the compositor? As the extension spec describe no compositor side effect, I think we should not do th

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

p.org/patch/188695/ > > So I have some question about it: > your implementation seems to depend on platform (Android, wayland) support, > for example call native_window_set_surface_damage() in Android implementation. > What's the purpose of it, tell the Android SurfaceFlinger

Re: [Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Qiang, Qiang Yu writes: > Hi Harish, > > I want to implement EGL_KHR_partial_update for lima mesa driver and find you > worked on Android/Wayland support for it: > https://patchwork.freedesktop.org/patch/160944/ > https://patchwork.freedesktop.org/patch/188695/ > >

[Mesa-dev] Question about EGL_KHR_partial_update implementation

Hi Harish, I want to implement EGL_KHR_partial_update for lima mesa driver and find you worked on Android/Wayland support for it: https://patchwork.freedesktop.org/patch/160944/ https://patchwork.freedesktop.org/patch/188695/ So I have some question about it: your implementation seems to depend

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On 07/05/18 20:36, Jason Ekstrand wrote: > On Mon, May 7, 2018 at 9:37 AM, Kenneth Graunke > wrote: > > On Monday, May 7, 2018 8:53:34 AM PDT Jason Ekstrand wrote: > > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro > mailto:apinhe...@igalia.com>> >

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On 07/05/18 21:21, Rob Clark wrote: > On Mon, May 7, 2018 at 2:36 PM, Jason Ekstrand wrote: >> On Mon, May 7, 2018 at 11:02 AM, Rob Clark wrote: >>> On Mon, May 7, 2018 at 11:53 AM, Jason Ekstrand >>> wrote: On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro wrote: > Hi Jason, >>

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Mon, May 7, 2018 at 2:36 PM, Jason Ekstrand wrote: > On Mon, May 7, 2018 at 11:02 AM, Rob Clark wrote: >> >> On Mon, May 7, 2018 at 11:53 AM, Jason Ekstrand >> wrote: >> > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro >> > wrote: >> >> >> >> Hi Jason, >> >> >> >> as part of the ARB_gl_sp

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Mon, May 7, 2018 at 9:37 AM, Kenneth Graunke wrote: > On Monday, May 7, 2018 8:53:34 AM PDT Jason Ekstrand wrote: > > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro > > wrote: > > > > > Hi Jason, > > > > > > as part of the ARB_gl_spirv work, we are doing the linking based on the > > > nir

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Mon, May 7, 2018 at 11:02 AM, Rob Clark wrote: > On Mon, May 7, 2018 at 11:53 AM, Jason Ekstrand > wrote: > > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro > > wrote: > >> > >> Hi Jason, > >> > >> as part of the ARB_gl_spirv work, we are doing the linking based on the > >> nir shader tha

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Mon, May 7, 2018 at 11:53 AM, Jason Ekstrand wrote: > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro > wrote: >> >> Hi Jason, >> >> as part of the ARB_gl_spirv work, we are doing the linking based on the >> nir shader that comes from spirv_to_nir. On some cases, >> nir_lower_wpos_ytransform

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Monday, May 7, 2018 8:53:34 AM PDT Jason Ekstrand wrote: > On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro > wrote: > > > Hi Jason, > > > > as part of the ARB_gl_spirv work, we are doing the linking based on the > > nir shader that comes from spirv_to_nir. On some cases, > > nir_lower_wpos_y

Re: [Mesa-dev] A question about nir_lower_wpos_ytransform

On Mon, May 7, 2018 at 8:02 AM, Alejandro Piñeiro wrote: > Hi Jason, > > as part of the ARB_gl_spirv work, we are doing the linking based on the > nir shader that comes from spirv_to_nir. On some cases, > nir_lower_wpos_ytransform introduces a new uniform, > "gl_FbWposYTransform". So as the unifo

Re: [Mesa-dev] Question about NIR changes since mesa 17.3

On 31/03/18 00:43, Qiang Yu wrote: Hi guys, I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes in 18.0 will always do nir_lower_io_to_scalar_early() for the output of vertex shader and input of fragment shader. My first question is: Is it for the link

[Mesa-dev] Question about NIR changes since mesa 17.3

Hi guys, I'm rebasing the mesa-lima code from 17.3 to 18.0 and found the NIR changes in 18.0 will always do nir_lower_io_to_scalar_early() for the output of vertex shader and input of fragment shader. My first question is: Is it for the link time optimization that we can drop un-used channel

Re: [Mesa-dev] Question about min_index/max_index calculation

On Mon, Mar 26, 2018 at 6:39 PM, Erico Nunes wrote: > Thanks all for the input. > > I don't have an in-depth knowledge of the hardware either, though as > far as we can see the hardware does expect that we pass min_index in > the command stream. max_index is used to calculate the sizes in other >

Re: [Mesa-dev] Question about min_index/max_index calculation

Thanks all for the input. I don't have an in-depth knowledge of the hardware either, though as far as we can see the hardware does expect that we pass min_index in the command stream. max_index is used to calculate the sizes in other command stream fields (which is not the same as pipe_draw_info.c

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 6:00 PM, Jason Ekstrand wrote: > On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák wrote: >> >> On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott >> wrote: >>> >>> If Gallium was being lazy and not >>> specifying the bounds for internal shaders, that needs to be fixed for >>> the

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 2:27 PM, Marek Olšák wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott > wrote: > >> If Gallium was being lazy and not >> specifying the bounds for internal shaders, that needs to be fixed for >> the HW to work properly. >> > > I don't understand the sentence. Shade

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 5:27 PM, Marek Olšák wrote: > On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott > wrote: > >> If Gallium was being lazy and not >> specifying the bounds for internal shaders, that needs to be fixed for >> the HW to work properly. >> > > I don't understand the sentence. Shade

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 24, 2018 at 1:36 PM, Connor Abbott wrote: > If Gallium was being lazy and not > specifying the bounds for internal shaders, that needs to be fixed for > the HW to work properly. > I don't understand the sentence. Shaders don't interact with vertex indices. I also don't like the word

Re: [Mesa-dev] Question about min_index/max_index calculation

My understanding is that unlike most other architectures, Mali does vertex shading on every vertex up-front, completely ignoring the index buffer. Primitive assembly and tile binning happen after every vertex is transformed. There is no cache of transformed vertices. Utgard also only supports GLES2

Re: [Mesa-dev] Question about min_index/max_index calculation

The index bounds are computed only when they are needed for uploading vertices that are passed via a CPU pointer (user_buffer). In all other cases, computing the index bounds has a performance cost, which can be very significant. If you rely on u_vbuf to upload vertices for you, you shouldn't need

Re: [Mesa-dev] Question about min_index/max_index calculation

On Sat, Mar 17, 2018 at 2:12 PM, Erico Nunes wrote: > Hi all, > > I have been working to add indexed drawing/glDrawElements support to > the mesa-lima driver currently in development > (https://github.com/yuq/mesa-lima). > For that implementation, it seems that we need to have the minimum and > ma

[Mesa-dev] Question about min_index/max_index calculation

Hi all, I have been working to add indexed drawing/glDrawElements support to the mesa-lima driver currently in development (https://github.com/yuq/mesa-lima). For that implementation, it seems that we need to have the minimum and maximum index values from the index buffer available in order to set

[Mesa-dev] Question: Underutilization of GPU in certain benchmarks - Bug or Feature ?

Hi all, while looking for problems with NIR, I noticed that in the Bioshock Infinite and also Dirt Rallye Benchmark there are times when GPU shader utilization drops to 80% (Bioshock) or 60% (Dirt Rallye). In Bioshock this directly associated with fps drops, in Dirt Rallye it is not so obvious bu

Re: [Mesa-dev] Patch submit question

It’s a commit that needs to be slightly different in master and 18.0, hence 2x the # of commits. Thanks for the 662cff8f pointer. Perfect example! George > On Feb 26, 2018, at 4:14 PM, Emil Velikov wrote: > > On 26 February 2018 at 20:18, Kyriazis, George > wrote: >> Thanks Jordan, >> >>

Re: [Mesa-dev] Patch submit question

On 26 February 2018 at 20:18, Kyriazis, George wrote: > Thanks Jordan, > > Since I won’t be checking this in to mesa master, what do I need to do to > actually push it to the stable branch, after I get a review on mesa-dev? > When possible, please refrain from pushing to the stable branch. If th

Re: [Mesa-dev] Patch submit question

gt;> Hello mesa-dev, >> >> I have a quick patch submission question: >> >> I have a patch that I’d like to also nominate to mesa-stable >> (specifically 18.0.1 or 18.0.2), however the same patch is different >> between master and stable branches, due

Re: [Mesa-dev] Patch submit question

On 2018-02-23 13:20:21, Kyriazis, George wrote: > Hello mesa-dev, > > I have a quick patch submission question: > > I have a patch that I’d like to also nominate to mesa-stable > (specifically 18.0.1 or 18.0.2), however the same patch is different > between master and st

[Mesa-dev] Patch submit question

Hello mesa-dev, I have a quick patch submission question: I have a patch that I’d like to also nominate to mesa-stable (specifically 18.0.1 or 18.0.2), however the same patch is different between master and stable branches, due to neighboring code having changed in the meantime. What’s the

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On 30.08.2017 16:44, Rob Clark wrote: On Wed, Aug 30, 2017 at 10:18 AM, Qiang Yu wrote: On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: btw, does lima have some way to write to memory from cmdstream (ie. without setting up a full blown draw

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 10:18 AM, Qiang Yu wrote: > On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: >> On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: btw, does lima have some way to write to memory from cmdstream (ie. without setting up a full blown draw)? If so perhaps you could

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 9:03 PM, Rob Clark wrote: > On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: >>> btw, does lima have some way to write to memory from cmdstream (ie. >>> without setting up a full blown draw)? If so perhaps you could get >>> away with leaving some extra space at the end of

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Wed, Aug 30, 2017 at 3:26 AM, Qiang Yu wrote: >> btw, does lima have some way to write to memory from cmdstream (ie. >> without setting up a full blown draw)? If so perhaps you could get >> away with leaving some extra space at the end of your uniform buffer >> that you copy driver internal un

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

> btw, does lima have some way to write to memory from cmdstream (ie. > without setting up a full blown draw)? If so perhaps you could get > away with leaving some extra space at the end of your uniform buffer > that you copy driver internal uniforms into before kicking the draw? Unfortunately lim

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

> In my case, VC4 has lots of custom state-dependent uniforms, and uniform > upload is where we spend most of our CPU time (basically each draw call > needs to re-upload the uniform stream, and the stream has to be in the > order they will be used by instructions, rather than where they appear > in

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

Thanks Kenneth, here attach my RFC prototype patch implementing these, and comments follows. >> When working on lima gp compiler, I come across two problems about >> inserting extra uniform >> and instructions in nir for the driver and don't know where's the >> right place to do it. So I'd like >>

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Sat, Aug 26, 2017 at 9:40 AM, Qiang Yu wrote: > Hi guys, > > When working on lima gp compiler, I come across two problems about > inserting extra uniform > and instructions in nir for the driver and don't know where's the > right place to do it. So I'd like > to hear your opinion and if there's

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

Kenneth Graunke writes: > [ Unknown signature status ] > On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote: >> Hi guys, >> >> When working on lima gp compiler, I come across two problems about >> inserting extra uniform >> and instructions in nir for the driver and don't know where's th

Re: [Mesa-dev] Question about implementing viewport transfer and const load in nir

On Saturday, August 26, 2017 6:40:14 AM PDT Qiang Yu wrote: > Hi guys, > > When working on lima gp compiler, I come across two problems about > inserting extra uniform > and instructions in nir for the driver and don't know where's the > right place to do it. So I'd like > to hear your opinion and

[Mesa-dev] Question about implementing viewport transfer and const load in nir

Hi guys, When working on lima gp compiler, I come across two problems about inserting extra uniform and instructions in nir for the driver and don't know where's the right place to do it. So I'd like to hear your opinion and if there's other driver already did so. 1. viewport transfer lima gp nee

Re: [Mesa-dev] Question for nir lower load uniform to scalar

On Sat, Aug 26, 2017 at 3:07 AM, Eric Anholt wrote: > Qiang Yu writes: > >> Hi Eric, >> >> I'm working on lima gp compiler which should benefit from nir lowering >> uniform load to scalar. >> I notice you write the nir_lower_io_to_scalar.c which support lowering >> shader_in/shader_out >> but lef

Re: [Mesa-dev] Question for nir lower load uniform to scalar

On August 25, 2017 12:14:20 PM Eric Anholt wrote: Qiang Yu writes: Hi Eric, I'm working on lima gp compiler which should benefit from nir lowering uniform load to scalar. I notice you write the nir_lower_io_to_scalar.c which support lowering shader_in/shader_out but left the uniform lowerin

Re: [Mesa-dev] Question for nir lower load uniform to scalar

Qiang Yu writes: > Hi Eric, > > I'm working on lima gp compiler which should benefit from nir lowering > uniform load to scalar. > I notice you write the nir_lower_io_to_scalar.c which support lowering > shader_in/shader_out > but left the uniform lowering in vc4 driver, any reason why not > impl

  1   2   3   >