similar to: [Bug 61635] New: glVertexAttribPointer(id, GL_UNSIGNED_BYTE, GL_FALSE, ...) does not work

On Tue, Apr 19, 2016 at 8:52 AM, Daniel Melo Jorge da Cunha <dmjcunha at gmail.com> wrote: > Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card > processes > these three floats? Does the card work with floats? Does (mesa? gallium? > driver?) > process these three input floats before it is sent to the card? Where is the > code > for it?

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

Hi Ilia, you were straight to the point for me in: "src/mesa/vbo will upload it to a vbo. The driver then points the hardware at the vbo and tells it to read from there." But where is it the function that implements this? Is it in nv30_draw_vbo(...)? Please, give me a function name or at least a file name? 2016-04-19 10:04 GMT-04:00 Ilia Mirkin <imirkin at alum.mit.edu>: >

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,

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. src/gallium/drivers/nouveau/nv50/nv50_formats.c | 64 +++++++++++++++++++++++++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++++

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

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

Import "remove bgr" from qemu mainstream. git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6335 c046a42c-6fe2-441c-8c8c-71466251a162 Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- diff --git a/hw/musicpal.c b/hw/musicpal.c index d6bd9ec..44a5659 100644 --- a/hw/musicpal.c +++ b/hw/musicpal.c @@ -835,7 +835,7 @@ static void lcd_refresh(void *opaque)

Hi, for example, if I have glVertex3f(0.75, 0.75, 1.0) how the video card processes these three floats? Does the card work with floats? Does (mesa? gallium? driver?) process these three input floats before it is sent to the card? Where is the code for it? If you say the floats are memory mapped as in exec->vtx.buffer_map = (GLfloat *)ctx->Driver.MapBufferRange(...) I would say from what I

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,

Fixes icon colours on my PowerBook. Given that the preprocessor test was reversed when the code was reorganized and nobody on !MSBFirst platforms complained, one code path should suffice. --- src/texture.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/src/texture.c b/src/texture.c index 4170c70..7021643 100644 --- a/src/texture.c +++ b/src/texture.c @@ -164,13

This fixes issues where get_rt_format would see a 0 format because the nouveau_surface had not been properly initialized. Fixes crash on supertuxkart startup (which still fails due to out-of-vram issues). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/drivers/dri/nouveau/nouveau_texture.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git

Fixes an assertion seen by users. Signed-off-by: Lucas Stach <dev at lynxeye.de> Tested-by: JohnDoe_71Rus on irc --- src/mesa/drivers/dri/nouveau/nouveau_context.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c index 4845767..46c0d70 100644 ---

This fixes the teximage-colors uploads with GL_ALPHA format and non-GL_UNSIGNED_BYTE type. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c index 4130d36..4404d8c

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.

Import "DisplayState interface change" from qemu mainstream: the patch has been adapted to qemu-xen and merged with several following fixes. The original qemu svn commit is the following: git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6336 c046a42c-6fe2-441c-8c8c-71466251a162 Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- diff --git a/console.c

mesa_texstore expects pixel data, not compressed data. For compressed textures, we want to just copy the bits in without any conversion. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/mesa/drivers/dri/nouveau/nouveau_texture.c | 65 ++++++++++++++++++++------ 1 file changed, 52 insertions(+), 13 deletions(-) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c

in nouveau_shader_pass2() 210: struct pass2_rec *rec; ... 215: rec = calloc(1, sizeof(struct pass2_rec)); ... 218: nvs->pass_rec = rec; untested, please check. -- also free nvs->pass_rec on error Signed-off-by: Roel Kluin <12o3l at tiscali.nl> --- diff --git a/src/mesa/drivers/dri/nouveau/nouveau_shader_2.c b/src/mesa/drivers/dri/nouveau/nouveau_shader_2.c index

On Sun, Sep 14, 2014 at 3:37 AM, Francisco Jerez <currojerez at riseup.net> wrote: > Ilia Mirkin <imirkin at alum.mit.edu> writes: > >> mesa_texstore expects pixel data, not compressed data. For compressed >> textures, we want to just copy the bits in without any conversion. >> > > Any reason we cannot use _mesa_store_compressed_*image for this instead

Ilia Mirkin <imirkin at alum.mit.edu> writes: > mesa_texstore expects pixel data, not compressed data. For compressed > textures, we want to just copy the bits in without any conversion. > Any reason we cannot use _mesa_store_compressed_*image for this instead of rolling our own? > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- >