similar to: NV50 compute support questions

Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: > > > On 11/20/2015 11:36 AM, Hans de Goede wrote: >> Hi Samual, et al, > > Hi Hans, > >> >> In >> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd >> >> you write: "This compute support has been tested by >> Pierre

Hi, On 26-11-15 09:42, Samuel Pitoiset wrote: > Well, if you remove that assert locally, all compute tests in src/gallium/tests/trivial/compute.c pass on GK106, except the atomic ones. Do you mean the: Assertion `pres->target != PIPE_BUFFER' failed. or the: Assertion `tex->defExists(0) && tex->srcExists(0)' failed. assert? Or is the first one not present for

Well, if you remove that assert locally, all compute tests in src/gallium/tests/trivial/compute.c pass on GK106, except the atomic ones. I'm working on the fermi case btw. On 11/25/2015 03:43 PM, Hans de Goede wrote: > Hi, > > On 20-11-15 17:07, Samuel Pitoiset wrote: >> >> >> On 11/20/2015 11:36 AM, Hans de Goede wrote: >>> Hi Samual, et al, >>

On 11/26/2015 01:21 PM, Hans de Goede wrote: > Hi, > > On 26-11-15 09:42, Samuel Pitoiset wrote: >> Well, if you remove that assert locally, all compute tests in >> src/gallium/tests/trivial/compute.c pass on GK106, except the atomic >> ones. > > Do you mean the: > > Assertion `pres->target != PIPE_BUFFER' failed. > > or the: > >

On 11/25/2015 03:43 PM, Hans de Goede wrote: > Hi, > > On 20-11-15 17:07, Samuel Pitoiset wrote: >> >> >> On 11/20/2015 11:36 AM, Hans de Goede wrote: >>> Hi Samual, et al, >> >> Hi Hans, >> >>> >>> In >>>

tgsi_default_instruction_memory / tgsi_build_instruction_memory were returning uninitialized memory for tgsi_instruction_memory.Texture and tgsi_instruction_memory.Format. Note 0 means not set, and thus is a correct default initializer for these. Fixes: 3243b6fc97 ("tgsi: add Texture and Format to tgsi_instruction_memory") Cc: Nicolai Hähnle <nicolai.haehnle at amd.com>

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 66 +++++++++++++++++++++- 1 file changed, 63 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp index dfb093c..e38a3b8 100644 ---

https://bugs.freedesktop.org/show_bug.cgi?id=111217 Bug ID: 111217 Summary: compilation of vdpau shaders crashes in handleCVT_CVT Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee:

This lets us spill more values and compile a big shader for Civilization 6. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp index b33d7b4010..f29c8a1a95

This shortens runtime of piglit test fp-long-alu to ~22s No piglit regressions observed on nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++--- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 7 ++++--- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-

Hi, On 14-03-16 16:05, Ilia Mirkin wrote: > There's a less hacky and more hacky way forward. The more hacky solution is > to set file index to -1 or something and then not do the lowering when you > see that. > > The less hacky solution is the one you proposed as #1 - introduce a new > file for "buffer" memory and lower it to the global file by adding a base >

Hi, On 14-03-16 16:41, Samuel Pitoiset wrote: > > > On 03/14/2016 04:28 PM, Hans de Goede wrote: >> Hi, >> >> On 14-03-16 16:05, Ilia Mirkin wrote: >>> There's a less hacky and more hacky way forward. The more hacky >>> solution is >>> to set file index to -1 or something and then not do the lowering when >>> you >>> see

This little "hack" fixes the use of OpenCL global memory buffers with nouveau, but clearly the #if 0 is not a solution as it breaks buffers with GLSL. The reason I'm posting this as an RFC patch is to discuss how to solve this properly, 2 solutions come to mind: 1) Use separate nv50_ir::FILE_MEMORY_xxx values for buffers versus TGSI_FILE_MEMORY with TGSI_MEMORY_TYPE_GLOBAL,

Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise modifiers on variables inside Nouveau. This series add precise/invariant handling to TGSI, which can be then used by drivers to disable certain unsafe optimisations which may otherwise alter calculations, which depend on having the same result across shaders. This series fixes this bug in Tomb Raider and one CTS test

OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work

This looks like the right idea to me too. It may sound a bit weird to do that per instruction, but d3d11 does that as well. (Some d3d versions just have a global flag basically forbidding or allowing any such fast math optimizations in the assembly, but I'm not actually sure everybody honors that without tesselation...) For 1/9: Reviewed-by: Roland Scheidegger <sroland at vmware.com>

This is enough to enable tessellation support on nvc0. It seems to work a lot better on my GF108 than GK208. I suspect that there's some sort of scheduling shenanigans that need to be adjusted for kepler+. Or perhaps some shader header things. Even with the GF108, I still get occasional blue triangles in Heaven, but I get a *ton* of them on the GK208 -- seemingly the same issue, but it's

Although I'm sending this as a GSoC proposal, I'm well aware that the amount of work that a project of this kind involves largely exceeds the scope of the GSoC program. I think that's okay: my work here wouldn't be finished at the end of this summer by any means, it would merely be a start. TGSI is the intermediate representation that all open-source GPU drivers using the

https://bugs.freedesktop.org/show_bug.cgi?id=79462 Priority: medium Bug ID: 79462 Assignee: nouveau at lists.freedesktop.org Summary: [NVC0/Codegen] Shader compilation falis in spill logic Severity: normal Classification: Unclassified OS: All Reporter: imirkin at alum.mit.edu Hardware: Other

Francisco Jerez <currojerez at riseup.net> writes: >[...] > Pity not to see any interest in this since I brought up the idea two > weeks ago. I've uploaded a first attempt at writing a TGSI back-end > here [2]. It's able to generate code -- though only in assembly form > and with many loose ends still. > > Also, would it be possible for Tom Stellard