search for: ubo

Hey guys, I'm using the dolphin emulator from time and the stable version works reasonable well with current nvidia cards and nouveau.The git version got an overhaul however and now uses opengl3 and ubos (without ubo it uses a glUniform fallback). The ubo support works with the blobs. There are probably a few bugs with ubo one might be because of ubo access+offset (glBindBufferRange) as this is uncommon, there are no piglit tests. I use the linux kernel from git and mesa from git (last time I com...

https://bugs.freedesktop.org/show_bug.cgi?id=67215 Priority: medium Bug ID: 67215 Assignee: nouveau at lists.freedesktop.org Summary: UBO access seems to mask address on nouveau Severity: normal Classification: Unclassified OS: Linux (All) Reporter: wickmarkus at web.de Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/nouveau...

Thomas, OK, thanks for the update. I don't have a working machine with NV graphics that supports UBOs. Could you compile and run a test program for me if I wrote it? Though it may appear to not work for UBO offsets other than 0, there may be another pattern here, such as multiple of page size or something crazy like that. If we can find more information, it may help other developers. Patrick On...

The hardware allows multiple simultaneous renders with the same memory-backed constbufs but with each invocation having different values. However in order for that to work, the data has to be streamed in via the right constbuf slot. We weren't doing that for UBOs. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2 10.1" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_context.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c b/src/...

...sx2_GSReplayL nouveau_dri.so nvc0_validate_buffers My understanding of the code is that every time we switch a shader program, a full SSBO bind/validation is called. nvc0_set_shader_buffers will dirty buffer state (NVC0_NEW_3D_BUFFERS). The trick is that my application doesn't use SSBO (only UBO). Is it expected to call SSBO validation code when the shader program doesn't use them? If not, a validation shortcut will be nice. If it can help, here the backtrace from nvc0_set_shader_buffers #0 nvc0_set_shader_buffers (pipe=0x87c51e0, shader=0, start=16, nr=16, buffers=0x0) at nvc0/nvc...

Oh and just for the sake of completeness the problem occurs in the form of wrongly rendered textures in front of a black screen. The objects only are fusible for a second and them disappear sometimes they appear at the wrong position or are rotated. If you compile dolphin with GLEW_ARB_uniform_buffer_object replaced with false in Source/Plugins/Plugin_VideoOGL/Src/Render.cpp the problems won't

I myself am not that well-versed in c and opengl - especially opengl - I can read and write basic c code but that's my limit. The problem only appears when using an offset that's not zero.If you want to debug the issue you could very well use the dolphin-emu and apitrace. You can find one apitrace here http://markus.members.selfnet.de/dolphin/dolphin-emu.trace (~48M) The only 2 reasons I

...|(GPC0/TPC0/MP trap: |MEM_OUT_OF_BOUNDS) |MULTIPLE_WARP_ERRORS | |MEM_OUT_OF_BOUNDS) --- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> --- Those errors are most likely to happen when e.g. you're accessing a UBO out of its bounds. Or if the driver messed up binding said UBO... or some code generation error. However it should be ~harmless, except for the fact that the render in question will be messed up. BTW, what mesa version are you using? The DISP errors at the end are the reason (or at least a demons...

...e MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g. UBO-s) may differ per implementation. The uploading of kernel > parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers > to use an access mechanism for parameter reads which matches with the > upload method. > > Signed-off-by: Hans de Goede <hdegoede at redh...

...ey(keyC, draw = TRUE, vp = viewport(.75, .9)) trellis.focus("panel", 3, 1) ; draw.key(keyF, draw = TRUE, vp = viewport(.75, .9)) trellis.focus("panel", 4, 1) ; draw.key(keyS, draw = TRUE, vp = viewport(.75, .9)) trellis.unfocus() -- Luis Tito de Morais IRD - UMR LEMAR (IRD/UBO/CNRS/IFREMER) Tél. : +33 2 98 49 86 35 Mob. : +33 6 37 67 21 40 Courriel-1 : Luis.Tito-de-Morais@ird.fr Courriel-2 : Luis.Titodemorais@univ-brest.fr Pages web : Lab. : http://www-iuem.univ-brest.fr/UMR6539/recherche/equipe-5 Pers. : http://ird.academia.edu/LuisTitodeMorais Reshal : http://www.ne...

...t to differentiate between global, local >> and shared memory, as well as "input" memory. >> >> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a >> special memory type is added for this, since the actual storage of these >> (e.g. UBO-s) may differ per implementation. The uploading of kernel >> parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers >> to use an access mechanism for parameter reads which matches with the >> upload method. >> >> Signed-off-by: Hans de Goede...

...ent rights, .. Depening on you needs.. > My suggestion, re-read. > > https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs > And > https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles > > Greetz, > > Louis > > > > > > > -- UBO <http://www.univ-brest.fr>

..., I > get this: > > root at testsmb:~# ls -la /home/data/test.txt > -rwxrwxr-x+ 1 giduser domain users 0 Feb 6 13:48 /home/data/test.txt > > It looks like the Samba tools ignore 'idmap config SAMDOM : > unix_primary_group = yes' > > Rowland > > > -- UBO <http://www.univ-brest.fr>

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

Hi Ilia and Samuel, I rebased my mesa git tree today (it was getting a bit stale) and after that src/gallium/tests/trivial/compute.c stopped working as well as any opencl programs with the kernel in TGSI (as clover on nouveau currently only supports having the kernel in TGSI). The problem is that RES no longer is a valid register-file name in TGSI, specifically this is caused by this commit:

> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Rowland Penny via samba > Verzonden: woensdag 6 februari 2019 16:33 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] unix_primary_group = yes don t work > > On Wed, 6 Feb 2019 15:58:52 +0100 > L.P.H. van Belle <belle at bazuin.nl> wrote: > > > Hai

https://bugs.freedesktop.org/show_bug.cgi?id=91895 Bug ID: 91895 Summary: [nve7] Shadow Warrior: black gun & messed up colors Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

...seems like a nvidia implementation detail though, and we should IMHO > still > implement a specific TGSI register file for accessing kernel input params, > agreed ? I believe that kernel input params should be passed in via user uniforms. i.e. CONST. It doesn't have to be a separate UBO, it can use the user buffer thing, which is basically what it is now. > > If we can agree on the TGSI syntax for all this, then I'm pretty sure I can > hack > something together to get things to work with the latest master again, and > then we > can use this as a starting poi...

...t; > Can you try that. > > > > > >> Rowland > >> > >> -- > >> To unsubscribe from this list go to the following URL and read the > >> instructions: https://lists.samba.org/mailman/options/samba > >> > > > > -- > UBO <http://www.univ-brest.fr> > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >

...he log files show me that the Win 7 boxes use SMB2 protocol, and XP uses NTLM : is this normal ? (I thought XP could use SMB1, but maybe i'm wrong)... Any idea ? Or course I can show every piece of information you might need to resolve my issue... Thank you very much for your help... -- UBO <http://iut.univ-brest.fr>