search for: sample_count

...LER_VIEW_TARGET > > And this hack: > > --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c > @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen > *pscreen, > unsigned sample_count, > unsigned bindings) > { > - if (sample_count > 4) > + if (sample_count > 0) > return false; > if (!(0x00000017 & (1 << sample_count))) > return false; > > Fixes the slide animation misrendering (and...

.../nv30_screen.c > index 7aad26b..69acc38 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c > @@ -319,8 +319,16 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen, > unsigned sample_count, > unsigned bindings) > { > - if (sample_count > 4) > - return false; > + struct nv30_screen *screen = nv30_screen(pscreen); > + > + if (screen->eng3d->oclass >= NV40_3D_CLASS) { > + if (sample_count > 4) >...

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x

Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process is for getting (nouveau) mesa patches merged. Should I request commit rights, and push my own patches once they have been reviewed ? Regards, Hans

...the csv file OGSdata <- read.table("MG3199.csv",sep=",",header=TRUE) #creates 3 separate vectors sample <- OGSdata[,1] mci <- OGSdata[,2] pct <- OGSdata[,3] #change mci range offset <- min(mci)-1 mci <- (mci - offset) #matrix sizes mci_count <- max(mci) sample_count <- max(sample) #creates a zero matrix OGS <- mat.or.vec(mci_count,sample_count) #Create labels sample_lab <- ("A-9","B-9", "C-9", "D-9", "E-9","A-12","B-12", "C-12", "D-12", "E-12") #add...

On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > On 27-08-15 20:19, Ilia Mirkin wrote: >> >> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher at gmail.com> >> wrote: > > > <snip> > >>>>>> 2) Since the glretrace does work outside of libreoffice impress, I

The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 4 ++-- 1 file changed, 2

...gallium/drivers/nouveau/nvc0/nvc0_screen.c index 4757fe2..1c88580 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -43,6 +43,7 @@ nvc0_screen_is_format_supported(struct pipe_screen *pscreen, unsigned sample_count, unsigned bindings) { + const struct util_format_description *desc = util_format_description(format); if (sample_count > 8) return false; if (!(0x117 & (1 << sample_count))) /* 0, 1, 2, 4 or 8 */ @@ -55,6 +56,15 @@ nvc0_screen_is_forma...

.../nv30_screen.c > index 7aad26b..7a16e72 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c > @@ -319,8 +319,25 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen, > unsigned sample_count, > unsigned bindings) > { > + /* > + * msaa use on nv30 may trigger a (mesa?) bug where dmesg says: > + * [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate > + * [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list...

Again, thank you for helping me. I know this might seem like a trivial matter to you and other experts in the field, but believe me, there are a lot of programmers, whose posts I saw on the web, who tried to use WaveIn/WaveOut and Speex and failed. As I understand it, WaveIn just buffers audio data according to the bit rate specified. So, if we use waveFormat.wBitsPerSample = 8, then each Char of

...> >>> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >>> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen >>> *pscreen, >>> unsigned sample_count, >>> unsigned bindings) >>> { >>> - if (sample_count > 4) >>> + if (sample_count > 0) >>> return false; >>> if (!(0x00000017 & (1 << sample_count))) >>> return...

...vc0/nvc0_screen.c > index 4757fe2..1c88580 100644 > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c > @@ -43,6 +43,7 @@ nvc0_screen_is_format_supported(struct pipe_screen *pscreen, > unsigned sample_count, > unsigned bindings) > { > + const struct util_format_description *desc = util_format_description(format); > if (sample_count > 8) > return false; > if (!(0x117 & (1 << sample_count))) /* 0, 1, 2, 4 or 8 */ > @@ -...

...s. > My question is on how to deal with Speex output -- if I get a float > or a short from Speex' decode function, how does it map to audio > samples described above? First off, don't use the float decoder, use shorts instead. Define a unions as follows: union { char c [SAMPLE_COUNT * 2] ; short s [SAMPLE_COUNT] ; } buf; Read from Speex into the buf.s array and then pass the buf.c array to WaveOut. For an example of how to do this, have a look at the sndfile-play.c in the examples directory of libsndfile: http://www.mega-nerd.com/libsndfile/ Erik -- ----------...

...Speex output -- if I get a float > > or a short from Speex' decode function, how does it map to audio > > samples described above? > > First off, don't use the float decoder, use shorts instead. > > Define a unions as follows: > > union > { char c [SAMPLE_COUNT * 2] ; > short s [SAMPLE_COUNT] ; > } buf; > > Read from Speex into the buf.s array and then pass the buf.c array > to WaveOut. > > For an example of how to do this, have a look at the sndfile-play.c > in the examples directory of libsndfile: > > http://...

https://bugs.freedesktop.org/show_bug.cgi?id=46956 Bug #: 46956 Summary: Selecting 2xAntiAliasing causes Nexuiz to crash "X Error: BadMatch, failed request (X_CreateWindow)" Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status:

...hader, param); > +} > + > +static boolean > +tegra_screen_is_format_supported(struct pipe_screen *pscreen, > + enum pipe_format format, > + enum pipe_texture_target target, > + unsigned sample_count, > + unsigned usage) > +{ > + struct tegra_screen *screen = to_tegra_screen(pscreen); > + > + return screen->gpu->is_format_supported(screen->gpu, format, target, > + sample_count, us...

...ct tegra_screen *screen = to_tegra_screen(pscreen); + + return screen->gpu->get_shader_param(screen->gpu, shader, param); +} + +static boolean +tegra_screen_is_format_supported(struct pipe_screen *pscreen, + enum pipe_format format, + enum pipe_texture_target target, + unsigned sample_count, + unsigned usage) +{ + struct tegra_screen *screen = to_tegra_screen(pscreen); + + return screen->gpu->is_format_supported(screen->gpu, format, target, + sample_count, usage); +} + +static void +tegra_fence_reference(struct pipe_screen *pscreen, + struct pipe_fence_handle...

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