similar to: Textures Twiddling/Swizzling

Hi guys again. A homebrew developer (homebrew is custom software made for the switch using openGL under nouveau) reported to me that 'glGenerateMipmap' wasn't working on yuzu (Nintendo Switch emulator). I looked into it and I noticed all the triangle data used by nouveau to render the mipmaps was all zeroed out, meaning that probably we don't implement the mechanism you guys use to

Different textures may be bound to each slot for each stage. So we need to be able to upload ms parameters for each one without stages overwriting each other. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1 10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 4 ++++

I've been googling and searching the mailing list, and I think this is a new issue. I just tried copying a kernel source tree, using this command rsync -avz linux-2.6.16.29/. yuzu:/usr/src/linux-2.6.16.29/ I also tried adding this option: --include=".*" but in both cases, the .config file was not copied over. It seems that rsync is copying hidden directories but not hidden

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- All the arb_texture_cube_map_array piglits pass except the sampler-cube-shadow one. However, nva0+ appear to all fail at the non-array version of that test, sampler-cube-shadow, so I think it's very likely to be related. Probably some sampler setup bits changed. src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 5

This one maps textures to sampler units (or textures to texture units or whatever it's called), which wasn't done before. It should make the mesa demo "multiarb" work, at least with the shader patches I sent earlier. Of course, with this functionality one probably wouldn't have to setup the textures in NV50_TIC anew every time, but that can be optimized later.

So I have been implementing syncing mechanisms to yuzu's switch emulator, aka Tegra X1 emulation and I already have: Semaphores, Syncpoints and Queries to some extent. I'm missing the barriers (GPU waits for CPU): I got this from RE: Barrier mode has priority (from highest to lowest): 1) 0x08 sets needsWfi=0 -> highest priority, does puller refcnt + split(0,0) + 0x100 NoOperation + rest

I'm currently implementing mipmaps but I have a set of troubles guessing the block height and block depth of them. According to https://envytools.readthedocs.io/en/latest/hw/memory/g80-surface.html#textures-mipmapping-and-arrays the texture unit auto resizes mipmaps' blocks but how do I know how many blocks each one uses? I'm currently using this algorithm: u32 height =

Hey, as some of you may know we're in process of experimenting with LLVM in Gallium3D (Mesa's new driver model), where LLVM would be used both in the software only (by just JIT executing shaders) and hardware (drivers will implement LLVM code-generators) cases. While the software only case is pretty straight forward I just realized I missed something in my initial evaluation. That

So I have been going on over the documentation trying to figure out the exact layout of Pitch Linear Textures and find some missing values. First Question: What's the correct layout of pitch linear textures in memory? Is padding of the pitch added at start or at the end? Do they have some kind of header? Currently I see them as a normal texture matrix with just pitch at the end of each row

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- These look like pretty obvious typos. The x |= read; x &= ~write; (or vice-versa) pattern occurs in nvc0, so I'm guessing that this is what was intended here as well. Not sure if this fixes anything in particular though. src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 4 ++--

On Thu, 27 Sep 2007, Zack Rusin wrote: > as some of you may know we're in process of experimenting with LLVM in > Gallium3D (Mesa's new driver model), where LLVM would be used both in the > software only (by just JIT executing shaders) and hardware (drivers will > implement LLVM code-generators) cases. Yep, nifty! > That is graphics hardware (basically every single

Hi, On 08-04-16 17:02, Ilia Mirkin wrote: > On Fri, Apr 8, 2016 at 5:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 07-04-16 15:58, Ilia Mirkin wrote: >>> >>> That's wrong. >> >> >> It used to work with the old RES[] code and if one cannot specify >> a source swizzle, then how can I do something like

Add proper flushes for TIC and TSC and remove the costly 2D.0110 flush in nv50_flush. Correct TIC and TSC bo sizes. --- src/gallium/drivers/nv50/nv50_context.c | 7 --- src/gallium/drivers/nv50/nv50_context.h | 5 ++ src/gallium/drivers/nv50/nv50_screen.c | 25 ++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 53 +++++++++++++++++++++---

Hi guys how are you doing? I have some questions on how the GPU handles syncpoints from the commandlist. I do know the register 0xB2 is the one written in the Maxwell3D Engine. As far as I know bits 0:15 are the syncpoint id, bit 16 is unknown for me, bit 20 is increment? What other bits are set and what should be done on increment? Thanks in advance. -------------- next part -------------- An

Hi, On 08-04-16 17:45, Ilia Mirkin wrote: > On Fri, Apr 8, 2016 at 11:28 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> When dealing with non vector variables the llvm register allocator >> will use TEMP[0].x then TEMP[0].y, etc. >> >> When loading something from a global buffer it will calculate the >> address to use, and store that in say TEMP[0].x,

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

Hi, On 07-04-16 15:58, Ilia Mirkin wrote: > That's wrong. It used to work with the old RES[] code and if one cannot specify a source swizzle, then how can I do something like LOAD TEMP[0].y, MEMORY[0], address And get the data at absolute global memory address "address" into TEMP[0].y ? This is a must-have for llvm to be able to generate working TGSI code, I do not see any

Hello, I got some doubts on how texture modes work on TEX, TEXS, TLD4, etc instructions. I got: DC, AOFFI, NDV, NODEP, MZ, PTP modes as well as LZ Mode. How does this work or change the behavior of the texture instruction. So far of those I know AOFFI defines an Offset but I'm on blanks for the rest. -------------- next part -------------- An HTML attachment was scrubbed... URL:

13:28 < pmdata> ymanton> We have a bit more work to do for 8 bits texture. 13:28 < pmdata> Swizzling works by halving dimensions, and using a8r8g8b8 as format as seen in dumps for test_texture_format. 13:28 < pmdata> I nearly got text in progs/demos/texenv: http://people.freedesktop.org/~pmandin/20091011.png 13:28 < pmdata> My current

The llvm TGSI backend does things like: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be loaded instead. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++-- 1 file changed,