Re: [Mesa-dev] [PATCH 1/2] i965/brw: Emit state for hiz and separate stencil buffers
On 06/04/2011 04:29 PM, Chad Versace wrote: On 06/03/2011 03:33 PM, Kenneth Graunke wrote: Do we need to emit 3DSTATE_STENCIL_BUFFER with all 0's in the stencil_irb == NULL case? Ditto for HiZ I guess. Just being a bit paranoid. The test results for these paranoiac cases pass, so paranoia is unneeded. Regarding "Do we need to emit 3DSTATE_STENCIL_BUFFER with all 0's in the stencil_irb == NULL case", see tests: * hiz-depth-test-fbo-d24-s0 : column 6 * hiz-depth-stencil-fbo-d24-s0 : columns 3, 6 Regarding "Ditto for HiZ", the following test runs emit a stencil buffer but no hiz buffer: * hiz-stencil-test-fbo-d0-s8 : column 6 * hiz-stencil-read-fbo-d0-s8 : column 6 * hiz-depth-stencil-fbo-d0-s8 : column 6 Hrm. I was thinking of a slightly more elaborate case: Render to an FBO that has both depth and stencil...then render to another FBO that only has depth. The question is: would the old stencil buffer stay programmed and somehow get used. Although come to think of it, I think the "Separate Stencil Enable" bit in 3DSTATE_DEPTH_BUFFER ought to be sufficient. So it's probably okay. On your suggestion, I added this hunk to the patch. diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index 5dadb5b..f560bc3 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -169,6 +169,7 @@ translate_tex_format(gl_format mesa_format, return BRW_SURFACEFORMAT_L16_UNORM; case MESA_FORMAT_S8_Z24: + case MESA_FORMAT_X8_Z24: /* XXX: these different surface formats don't seem to * make any difference for shadow sampler/compares. */ Thanks! Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] intel: Define span functions for S8 renderbuffers
On 06/04/2011 04:34 PM, Chad Versace wrote: On 06/03/2011 03:36 PM, Kenneth Graunke wrote: On 06/03/2011 12:47 PM, Chad Versace wrote: Since the stencil buffer is interleaved, the generic Mesa renderbuffer accessors do not suffice. Custom span functions are necessary. Signed-off-by: Chad Versace I know you had done this with handwritten functions at one point, rather than using stenciltmp.h. Why the change, if you don't mind me asking? Either way is fine, of course. Before finalizing the patch, I decided to thoroughly inspect the macros-from-hell one more time, just to make sure that I didn't miss some necessary magic they did. And, I did miss some magic. The macros perform clipping on the span ranges. Rather than try to duplicate (likely incorrectly) the macros' clipping logic, I just bit the bullet and used them. Ah. :( Yeah, that seems wise. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] intel: Request DRI2 buffers for separate stencil and hiz
Just noticed two typos in comments. * Chad Versace : > --- a/src/mesa/drivers/dri/intel/intel_context.c > +++ b/src/mesa/drivers/dri/intel/intel_context.c (..) > +/** > + * \brief Verify that the X driver supports hiz and separate stencil. > + * > + * This implements the cleanup stage of the handshake described in the > + * comments for 'enum intel_dri2_has_hiz'. > + * > + * This should be called from intel_update_renderbuffers() after 1) the > + * DRIdrawable has been queried for its buffers via > DRI2GetBuffersWithFormat() > + * and 2) the DRM region of each returned DRIbuffer has been assigned to the > + * appropriate intel_renderbuffer. Futhermore, this should be called *only* Furthermore (..) > + /* > + * I don't know how to recover from the failure assertion below. > + * Rather than fail gradually and unexpectedtly, we should just die unexpectedly Best regards, Nicolas Kaiser ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/10] i965: Implement hiz and separate stencil for window framebuffer
I have a naive question: why are we allocating stencil/depth/aux buffers through X/DRI2? I can understand for the sake of interoperability why the color buffer attachments are negotiated with X, but I can't see any reason why X wants to know about the others. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
Am Samstag, den 04.06.2011, 18:28 -0700 schrieb Jose Fonseca: > I think we need to have a proper review round of the gallium interfaces, so > that we have an interface > everybody feels that we can support going forward, which did not happen last > round. I agree to that, the interface was at least partly developed by looking at what a mpeg2 decoder needs, and not by using a more general concept. > That said, I don't think much attention has been given to this branch outside > from those working on it. > So those with constructive feedback should say now, or "forever hold your > peace". > Because one way or the other, it doesn't make sense to have useful code on a > branch. Some things look quite good and well defined, while others obviously needs some more love from a designer point of view. > Attached is the diff between pipe-video and master for src/gallium/include/* > > I need to look more closely at this, but I can't help thinking that the new > interfaces are quite different from the rest of gallium's 3d interfaces. > Instead of being an extension to gallium 3D interfaces/objects, pipe-video > seems more like a completely parallel set of interfaces/objects. > > - AFACIT all drivers implement pipe_video context using > vl_create_context(pipe_context *). > If so then it makes no sense for this to be a gallium interface. It should > all be state tracker code. Yes that's true, but as Younes already mentioned that design was on purpose. The whole idea behind it is to give the driver control over using either the shader/cpu based solution for a given video decoding stage, or implement their own stuff by using some sort of hardware acceleration. The shader based stages are then relying on the "normal" gallium 3D objects to do their work, and have itself a clearly defined interface. So it should be possible to: a) Let a driver decide how to implement a specific codec, for example you can use UVD for bitstream decoding, while still using shaders to do iDCT and MC. b) Reuse a specific stage to implement other codecs, iDCT for example is a well defined mathematical transformation and used in a couple of different codecs. This obviously could also need a bit of improvement, the stage interfaces for mc are for example still not free of mpeg2 specific stuff. > At very least there are ovious things that need to be fixed: > > - get_param / is_format_supported should not be duplicated from screen. I was also considering that when I started with coding, but right now I think renaming get_param into get_video_param and using an separate set of caps instead is the better way to go. For is_format_supported: I Think this should get the format/codec as parameter, instead of the format/usage used in the screen object. I've put this on my todo list. > - #if 0 ... #endif code in the interface headers Yes, I know, that's already on the todo list. > I'd also would like to see how generic these interfaces are (e.g. could we > use this to implement DXVA DDI). Damm, that's a good point. I only looked at vdpau/vaapi/xvmc while changing the interface design away from xvmc, but taking a look at DXVA could also be of value. Thanks for the feedback, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/02/2011 04:40 PM, Brian Paul wrote: > On 06/02/2011 03:18 PM, Benjamin Bellec wrote: >> It's me again, with a new minor optimization for the >> util_next_power_of_two() function. >> >> This patch implements a faster algorithm, still taken from Wikipedia ( >> http://en.wikipedia.org/wiki/Power_of_two#Algorithm_to_round_up_to_power_of_two >> >> ). >> But especially, I added the most common values used by this function. I >> noted that ETQW, TA Spring and ExtremeTuxRacer call often "good" values. >> I can think that most OpenGL apps uses also these values. >> >> I have benchmarked this. With -O2 optimization, this new function is >> twice faster than the former. Without GCC optimization the difference is >> even bigger. >> >> There is no piglit regressions. >> >> But there is an issue, during compilation there is an error (-Wall) >> "warning: right shift count>= width of type [enabled by default]". > > I'd like to avoid the warning if at all possible. If you replace (val >>> 32) with (val >> (sizeof(unsigned) * 4)) does that silence it? It will because it will evaluate to val >> 16, which is not what's wanted. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3rvi4ACgkQX1gOwKyEAw/MIACeKRGD0qTbeJUS61+jI60Isd0c reEAn0wGrU8eucE50RL3tV4+4Ul8kT7D =z1BM -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/10] i965: Implement hiz and separate stencil for window framebuffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/05/2011 02:44 AM, Chris Wilson wrote: > I have a naive question: why are we allocating stencil/depth/aux buffers > through X/DRI2? > > I can understand for the sake of interoperability why the color buffer > attachments are negotiated with X, but I can't see any reason why X > wants to know about the others. Because multiple processes can render to the same window, pbuffer, or pixmap, and they'll want the same set of buffers. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3rv8UACgkQX1gOwKyEAw+F5wCgjUAuyABkolANadSNngaKjjUo t2oAnjAltSzRiIYMXT+Xoad/FqscgOzd =++lE -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: add GALLIUM_AUXILIARIES to target dependencies
Without it changes to GALLIUM_AUXILIARIES don't induce target rebuild --- src/gallium/targets/Makefile.xorg |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/targets/Makefile.xorg b/src/gallium/targets/Makefile.xorg index 47040bb..6fad710 100644 --- a/src/gallium/targets/Makefile.xorg +++ b/src/gallium/targets/Makefile.xorg @@ -41,7 +41,7 @@ endif default: depend $(TOP)/$(LIB_DIR)/gallium $(LIBNAME) $(LIBNAME_STAGING) -$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) +$(LIBNAME): $(OBJECTS) Makefile ../Makefile.xorg $(LIBS) $(DRIVER_PIPES) $(GALLIUM_AUXILIARIES) $(MKLIB) -linker '$(CC)' -noprefix -o $@ $(LDFLAGS) $(OBJECTS) $(DRIVER_PIPES) $(GALLIUM_AUXILIARIES) $(DRIVER_LINKS) depend: $(C_SOURCES) $(CPP_SOURCES) $(ASM_SOURCES) $(SYMLINKS) $(GENERATED_SOURCES) -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xorg: initialize drm_mode.type
it's uninitialized, but used by kernel (drm_mode_setcrtc -> drm_mode_set_crtcinfo) --- src/gallium/state_trackers/xorg/xorg_crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xorg_crtc.c b/src/gallium/state_trackers/xorg/xorg_crtc.c index 0499ed1..22e61cf 100644 --- a/src/gallium/state_trackers/xorg/xorg_crtc.c +++ b/src/gallium/state_trackers/xorg/xorg_crtc.c @@ -122,6 +122,7 @@ crtc_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr mode, drm_mode.hskew = mode->HSkew; drm_mode.vscan = mode->VScan; drm_mode.vrefresh = mode->VRefresh; +drm_mode.type = 0; if (!mode->name) xf86SetModeDefaultName(mode); strncpy(drm_mode.name, mode->name, DRM_DISPLAY_MODE_LEN - 1); -- 1.7.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] xorg/nouveau: rename to nouveau2
On Mon, May 16, 2011 at 09:50:29PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/targets/xorg-nouveau/Makefile |2 +- > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 14 +++--- > 2 files changed, 8 insertions(+), 8 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: > Bail out early in probe, so other driver can take control of the card. > Doing it in screen_create would be too late. > --- > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 > ++- > 1 files changed, 35 insertions(+), 9 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t blend -f a8r8g8b8 -o Clear
On Mon, May 16, 2011 at 09:52:05PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/state_trackers/xorg/xorg_composite.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xorg: fix crash triggered by rendercheck -t composite -f a8r8g8b8 -o Src, Saturate
On Mon, May 16, 2011 at 09:52:47PM +0200, Marcin Slusarz wrote: > samplers[0] may remain uninititialized if src picture/pixmap is null > --- > src/gallium/state_trackers/xorg/xorg_composite.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: add \n to debug_checkpoint_full
On Mon, May 16, 2011 at 09:53:06PM +0200, Marcin Slusarz wrote: > > --- > src/gallium/auxiliary/util/u_debug.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz wrote: > On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: >> Bail out early in probe, so other driver can take control of the card. >> Doing it in screen_create would be too late. >> --- >> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 >> ++- >> 1 files changed, 35 insertions(+), 9 deletions(-) > > ping > Why do you need a list of cards for that, as opposed to reading the reg? Stéphane ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
2011/6/5 Stéphane Marchesin : > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz wrote: >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: >>> Bail out early in probe, so other driver can take control of the card. >>> Doing it in screen_create would be too late. >>> --- >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 >>> ++- >>> 1 files changed, 35 insertions(+), 9 deletions(-) >> >> ping >> > > Why do you need a list of cards for that, as opposed to reading the reg? > > Stéphane > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > I agree with Stephane, checking register 0 should work fine. First check for NV04/05, then for NV10-NV2F. Maarten. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
Wasn't nouveau targeted to provide HW acceleration for old cards like the TNT2, or has that idea been killed? Patrick On Sun, Jun 5, 2011 at 2:06 PM, Marcin Slusarz wrote: > On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: > > Bail out early in probe, so other driver can take control of the card. > > Doing it in screen_create would be too late. > > --- > > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 > ++- > > 1 files changed, 35 insertions(+), 9 deletions(-) > > ping > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 5, 2011 at 9:22 PM, Patrick Baggett wrote: > Wasn't nouveau targeted to provide HW acceleration for old cards like the > TNT2, or has that idea been killed? > Patrick > NV04-NV2F support went into a "classic" driver. > On Sun, Jun 5, 2011 at 2:06 PM, Marcin Slusarz > wrote: >> >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: >> > Bail out early in probe, so other driver can take control of the card. >> > Doing it in screen_create would be too late. >> > --- >> > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 >> > ++- >> > 1 files changed, 35 insertions(+), 9 deletions(-) >> >> ping >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 09:15:47PM +0200, Maarten Maathuis wrote: > 2011/6/5 Stéphane Marchesin : > > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz > > wrote: > >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: > >>> Bail out early in probe, so other driver can take control of the card. > >>> Doing it in screen_create would be too late. > >>> --- > >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 > >>> ++- > >>> 1 files changed, 35 insertions(+), 9 deletions(-) > >> > >> ping > >> > > > > Why do you need a list of cards for that, as opposed to reading the reg? > > > > I agree with Stephane, checking register 0 should work fine. First > check for NV04/05, then for NV10-NV2F. > I did it this way because I didn't have access to device file descriptor - it's created somewhere near InitScreen and passed to nouveau_drm_screen_create - too late to exit gracefully (something which I believe is a bug, but I couldn't track it). But now I see xf86-video-nouveau is in exactly the same situation - it opens fd temporarily in PciProbe. I'll adapt its code to target/xorg-nouveau. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 5, 2011 at 9:46 PM, Marcin Slusarz wrote: > On Sun, Jun 05, 2011 at 09:15:47PM +0200, Maarten Maathuis wrote: >> 2011/6/5 Stéphane Marchesin : >> > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz >> > wrote: >> >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote: >> >>> Bail out early in probe, so other driver can take control of the card. >> >>> Doing it in screen_create would be too late. >> >>> --- >> >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 >> >>> ++- >> >>> 1 files changed, 35 insertions(+), 9 deletions(-) >> >> >> >> ping >> >> >> > >> > Why do you need a list of cards for that, as opposed to reading the reg? >> > >> >> I agree with Stephane, checking register 0 should work fine. First >> check for NV04/05, then for NV10-NV2F. >> > > I did it this way because I didn't have access to device file descriptor - > it's created > somewhere near InitScreen and passed to nouveau_drm_screen_create - too late > to > exit gracefully (something which I believe is a bug, but I couldn't track it). > > But now I see xf86-video-nouveau is in exactly the same situation - it opens > fd > temporarily in PciProbe. I'll adapt its code to target/xorg-nouveau. I was incorrect in saying that you should check registers yourself (which would require root), but opening the device should give you the chipset type. > > Marcin > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37959] New: [regresssion] Errors starting sauerbraten with today's git master.
https://bugs.freedesktop.org/show_bug.cgi?id=37959 Summary: [regresssion] Errors starting sauerbraten with today's git master. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: All Status: NEW Severity: major Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: david.ro...@mcgill.ca When I start sauerbraten on my R200 box (an older HP laptop) I see: Mesa 7.11-devel implementation error: glUniform1f should be mapped to 322, not 547 Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: glMultiTexCoord4fARB should be mapped to 307, not 402 Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: glGetProgramivNV should be mapped to 306, not 749 Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: glFramebufferTexture3DEXT should be mapped to 337, not 844 after which, the program hangs. I should also point out that this game program has triggered other, as yet unresolved, serious bugs; see, Bug #32787 or Bug 25597. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 09:54:31PM +0200, Maarten Maathuis wrote:
> On Sun, Jun 5, 2011 at 9:46 PM, Marcin Slusarz
> wrote:
> > On Sun, Jun 05, 2011 at 09:15:47PM +0200, Maarten Maathuis wrote:
> >> 2011/6/5 Stéphane Marchesin :
> >> > On Sun, Jun 5, 2011 at 12:06, Marcin Slusarz
> >> > wrote:
> >> >> On Tue, May 17, 2011 at 12:20:14AM +0200, Marcin Slusarz wrote:
> >> >>> Bail out early in probe, so other driver can take control of the card.
> >> >>> Doing it in screen_create would be too late.
> >> >>> ---
> >> >>> src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44
> >> >>> ++-
> >> >>> 1 files changed, 35 insertions(+), 9 deletions(-)
> >> >>
> >> >> ping
> >> >>
> >> >
> >> > Why do you need a list of cards for that, as opposed to reading the reg?
> >> >
> >>
> >> I agree with Stephane, checking register 0 should work fine. First
> >> check for NV04/05, then for NV10-NV2F.
> >>
> >
> > I did it this way because I didn't have access to device file descriptor -
> > it's created
> > somewhere near InitScreen and passed to nouveau_drm_screen_create - too
> > late to
> > exit gracefully (something which I believe is a bug, but I couldn't track
> > it).
> >
> > But now I see xf86-video-nouveau is in exactly the same situation - it
> > opens fd
> > temporarily in PciProbe. I'll adapt its code to target/xorg-nouveau.
>
> I was incorrect in saying that you should check registers yourself
> (which would require root), but opening the device should give you the
> chipset type.
>
Yeah. New patch below.
Thanks!
---
From: Marcin Slusarz
Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
Bail out early in probe, so other driver (xf86-video-nouveau) can take control
of the card. Doing it in screen_create would be too late.
---
src/gallium/targets/xorg-nouveau/Makefile |3 +
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63 +++---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/Makefile
b/src/gallium/targets/xorg-nouveau/Makefile
index 16ac954..755969c 100644
--- a/src/gallium/targets/xorg-nouveau/Makefile
+++ b/src/gallium/targets/xorg-nouveau/Makefile
@@ -23,4 +23,7 @@ DRIVER_PIPES = \
DRIVER_LINKS = \
$(shell pkg-config --libs libdrm libdrm_nouveau)
+DRIVER_INCLUDES = \
+ $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau xf86driproto)
+
include ../Makefile.xorg
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index a25254a..43470a1 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -29,6 +29,9 @@
*/
#include "../../state_trackers/xorg/xorg_winsys.h"
+#include
+#include
+#include
static void nouveau_xorg_identify(int flags);
static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
@@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr driver, int
entity_num,
static const struct pci_id_match nouveau_xorg_device_match[] = {
{ 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
0x0003, 0x00ff, 0 },
-{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
- 0x0003, 0x00ff, 0 },
{0, 0, 0},
};
-static SymTabRec nouveau_xorg_chipsets[] = {
-{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
-{-1, NULL}
-};
-
static PciChipsets nouveau_xorg_pci_devices[] = {
{PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
{-1, -1, NULL}
@@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts, int
*errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel Drivers",
- nouveau_xorg_chipsets);
+xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for NV30+
NVIDIA chipsets\n");
}
static Bool
@@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
{
ScrnInfoPtr scrn = NULL;
EntityInfoPtr entity;
+struct nouveau_device *dev = NULL;
+char *busid;
+int chipset, ret;
+
+if (device->vendor_id != 0x10DE)
+ return FALSE;
+
+if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
+ return FALSE;
+}
+busid = DRICreatePCIBusID(device);
+
+ret = nouveau_device_open(&dev, busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
+ free(busid);
+ return FALSE;
+}
+
+chipset = dev->chipset;
+nouveau_device_close(&dev);
+
+ret = drmCheckModesettingSupported(busid);
+free(busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
+ return FALSE;
+}
+
+switch (chipset & 0xf0) {
+case 0x00:
+case 0x10:
+case 0x20:
+ xf86DrvMsg(-1, X_NOTICE, "Too old chipset: NV%02x\n", chipset);
+ return FALSE;
+case 0x30:
+case 0x40:
+
Re: [Mesa-dev] [PATCH v2 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 02:22:19PM -0500, Patrick Baggett wrote: >Wasn't nouveau targeted to provide HW acceleration for old cards like >the TNT2, or has that idea been killed? > This patch is for Gallium3D accelerated 2D xorg driver. Nobody is killing support for old cards from xf86-video-nouveau. Marcin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function
On Sun, Jun 5, 2011 at 11:34 AM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/02/2011 04:40 PM, Brian Paul wrote: >> On 06/02/2011 03:18 PM, Benjamin Bellec wrote: >>> It's me again, with a new minor optimization for the >>> util_next_power_of_two() function. >>> >>> This patch implements a faster algorithm, still taken from Wikipedia ( >>> http://en.wikipedia.org/wiki/Power_of_two#Algorithm_to_round_up_to_power_of_two >>> >>> ). >>> But especially, I added the most common values used by this function. I >>> noted that ETQW, TA Spring and ExtremeTuxRacer call often "good" values. >>> I can think that most OpenGL apps uses also these values. >>> >>> I have benchmarked this. With -O2 optimization, this new function is >>> twice faster than the former. Without GCC optimization the difference is >>> even bigger. >>> >>> There is no piglit regressions. >>> >>> But there is an issue, during compilation there is an error (-Wall) >>> "warning: right shift count>= width of type [enabled by default]". >> >> I'd like to avoid the warning if at all possible. If you replace (val 32) with (val >> (sizeof(unsigned) * 4)) does that silence it? > > It will because it will evaluate to val >> 16, which is not what's wanted. It would evaluate to 32 (8*4) when relevant. Please note the conditional. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
---
From: Marcin Slusarz
Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
Bail out early in probe, so other driver (xf86-video-nouveau) can
take control
of the card. Doing it in screen_create would be too late.
---
src/gallium/targets/xorg-nouveau/Makefile |3 +
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63
+++---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/Makefile
b/src/gallium/targets/xorg-nouveau/Makefile
index 16ac954..755969c 100644
--- a/src/gallium/targets/xorg-nouveau/Makefile
+++ b/src/gallium/targets/xorg-nouveau/Makefile
@@ -23,4 +23,7 @@ DRIVER_PIPES = \
DRIVER_LINKS = \
$(shell pkg-config --libs libdrm libdrm_nouveau)
+DRIVER_INCLUDES = \
+ $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau
xf86driproto)
+
include ../Makefile.xorg
diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
index a25254a..43470a1 100644
--- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
+++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
@@ -29,6 +29,9 @@
*/
#include "../../state_trackers/xorg/xorg_winsys.h"
+#include
+#include
+#include
static void nouveau_xorg_identify(int flags);
static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
@@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr
driver, int entity_num,
static const struct pci_id_match nouveau_xorg_device_match[] = {
{ 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
0x0003, 0x00ff, 0 },
-{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
- 0x0003, 0x00ff, 0 },
{0, 0, 0},
};
-static SymTabRec nouveau_xorg_chipsets[] = {
-{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
-{-1, NULL}
-};
-
static PciChipsets nouveau_xorg_pci_devices[] = {
{PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
{-1, -1, NULL}
@@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts,
int *errmaj, int *errmin)
static void
nouveau_xorg_identify(int flags)
{
-xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel
Drivers",
- nouveau_xorg_chipsets);
+xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for
NV30+ NVIDIA chipsets\n");
}
static Bool
@@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
{
ScrnInfoPtr scrn = NULL;
EntityInfoPtr entity;
+struct nouveau_device *dev = NULL;
+char *busid;
+int chipset, ret;
+
+if (device->vendor_id != 0x10DE)
+ return FALSE;
+
+if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
+ return FALSE;
+}
+busid = DRICreatePCIBusID(device);
+
+ret = nouveau_device_open(&dev, busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
+ free(busid);
+ return FALSE;
+}
+
+chipset = dev->chipset;
+nouveau_device_close(&dev);
+
+ret = drmCheckModesettingSupported(busid);
+free(busid);
+if (ret) {
+ xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
+ return FALSE;
+}
+
+switch (chipset & 0xf0) {
+case 0x00:
+case 0x10:
+case 0x20:
+ xf86DrvMsg(-1, X_NOTICE, "Too old chipset: NV%02x\n", chipset);
+ return FALSE;
+case 0x30:
+case 0x40:
+case 0x60:
+case 0x50:
+case 0x80:
+case 0x90:
+case 0xa0:
+case 0xc0:
0xd0 should be added here, there's NVD9 already.
+ xf86DrvMsg(-1, X_INFO, "Detected chipset: NV%02x\n", chipset);
+ break;
+default:
+ xf86DrvMsg(-1, X_ERROR, "Unknown chipset: NV%02x\n", chipset);
+ return FALSE;
+}
scrn = xf86ConfigPciEntity(scrn, 0, entity_num,
nouveau_xorg_pci_devices,
NULL, NULL, NULL, NULL, NULL);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] mesa regressions on darwin
So I've finally sat down and tried to fix regressions on master due to glx restructuring last year ... mostly these are changes where people forgot to make corresponding changes in the apple subdirectory. There is one standout that I'm not sure how to fix (glxext.c). This is a build failure introduced by (http://cgit.freedesktop.org/mesa/mesa/commit/?id=6849916170c0275c13510251a7b217c20f2b993e This commit added a new reference to appleglDisplay, but it was never defined. What is supposed to be happening here? ../glxext.c: In function ‘AllocAndFetchScreenConfigs’: ../glxext.c:782: error: ‘struct glx_display’ has no member named ‘appleglDisplay’ ../glxext.c:783: error: ‘struct glx_display’ has no member named ‘appleglDisplay’ ../glxext.c: In function ‘__glXInitialize’: ../glxext.c:869: warning: implicit declaration of function ‘applegl_create_display’ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa regressions on darwin
I think I've figured out those issues... I just need to now figure out how to properly implement applegl_glx.c ... On Jun 5, 2011, at 6:34 PM, Jeremy Huddleston wrote: > So I've finally sat down and tried to fix regressions on master due to glx > restructuring last year ... mostly these are changes where people forgot to > make corresponding changes in the apple subdirectory. > > There is one standout that I'm not sure how to fix (glxext.c). This is a > build failure introduced by > (http://cgit.freedesktop.org/mesa/mesa/commit/?id=6849916170c0275c13510251a7b217c20f2b993e > > This commit added a new reference to appleglDisplay, but it was never > defined. What is supposed to be happening here? > > ../glxext.c: In function ‘AllocAndFetchScreenConfigs’: > ../glxext.c:782: error: ‘struct glx_display’ has no member named > ‘appleglDisplay’ > ../glxext.c:783: error: ‘struct glx_display’ has no member named > ‘appleglDisplay’ > ../glxext.c: In function ‘__glXInitialize’: > ../glxext.c:869: warning: implicit declaration of function > ‘applegl_create_display’ > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/brw: Emit state for hiz and separate stencil buffers
On Sun, 05 Jun 2011 01:37:27 -0700, Kenneth Graunke wrote: > On 06/04/2011 04:29 PM, Chad Versace wrote: > > On 06/03/2011 03:33 PM, Kenneth Graunke wrote: > >> Do we need to emit 3DSTATE_STENCIL_BUFFER with all 0's in the stencil_irb > >> == NULL case? Ditto for HiZ I guess. Just being a > >> bit paranoid. > > > > The test results for these paranoiac cases pass, so paranoia is unneeded. > > Regarding "Do we need to emit 3DSTATE_STENCIL_BUFFER > > with all 0's in the stencil_irb == NULL case", see tests: > > * hiz-depth-test-fbo-d24-s0 : column 6 > > * hiz-depth-stencil-fbo-d24-s0 : columns 3, 6 > > Regarding "Ditto for HiZ", the following test runs emit a stencil buffer > > but no hiz buffer: > > * hiz-stencil-test-fbo-d0-s8 : column 6 > > * hiz-stencil-read-fbo-d0-s8 : column 6 > > * hiz-depth-stencil-fbo-d0-s8 : column 6 > > Hrm. I was thinking of a slightly more elaborate case: Render to an FBO > that has both depth and stencil...then render to another FBO that only > has depth. The question is: would the old stencil buffer stay > programmed and somehow get used. Although come to think of it, I think > the "Separate Stencil Enable" bit in 3DSTATE_DEPTH_BUFFER ought to be > sufficient. So it's probably okay. To be extra safe, we could upload a zero-ish 3DSTATE_STENCIL_BUFFER when there is no stencil buffer. But, that upload is really wasted bandwidth, since the separate-stencil-enable bit is disabled and hardware won't read 3DSTATE_STENCIL_BUFFER anyway. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965/gen6: Add support for gl_PointCoord.
This is just like PointSprite overrides, but it's always on for that attribute. Fixes glsl-fs-pointcoord, gtf/point_sprites. --- src/mesa/drivers/dri/i965/gen6_sf_state.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c b/src/mesa/drivers/dri/i965/gen6_sf_state.c index f3e6734..faa68d6 100644 --- a/src/mesa/drivers/dri/i965/gen6_sf_state.c +++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c @@ -251,6 +251,9 @@ upload_sf_state(struct brw_context *brw) dw16 |= (1 << input_index); } + if (attr == FRAG_ATTRIB_PNTC) +dw16 |= (1 << input_index); + /* The hardware can only do the overrides on 16 overrides at a * time, and the other up to 16 have to be lined up so that the * input index = the output index. We'll need to do some -- 1.7.5.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] i965/gen6: Refactor SF setup a bit to handle overrides in one place.
---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 43 -
1 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c
b/src/mesa/drivers/dri/i965/gen6_sf_state.c
index 84028e4..8437cfe 100644
--- a/src/mesa/drivers/dri/i965/gen6_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c
@@ -100,10 +100,11 @@ upload_sf_state(struct brw_context *brw)
int i;
/* _NEW_BUFFER */
GLboolean render_to_fbo = brw->intel.ctx.DrawBuffer->Name != 0;
- int attr = 0;
+ int attr = 0, input_index = 0;
int urb_start;
int two_side_color = (ctx->Light.Enabled && ctx->Light.Model.TwoSide);
float point_size;
+ uint16_t attr_overrides[FRAG_ATTRIB_MAX];
/* _NEW_TRANSFORM */
if (ctx->Transform.ClipPlanesEnabled)
@@ -243,6 +244,27 @@ upload_sf_state(struct brw_context *brw)
((brw->fragment_program->Base.InputsRead & FRAG_BIT_WPOS) ? 0
: 1));
}
+ /* Create the mapping from the FS inputs we produce to the VS outputs
+* they source from.
+*/
+ for (; attr < FRAG_ATTRIB_MAX; attr++) {
+ if (!(brw->fragment_program->Base.InputsRead & BITFIELD64_BIT(attr)))
+continue;
+
+ /* The hardware can only do the overrides on 16 overrides at a
+ * time, and the other up to 16 have to be lined up so that the
+ * input index = the output index. We'll need to do some
+ * tweaking to make sure that's the case.
+ */
+ assert(input_index < 16 || attr == input_index);
+
+ attr_overrides[input_index++] = get_attr_override(brw, attr,
+ two_side_color);
+ }
+
+ for (; attr < FRAG_ATTRIB_MAX; attr++)
+ attr_overrides[input_index++] = 0;
+
BEGIN_BATCH(20);
OUT_BATCH(_3DSTATE_SF << 16 | (20 - 2));
OUT_BATCH(dw1);
@@ -253,24 +275,7 @@ upload_sf_state(struct brw_context *brw)
OUT_BATCH_F(ctx->Polygon.OffsetFactor); /* scale */
OUT_BATCH_F(0.0); /* XXX: global depth offset clamp */
for (i = 0; i < 8; i++) {
- uint32_t attr_overrides = 0;
-
- for (; attr < 64; attr++) {
-if (brw->fragment_program->Base.InputsRead & BITFIELD64_BIT(attr)) {
- attr_overrides |= get_attr_override(brw, attr, two_side_color);
- attr++;
- break;
-}
- }
-
- for (; attr < 64; attr++) {
-if (brw->fragment_program->Base.InputsRead & BITFIELD64_BIT(attr)) {
- attr_overrides |= get_attr_override(brw, attr, two_side_color) <<
16;
- attr++;
- break;
-}
- }
- OUT_BATCH(attr_overrides);
+ OUT_BATCH(attr_overrides[i * 2] | attr_overrides[i * 2 + 1] << 16);
}
OUT_BATCH(dw16); /* point sprite texcoord bitmask */
OUT_BATCH(dw17); /* constant interp bitmask */
--
1.7.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965/gen6: Fix point sprite texture coordinate overrides.
We were assuming that the input attribute n to the FS was
FRAG_ATTRIB_TEXn, which happened to be true often enough for our
testcases.
---
src/mesa/drivers/dri/i965/gen6_sf_state.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c
b/src/mesa/drivers/dri/i965/gen6_sf_state.c
index 8437cfe..f3e6734 100644
--- a/src/mesa/drivers/dri/i965/gen6_sf_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c
@@ -231,13 +231,6 @@ upload_sf_state(struct brw_context *brw)
(1 << GEN6_SF_TRIFAN_PROVOKE_SHIFT);
}
- if (ctx->Point.PointSprite) {
- for (i = 0; i < 8; i++) {
- if (ctx->Point.CoordReplace[i])
- dw16 |= (1 << i);
- }
- }
-
/* flat shading */
if (ctx->Light.ShadeModel == GL_FLAT) {
dw17 |= ((brw->fragment_program->Base.InputsRead & (FRAG_BIT_COL0 |
FRAG_BIT_COL1)) >>
@@ -251,6 +244,13 @@ upload_sf_state(struct brw_context *brw)
if (!(brw->fragment_program->Base.InputsRead & BITFIELD64_BIT(attr)))
continue;
+ /* _NEW_POINT */
+ if (ctx->Point.PointSprite &&
+ (attr >= FRAG_ATTRIB_TEX0 && attr <= FRAG_ATTRIB_TEX7) &&
+ ctx->Point.CoordReplace[attr - FRAG_ATTRIB_TEX0]) {
+dw16 |= (1 << input_index);
+ }
+
/* The hardware can only do the overrides on 16 overrides at a
* time, and the other up to 16 have to be lined up so that the
* input index = the output index. We'll need to do some
--
1.7.5.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/10] intel: Request DRI2 buffers for separate stencil and hiz
On Sun, 5 Jun 2011 11:01:21 +0200, Nicolas Kaiser wrote: > Just noticed two typos in comments. > > * Chad Versace : > > --- a/src/mesa/drivers/dri/intel/intel_context.c > > +++ b/src/mesa/drivers/dri/intel/intel_context.c > (..) > > +/** > > + * \brief Verify that the X driver supports hiz and separate stencil. > > + * > > + * This implements the cleanup stage of the handshake described in the > > + * comments for 'enum intel_dri2_has_hiz'. > > + * > > + * This should be called from intel_update_renderbuffers() after 1) the > > + * DRIdrawable has been queried for its buffers via > > DRI2GetBuffersWithFormat() > > + * and 2) the DRM region of each returned DRIbuffer has been assigned to > > the > > + * appropriate intel_renderbuffer. Futhermore, this should be called *only* > > Furthermore > > (..) > > +/* > > + * I don't know how to recover from the failure assertion below. > > + * Rather than fail gradually and unexpectedtly, we should just die > > unexpectedly > > > Best regards, > Nicolas Kaiser Thanks. Spelling fixes applied. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/10] i965: Implement hiz and separate stencil for window framebuffer
On Sun, 05 Jun 2011 10:44:17 +0100, Chris Wilson wrote: > I have a naive question: why are we allocating stencil/depth/aux buffers > through X/DRI2? > > I can understand for the sake of interoperability why the color buffer > attachments are negotiated with X, but I can't see any reason why X > wants to know about the others. > -Chris From the GLX 1.4 specification: Ancillary buffers are associated with a GLXDrawable, not with a rendering context. If several rendering contexts are all writing to the same window, they will share those buffers. This is why so much of GLX is so painful -- even across address spaces, drawables have to share buffers. pgpUHPorjdve6.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37476] [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=37476 Mike Kaplinskiy changed: What|Removed |Added Platform|Other |x86 (IA32) AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||mike.kaplins...@gmail.com --- Comment #1 from Mike Kaplinskiy 2011-06-05 22:32:34 PDT --- [changing assignee as this is clearly a mesa bug] piglit arb_shader_texture_lod-texgrad shows the problem (using texture2DGradARB). Currently running it may also get you a fortify crash due to TXD having 4 inputs (the max in the context structure is 3). I'm attaching a patch that has an implementation. Unfortunately I can't seem to get it to work entirely correctly. The piglit test looks almost correct but has several artifacts in random places. If someone could point me in the right direction (as I'm completely clueless), I would be happy to finish it. In case it matters, piglit does not show any new failures from this patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 37476] [wine] Devil May Cry 4: TXD tgsi opcode unsupported / translation from TGSI failed / missing vertex shader
https://bugs.freedesktop.org/show_bug.cgi?id=37476 --- Comment #2 from Mike Kaplinskiy 2011-06-05 22:33:42 PDT --- Created an attachment (id=47580) View: https://bugs.freedesktop.org/attachment.cgi?id=47580 Review: https://bugs.freedesktop.org/review?bug=37476&attachment=47580 Incomplete patch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Nouveau] [PATCH v3 2/2] xorg/nouveau: blacklist all pre NV30 cards
On Sun, Jun 05, 2011 at 11:43:15PM +0200, Marcin Kościelnicki wrote:
> > ---
> > From: Marcin Slusarz
> > Subject: [PATCH] xorg/nouveau: blacklist all pre NV30 cards
> >
> > Bail out early in probe, so other driver (xf86-video-nouveau) can
> > take control
> > of the card. Doing it in screen_create would be too late.
> > ---
> > src/gallium/targets/xorg-nouveau/Makefile |3 +
> > src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 63
> > +++---
> > 2 files changed, 57 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/gallium/targets/xorg-nouveau/Makefile
> > b/src/gallium/targets/xorg-nouveau/Makefile
> > index 16ac954..755969c 100644
> > --- a/src/gallium/targets/xorg-nouveau/Makefile
> > +++ b/src/gallium/targets/xorg-nouveau/Makefile
> > @@ -23,4 +23,7 @@ DRIVER_PIPES = \
> > DRIVER_LINKS = \
> > $(shell pkg-config --libs libdrm libdrm_nouveau)
> >
> > +DRIVER_INCLUDES = \
> > + $(shell pkg-config --cflags-only-I libdrm libdrm_nouveau
> > xf86driproto)
> > +
> > include ../Makefile.xorg
> > diff --git a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > index a25254a..43470a1 100644
> > --- a/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > +++ b/src/gallium/targets/xorg-nouveau/nouveau_xorg.c
> > @@ -29,6 +29,9 @@
> > */
> >
> > #include "../../state_trackers/xorg/xorg_winsys.h"
> > +#include
> > +#include
> > +#include
> >
> > static void nouveau_xorg_identify(int flags);
> > static Bool nouveau_xorg_pci_probe(DriverPtr driver, int entity_num,
> > @@ -38,16 +41,9 @@ static Bool nouveau_xorg_pci_probe(DriverPtr
> > driver, int entity_num,
> > static const struct pci_id_match nouveau_xorg_device_match[] = {
> > { 0x10de, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
> >0x0003, 0x00ff, 0 },
> > -{ 0x12d2, PCI_MATCH_ANY, PCI_MATCH_ANY, PCI_MATCH_ANY,
> > - 0x0003, 0x00ff, 0 },
> > {0, 0, 0},
> > };
> >
> > -static SymTabRec nouveau_xorg_chipsets[] = {
> > -{PCI_MATCH_ANY, "NVIDIA Graphics Device"},
> > -{-1, NULL}
> > -};
> > -
> > static PciChipsets nouveau_xorg_pci_devices[] = {
> > {PCI_MATCH_ANY, PCI_MATCH_ANY, NULL},
> > {-1, -1, NULL}
> > @@ -121,8 +117,7 @@ nouveau_xorg_setup(pointer module, pointer opts,
> > int *errmaj, int *errmin)
> > static void
> > nouveau_xorg_identify(int flags)
> > {
> > -xf86PrintChipsets("nouveau2", "Driver for Modesetting Kernel
> > Drivers",
> > - nouveau_xorg_chipsets);
> > +xf86DrvMsg(0, X_INFO, "nouveau2: Gallium3D based 2D driver for
> > NV30+ NVIDIA chipsets\n");
> > }
> >
> > static Bool
> > @@ -131,6 +126,56 @@ nouveau_xorg_pci_probe(DriverPtr driver,
> > {
> > ScrnInfoPtr scrn = NULL;
> > EntityInfoPtr entity;
> > +struct nouveau_device *dev = NULL;
> > +char *busid;
> > +int chipset, ret;
> > +
> > +if (device->vendor_id != 0x10DE)
> > + return FALSE;
> > +
> > +if (!xf86LoaderCheckSymbol("DRICreatePCIBusID")) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] No DRICreatePCIBusID symbol\n");
> > + return FALSE;
> > +}
> > +busid = DRICreatePCIBusID(device);
> > +
> > +ret = nouveau_device_open(&dev, busid);
> > +if (ret) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] failed to open device\n");
> > + free(busid);
> > + return FALSE;
> > +}
> > +
> > +chipset = dev->chipset;
> > +nouveau_device_close(&dev);
> > +
> > +ret = drmCheckModesettingSupported(busid);
> > +free(busid);
> > +if (ret) {
> > + xf86DrvMsg(-1, X_ERROR, "[drm] KMS not enabled\n");
> > + return FALSE;
> > +}
> > +
> > +switch (chipset & 0xf0) {
> > +case 0x00:
> > +case 0x10:
> > +case 0x20:
> > + xf86DrvMsg(-1, X_NOTICE, "Too old chipset: NV%02x\n", chipset);
> > + return FALSE;
> > +case 0x30:
> > +case 0x40:
> > +case 0x60:
> > +case 0x50:
> > +case 0x80:
> > +case 0x90:
> > +case 0xa0:
> > +case 0xc0:
> 0xd0 should be added here, there's NVD9 already.
There's no point in adding it now - mesa does not support it...
(see nouveau_drm_screen_create in
src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c)
> > + xf86DrvMsg(-1, X_INFO, "Detected chipset: NV%02x\n", chipset);
> > + break;
> > +default:
> > + xf86DrvMsg(-1, X_ERROR, "Unknown chipset: NV%02x\n", chipset);
> > + return FALSE;
> > +}
> >
> > scrn = xf86ConfigPciEntity(scrn, 0, entity_num,
> > nouveau_xorg_pci_devices,
> >NULL, NULL, NULL, NULL, NULL);
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/nouveau: remove unused nouveau_screen_bo_user
On Mon, May 09, 2011 at 12:35:10AM +0200, Marcin Slusarz wrote: > > --- > src/gallium/drivers/nouveau/nouveau_screen.c | 14 -- > src/gallium/drivers/nouveau/nouveau_screen.h |2 -- > 2 files changed, 0 insertions(+), 16 deletions(-) ping ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
