search for: miptrees

http://bugs.freedesktop.org/show_bug.cgi?id=25440 Summary: PATCH: fixes conflicting miptree definitions Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org

I wrote a tool for automatically finding out the texture layout for Gallium drivers. You can find it attached to http://sourceforge.net/mailarchive/forum.php?thread_name=ff13bc9a1001081140y18450c3ejdfac25c9260fd367%40mail.gmail.com&forum_name=mesa3d-dev . Here are the findings from running it. The result is that our miptree layout code is partially broken, and overly complex. In particular:

The mt address is about to be used more, make sure it's set appropriately. Reported-by: Emil Velikov <emil.l.velikov at gmail.com> Tested-by: Emil Velikov <emil.l.velikov at gmail.com> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2 10.3" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv84_video.c | 2 ++ 1 file

Hello, I have been looking at cubic texture mapping for a bit, and I have found that hw mipmap generation doesn't work at all or the textures are all messed up (normal 2d work fine). This is with linear textures. Also of note is that software mipmap generation works fine. I have done sanity checks for the miptree pitches, offsets, etc and everything seems to match up fine for both the

...9b4a 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_resource.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_resource.c @@ -68,6 +68,8 @@ nv50_surface_create(struct pipe_context *pipe, struct pipe_resource *pres, const struct pipe_surface *templ) { + /* surfaces are assumed to be miptrees all over the place. */ + assert(pres->target != PIPE_BUFFER); if (unlikely(pres->target == PIPE_BUFFER)) return nv50_surface_from_buffer(pipe, pres, templ); return nv50_miptree_surface_new(pipe, pres, templ); diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c b/src/ga...

Changes: - Fixed some nv##_miptree that were not converted to nv04_miptree. - Disable swizzling on non-RGBA 2D textures, since the current 2D code is mostly broken in those cases. A later patch will fix this. Thanks to Andrew Randrianasulu who reported this. This patch rewrites all the miptree layout and transfer code in the pre-NV50 Gallium drivers. The code is also unified among them and

This patch rewrites all the miptree layout and transfer code in the pre-NV50 Gallium drivers. The code is also unified among them and put in the nv04 directory. The current code is broken in several ways: 1. 3D textures are laid out first by face, then by level, which is incorrect 2. Cube maps should have 128-byte aligned faces 3. Swizzled textures have a strange alignment test that seems

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

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.

This patch fixes two issues in nv40_miptree_layout. First, pt->width0 is used, which is the size of the whole texture, while width, which is the size of the mipmap level, should be used. Second, the current code does not 64-byte align the pitch of swizzled textures. However, on my NV40 this causes a pgraph error regarding the pitch register (and sometimes a system lockup too), which is fixed

The Wine development release 1.9.8 is now available. What's new in this release (see below for details): - More work towards the WineD3D command stream. - Bug fix update of the Mono engine. - More WebServices reader support. - Still more Shader Model 5 support. - Support for gradients in metafiles. - Improved table formatting in WinHelp. - Various bug fixes. The source is

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 +++++++++++++++++++++---

On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: > On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I

--- Hi, this is still WIP, but already passes piglit's s3tc-teximage, s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests) and even Wolfenstein:Enemy-Territory works on my nv25. It's based on Ben's newlib branch. I have few issues though: 1) So far it needs libtxc_dxtn, but I might expose the s3tc extensions even without encoder using driconf option - Is that desirable? 2)

Requesting a new real buffer from the kernel and copying all the data is wasteful e.g. if only a few (but widely spread) vertices are accessed. --- src/gallium/drivers/nv50/nv50_context.h | 3 + src/gallium/drivers/nv50/nv50_vbo.c | 409 +++++++++++++++++++++++++++++-- 2 files changed, 394 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nv50/nv50_context.h

..., argv=<optimized out>) at compute.c:1584 Which comes from the assert here: static struct pipe_surface * nvc0_surface_create(struct pipe_context *pipe, struct pipe_resource *pres, const struct pipe_surface *templ) { /* surfaces are assumed to be miptrees all over the place. */ assert(pres->target != PIPE_BUFFER); if (unlikely(pres->target == PIPE_BUFFER)) return nv50_surface_from_buffer(pipe, pres, templ); return nvc0_miptree_surface_new(pipe, pres, templ); } Just dropping that assert helps somewhat, it leads to: PIPE_COM...

...rom the assert here: >> >> static struct pipe_surface * >> nvc0_surface_create(struct pipe_context *pipe, >> struct pipe_resource *pres, >> const struct pipe_surface *templ) >> { >> /* surfaces are assumed to be miptrees all over the place. */ >> assert(pres->target != PIPE_BUFFER); >> if (unlikely(pres->target == PIPE_BUFFER)) >> return nv50_surface_from_buffer(pipe, pres, templ); >> return nvc0_miptree_surface_new(pipe, pres, templ); >> } >> >> Ju...

...1584 > > Which comes from the assert here: > > static struct pipe_surface * > nvc0_surface_create(struct pipe_context *pipe, > struct pipe_resource *pres, > const struct pipe_surface *templ) > { > /* surfaces are assumed to be miptrees all over the place. */ > assert(pres->target != PIPE_BUFFER); > if (unlikely(pres->target == PIPE_BUFFER)) > return nv50_surface_from_buffer(pipe, pres, templ); > return nvc0_miptree_surface_new(pipe, pres, templ); > } > > Just dropping that assert help...

...;> >>> static struct pipe_surface * >>> nvc0_surface_create(struct pipe_context *pipe, >>> struct pipe_resource *pres, >>> const struct pipe_surface *templ) >>> { >>> /* surfaces are assumed to be miptrees all over the place. */ >>> assert(pres->target != PIPE_BUFFER); >>> if (unlikely(pres->target == PIPE_BUFFER)) >>> return nv50_surface_from_buffer(pipe, pres, templ); >>> return nvc0_miptree_surface_new(pipe, pres, templ); >>> }...

...1584 > > Which comes from the assert here: > > static struct pipe_surface * > nvc0_surface_create(struct pipe_context *pipe, > struct pipe_resource *pres, > const struct pipe_surface *templ) > { > /* surfaces are assumed to be miptrees all over the place. */ > assert(pres->target != PIPE_BUFFER); > if (unlikely(pres->target == PIPE_BUFFER)) > return nv50_surface_from_buffer(pipe, pres, templ); > return nvc0_miptree_surface_new(pipe, pres, templ); > } > > Just dropping that assert help...