Re: [Mesa-dev] How do people feel about D3D in piglit?
On Tue, Nov 19, 2019 at 8:26 AM Jason Ekstrand wrote: > > Ok, that's a bit of a weird click-bait title but it's descriptive. One of > the things that we really need to get tested in piglit is the GL <-> Vulkan > interop extensions. The Vulkan bits are implemented in ANV and RADV and the > GL bit is implemented in radeonsi but we don't have a good test plan at the > moment. Because any such tests necessarily go across APIs, they can't really > be put into the Vulkan CTS or the OpenGL CTS. This makes piglit the natural > place to put such tests. > > Ok, back to my question at the top. Let's say that someone wants to use said > piglit tests on Windows. In that case, they really need to be able to test > Vulkan <-> D3D11 interop as well as Vulkan <-> GL. One could imagine, for > instance, that maybe DXVK would like to implement such interop on top of > Vulkan <-> Vulkan interop in which case they would need tests. > > So, does anyone have a major problem with Piglit linking against D3D APIs > when built on Windows? I'm happy if it has to sit behind a flag. Sounds like the right place to me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] How do people feel about D3D in piglit?
Ok, that's a bit of a weird click-bait title but it's descriptive. One of the things that we really need to get tested in piglit is the GL <-> Vulkan interop extensions. The Vulkan bits are implemented in ANV and RADV and the GL bit is implemented in radeonsi but we don't have a good test plan at the moment. Because any such tests necessarily go across APIs, they can't really be put into the Vulkan CTS or the OpenGL CTS. This makes piglit the natural place to put such tests. Ok, back to my question at the top. Let's say that someone wants to use said piglit tests on Windows. In that case, they really need to be able to test Vulkan <-> D3D11 interop as well as Vulkan <-> GL. One could imagine, for instance, that maybe DXVK would like to implement such interop on top of Vulkan <-> Vulkan interop in which case they would need tests. So, does anyone have a major problem with Piglit linking against D3D APIs when built on Windows? I'm happy if it has to sit behind a flag. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: add missing rollback of URB requirements
On Tue, Jan 8, 2019 at 11:01 PM Chris Wilson wrote: > Quoting Kenneth Graunke (2019-01-08 20:17:01) > > On Tuesday, January 8, 2019 3:11:37 AM PST Chris Wilson wrote: > > > Quoting Lionel Landwerlin (2019-01-08 11:03:26) > > > > Hi Andrii, > > > > > > > > Although I think what these patches do makes sense, I think it's > missing > > > > the bigger picture. > > > > There is a lot more state that gets lost if we have to revert all of > the > > > > emitted commands. > > > > A quick look at brw_upload_pipeline_state() shows all of the > programs > > > > could be invalid as well, or the number of samples, etc... > > > > > > > > To me it seems like we need a much larger state save/restore. > > > > > > > > Ken: what do you think? > > > > > > How about not rolling back? If we accept it as currently broken, and > just > > > demand the kernel provide logical contexts for all i965 devices (just > ack > > > some patches!), and then just flush the batch (possibly with a dummy 3D > > > prim if you want to be sure the 3D state is loaded) and rely on the > > > context preserving state across batches. > > > -Chris > > > > I'm not sure precisely what you're proposing, but every scenario I can > > think of is breaking in some subtle way. > > > > Option 1: Submit batch at last 3DPRIMITIVE, re-call emit in a new batch. > > > > This is what we do today; it doesn't work since brw_upload_render_state > > implicitly sets CPU-side fields for "current state of the GPU", which > > become inaccurate at rollback, so the next state upload would do the > > wrong thing. We'd need to roll all those back as well, or only commit > > them when we finish uploading state. Atoms also flag other new atoms, > > and that's not getting rolled back, but extra flagging is harmless. > > > > Fixing this means disentangling some of our code, saving and restoring > > more values, and so on. Maybe dropping a few CPU micro-optimizations. > > > > Option 2: Submit batch at last 3DPRIMITIVE (A), memcpy commands for > > for failing primitive (B) into a new batch. > > > > This doesn't work either. Let's say (A) issued a 3DSTATE_INDEX_BUFFER > > command with a pointer to the index buffer. (B) didn't change index > > buffer state, so it doesn't emit one, intending to reuse the old value. > > This with all relocs with BRW_NEW_BATCH, and iirc the rule is that they > are already tied into that BRW_NEW_BATCH flag. Except you don't need to > memcpy, since you already have the 3DSTATE equivalent to the cpu state > tracker in the batch, emit that, and it will be recorded in the context > for the next batch. (You just don't tell the kernel about the > buffers/relocs that cause the aperture exhaustion and it won't do > anything about them. The GPU may load stale addresses, but never uses > them, exactly like the context state on the next batch anyway.) > > It's not a great argument, but the argument is that there's less you > need to fixup, than having to remember to every single comparison in > order to rollback the cpu state tracker. > -Chris > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > So, have we a plan as to it? This patch was sent 1 year ago and I almost forgot it. Maybe it was fixed by somebody and this patch can be just rejected/closed) - Andrii ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 109461, which changed state. Bug 109461 Summary: [amdgpu/radeonsi,HAWAII] Hand of Fate 2 leads to GPU lock up (display powered off, SSH works, keyboard dead): "flip_done timed out" https://bugs.freedesktop.org/show_bug.cgi?id=109461 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 57719] Testing Bugzilla security group
https://bugs.freedesktop.org/show_bug.cgi?id=57719 Daniel Stone changed: What|Removed |Added Group|Mesa Security | -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 74973, which changed state. Bug 74973 Summary: [radeonsi] Gimp OpenCL does not work https://bugs.freedesktop.org/show_bug.cgi?id=74973 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 74974, which changed state. Bug 74974 Summary: [radeonsi] x264 OpenCL does not work https://bugs.freedesktop.org/show_bug.cgi?id=74974 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
