similar to: nv50/gallium: a few patches, updated

I went through the gallium-nine tree and picked out nouveau patches that are general bug-fixes. The first bunch I'd like to also get into 10.2. I've reviewed all of them and they make sense to me, but sending them out for public review as well in case there are any objections. Unless I hear objections, I'd like to push this by Friday. Christoph Bumiller (11): nv50,nvc0: always pull

Just wanted to communicate some thoughts I had while reading the diffs, even thought I didn't have the time to look at everything in detail yet. - nv50: use relocs rather than re-uploading TIC all the time It's nice that we can write relocs to arbitrary buffers, and it's much less work than emitting the whole state object obviously. Just, you forgot the card won't care until you

On 21/05/14 00:39, Ilia Mirkin wrote: > From: Christoph Bumiller <e0425955 at student.tuwien.ac.at> > > [imirkin: add logic to also clear the "regular" scissors] Can you please share why are you've added the "regular" scissors ? Does it matter if we set the screen scissors before the render target params? Thanks Emil > Reviewed-by: Ilia Mirkin

Commit eb168e26aa63f11a47d70c4555cae30691a2cd57 changed the way pipe->clear works so I figured I'd try to make an updated version, so below is the diff - my concerns/uncertainties should be contained in the comments. Or maybe you want to do it the way NV40 does it, just calling surface_fill through a utility function (althoug this does currently seem to only clear one color buffer) .

Hi. There's not much to say here, just replacing the screen_init stateobj with direct pushbuffer emission. We don't need to store all the usless state from init, and the constant buffer relocations which currently don't work if the addresses change (because the method CB_DEF_SET isn't among them (not an address)) become effective. Thoughts, ack / nack ? Thanks, Christoph

On Wed, May 21, 2014 at 2:57 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > On 21/05/14 00:39, Ilia Mirkin wrote: >> From: Christoph Bumiller <e0425955 at student.tuwien.ac.at> >> >> [imirkin: add logic to also clear the "regular" scissors] > Can you please share why are you've added the "regular" scissors ? Because I had to

From: Christoph Bumiller <e0425955 at student.tuwien.ac.at> [imirkin: add logic to also clear the "regular" scissors] Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_surface.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git

--- src/gallium/drivers/nv50/nv50_program.c | 2 +- src/gallium/drivers/nv50/nv50_screen.c | 17 ++++++++--------- src/gallium/drivers/nv50/nv50_state_validate.c | 10 +++++----- src/gallium/drivers/nv50/nv50_transfer.c | 8 ++++---- src/gallium/drivers/nv50/nv50_vbo.c | 24 ++++++++++++------------ 5 files changed, 30 insertions(+), 31 deletions(-)

When trying out the Gallium3D NV50 driver (curiosity) with a small OpenGL program that renders 2 rotating triangles partially occluding each other I noticed that depth buffer clearing by rendering a quad (st_cb_clear.c/clear_with_quad) didn't work properly. I found this was because the rasterizer state that is set by clear_with_quad has bypass_vs_clip_and_viewport = 1 which would only be

http://bugs.freedesktop.org/show_bug.cgi?id=23291 Summary: A slight problem in the NV50 nouveau driver in Mesa Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org

Hi ! Here are some more changes to the shader code to be applied in addition to the previous ones. Well, I've though about getting an account so I could commit some (or all) of this stuff, probably in splitting some patches up a bit more. But I'd feel much better doing so (if I was even allowed to) if someone (darktama) had a look at my code before, preferably with some comments on how to

On 17/01/14 02:23, Ilia Mirkin wrote: > This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers > as specified by glDrawBuffers). > > This implementation is highly based on a larger commit by > Christoph Bumiller <e0425955 at student.tuwien.ac.at> in his gallium-nine > branch. > Ilia, Do you know why we cannot set the rt height to 64? After all you

A little patch that makes the nv50 mesa driver use the correct GPU values for the matching depth formats. There doesn't seem to be Z16, but I added Z32_FLOAT to show the tile_flags the various formats need in the page tables. There'd also be Z32_FLOAT_S8_UNORM (0x19, tile flags 0xe000), but that's not yet defined in the pipe formats header, and I actually don't know if it's

We need to invert the viewport translate/scale parameters when the state tracker thinks we have Y_0_TOP. If these cases, we have do to bypass mode by setting an identity viewport transform for x, z and inversion for y, or p.e. clear_with_quad won't work correctly. Clipping for xy in NDC space needs to be disabled then. --- src/gallium/drivers/nv50/nv50_context.h | 1 +

Here's the new and better version of the shader patches I sent some time ago, including some (hopefully) improvements. I'm probably going to push them next week after pondering them for a while longer, if there are no complaints. I considered just committing them right away, but well, I'm sending them here just in case ... There's one quite large patch I considered splitting up

This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers as specified by glDrawBuffers). This implementation is highly based on a larger commit by Christoph Bumiller <e0425955 at student.tuwien.ac.at> in his gallium-nine branch. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv50/nv50_defs.xml.h | 1 +

On Thu, Jan 23, 2014 at 2:40 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > On 17/01/14 02:23, Ilia Mirkin wrote: >> This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers >> as specified by glDrawBuffers). >> >> This implementation is highly based on a larger commit by >> Christoph Bumiller <e0425955 at student.tuwien.ac.at>

https://bugs.freedesktop.org/show_bug.cgi?id=61854 Priority: medium Bug ID: 61854 Assignee: nouveau at lists.freedesktop.org Summary: [nv50]glClipPlane not clipping correctly for glsl Severity: normal Classification: Unclassified OS: Linux (All) Reporter: bill at taniwha.org Hardware: x86-64 (AMD64)

ping On Fri, Oct 4, 2013 at 4:32 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > This CAP will determine whether ARB_framebuffer_object can be enabled. > The nv30 driver does not allow mixing swizzled and linear zsbuf/cbuf > textures. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/gallium/docs/source/screen.rst | 3 +++ >

This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers as specified by glDrawBuffers). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not sure whether something needs to be done to clear out the old RT_* settings for that index buffer, or if things are cleared out implicitly. Perhaps instead of skipping indices, RT_CONTROL needs to be adjusted with the