similar to: [PATCH] nvc0: add hardware ETC2 and ASTC support where possible

On Sat, Dec 19, 2015 at 1:53 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These are supported on GK20A and GM107. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Was a bit torn on where to place the enums... we're about to gut all > the xml definitions so this seemed appropriate for now. > > Tested on GK20A only. > >

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- src/gallium/drivers/nouveau/nv50/g80_defs.xml.h | 279 ++++++++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 src/gallium/drivers/nouveau/nv50/g80_defs.xml.h diff --git a/src/gallium/drivers/nouveau/nv50/g80_defs.xml.h

Why not fix the new names instead to be like the old names? Seems like that would be way simpler... On Feb 15, 2016 12:38 AM, "Ben Skeggs" <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > We've previously had identical naming between vertex and texture > formats, so it mostly made sense to define these together. > > However,

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

From: Ben Skeggs <bskeggs at redhat.com> We've previously had identical naming between vertex and texture formats, so it mostly made sense to define these together. However, upcoming patches are going to transition the driver over to using updated texture header definitions using NVIDIA's naming, and this will no longer be the case. Signed-off-by: Ben Skeggs <bskeggs at

Hi, guys: I’m a developer of FydeOS. We porting ChromiumOS to amd64 and arm platforms. Now, I’m woking on porting android environment to Nvidia graphic cards. I have experience to port android to Vmware(SVGA). I found two display formats were not supported to display in nouveau driver: PIPE_FORMAT_R8G8B8A8_UNORM, PIPE_FORMAT_R8G8B8X8_UNORM. Which are defined at nv50/nv50_formats.c line: 130,131.

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on nv96 with Chris Forbes's piglit tests (on list, but not checked in yet)... only assuming about nvc0, but it seems reasonable since all the other attributes are the same. docs/GL3.txt | 2 +- src/gallium/drivers/nouveau/nv50/nv50_3d.xml.h | 1 +

Can you push this to a repo somewhere? I want to see what the final version looks like after all your changes, but it's hard to see that with these patches. On Mon, Feb 15, 2016 at 12:38 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > From: Ben Skeggs <bskeggs at redhat.com> > > Adds support for the new TIC layout that's present on Maxwell GPUs, > heavily based on

I'm trying to match a ConstantFPSDNode == 0 in dag pattern for tablegen but am having some issues. So LLVM doesn't seem to accept a floating point constant literal match like: %v = call <4 x float> @foo(i32 15, float %s, float 0.0, <8 x i32> %rsrc, <4 x i32> %samp, i1 0, i32 0, i32 0) ret <4 x float> %v def : XXXPat<(v4f32 (int_foo i32:$mask, f32:$s, 0,

Unfortuantely we don't know if a particular load is a real 2d image (as would be a cube face or 2d array element), or a layer of a 3d image. Since we pass in the TIC reference, the instruction's type has to match what's in the TIC (experimentally). In order to properly support bindless images, this also can't be done by looking at the current bindings and generating appropriate

On Sat, Feb 16, 2019 at 2:27 AM Yang Tsao <yang at fydeos.io> wrote: > > Thx for your reply. > Chromium OS is running based DRM driver. There is no X server frame work. I modified nv50/nv50_formats.c. > > And there also a few code related the display format: > nv50_surface.c > Function nv50_2d_format: > I add: > > ——————————— > switch (format) { >

On Fri, Jan 09, 2015 at 07:07:38PM -0500, Bill Maltby (C4B) wrote: > On Fri, 2015-01-09 at 15:17 -0500, Fred Smith wrote: > > On Fri, Jan 09, 2015 at 02:34:38PM -0500, Bill Maltby (C4B) wrote: > > > On Fri, 2015-01-09 at 09:17 -0500, Fred Smith wrote: > > > > Hi all! > > > > > > > > Using the default Gnome desktop on Centos-6, I keep having

On Sun, Jan 11, 2015 at 05:12:48PM -0500, Bill Maltby (C4B) wrote: > On Fri, 2015-01-09 at 19:42 -0500, Fred Smith wrote: > > On Fri, Jan 09, 2015 at 07:07:38PM -0500, Bill Maltby (C4B) wrote: > > <snip> > > > > > > Well, that's the limit of my offerings. I'm still trying to find the > > > thing I used back in C5(?) that raised the panels

On 01/09/2015 06:07 PM, Bill Maltby (C4B) wrote: > I'm still trying to find the > thing I used back in C5(?) that raised the panels when the mouse hovered > over it for X seconds. With C6 I can't find it anymore and it switches > way too fast. I presume you're talking about panels with "Autohide" set. If you have the GUI gconf-editor installed, it's under

On Fri, 2015-08-14 at 06:39 -0400, Bill Maltby (C4B) wrote: > On Fri, 2015-08-14 at 06:02 -0400, Bill Maltby (C4B) wrote: > > <snip> > Anyway, logging the user out and back in, the panel shows no checking > for updates. Ksnapshot selection for the other user still lagging and > jerky. CPU usage now bouncing 49%-53% with only this message composing > going on and the

On Aug 16, 2015, at 2:39 PM, Bill Maltby (C4B) <centos4bill at gmail.com> wrote: > My preliminary conclusion is there's something in java and/or > libreoffice that begins causing load on the X server once activity > begins. The full effects of the java applet in FF could not be > determined during the attempt to duplicate due to the lack of a data > feed Saturday and

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

On 2015-04-04, Bill Maltby (C4B) <centos4bill at gmail.com> wrote: > On Sat, 2015-04-04 at 11:12 +0100, Nux! wrote: >> 100% with Digimer here. <snip> > >> All this energy should be put into contributing towards to the >> project, testing, helping out community. > > Well, I used to agree. But when a bug report filed in December goes > untouched entering

On 01/23/2015 04:05 PM, Always Learning wrote: > On Thu, 2015-01-22 at 21:19 -0500, Bill Maltby (C4B) wrote: > >> I object to this sort of crap. Hidden, no reason for an *IX desktop to >> be forced to ignore or deal with this crap. >> >> Anybody else seeing it? >> >> In case attachments aren't allowed in the list, here's the Dropbox url >>

On Thu, 2015-08-13 at 23:51 -0700, Gordon Messmer wrote: > On 08/13/2015 02:44 PM, Bill Maltby (C4B) wrote: > > Top shows > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 32160 root 20 0 259m 104m 22m R 76.5 1.3 559:07.79 Xorg > > 23391 hardtolo 20 0 6293m 215m 26m S 16.9 2.7 21:49.86 java > > Well, what's process