[Mesa-dev] bad libdrm_radeon version for scons
Hello, Just to report that libdrm_radeon version (2.4.44) has not been updated in scons/gallium.py too (still at version 2.4.42). Regards. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How do I start contributing to Mesa?
Le 04/06/2013 21:54, Brian Paul a écrit : > On 06/04/2013 06:37 AM, Arnas Milaševičius wrote: >> Hello, >> >> First of all, I'm not sure if it's the right place to ask such a >> question, but I'll try. I've started learning OpenGL and I really want >> to contribute to Mesa project, but the way to do it had always been a >> mistery for me. As a beginner contributor, I still don't understand >> which bugs should I take, how do I fix em? It's like, you take the bug, >> but... where the heck do you start fixing it? How do you find the core >> of the problem? I see many people telling that the best start is to >> start fixing bugs you have, but atm I don't have any problems that'd >> bother me. > > Probably the easiest bugs to fix are those that fail on assertions or > crash. With those you can at least get a stack trace in the debugger > and get some idea of the code path involved. With general rendering > bugs it's often harder to know where to start looking. > > Otherwise, which driver are you using or are you interested in? It's > sometimes easier to focus on one particular area of mesa (such as a > driver, or say the GLSL compiler) than to try to understand everything. > > >> So, could anyone point me to the right direction? Maybe share your >> experience, how did you start, what do you do when you start fixing bugs >> and how should I fix em as a beginner, etc? > > Again, if there's a particular of area of interest to you, start > there. Read the source code. If you find the comments lacking, post > patches to improve the comments as you figure things out. > > There's a terribly out-dated helpwanted.html file in the docs > directory which was intended to list things to be worked on. It would > probably be better if were more active in creating Bugzilla entries > for to-do items that we'd like to do but don't always have time for. > I'm sure we could come up with some easier things for newbies. I > could probably come up with 1 or 2 things pretty quickly... Hello, I also think that it would be very interesting for beginners (like me) that experimented mesa developpers writes some easy (even trivial!) TODO things on the wiki (for instance http://dri.freedesktop.org/wiki/R600ToDo/) or elsewhere. Tasks that you (as experimented) consider very easy, "useless" or with very low priority... for beginners these kind of tasks could already be a hard work to begin with. Regards. Benjamin > > -Brian > > ___ > 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
[Mesa-dev] r600g: status of my work on the shader optimization
Hello, Does your branch should works on R700 ? I tested it on a RV770 but get many corruptions on Counter Strike Source (native). I haven't tested anything else. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r6xx PIPE_CAP_MAX_RENDER_TARGETS
Hello, In src/gallium/drivers/r600/r600_pipe.c I saw this : /* Render targets. */ case PIPE_CAP_MAX_RENDER_TARGETS: /* FIXME some r6xx are buggy and can only do 4 */ return 8; The last line of R6xx_R7xx_3D.pdf says : 4 MRT + 8-Sample Restriction On RV610, there is a maximum of 4 enabled render targets for 8-sample surfaces. Is this related ? I don't know what is 8-sample surfaces... so I don't know if the attached fix is as simple as this. Regards. Benjamin Bellec diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 48b0fe9..a82f9bb 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -398,8 +398,8 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) /* Render targets. */ case PIPE_CAP_MAX_RENDER_TARGETS: - /* FIXME some r6xx are buggy and can only do 4 */ - return 8; + /* On RV610, there is a maximum of 4 enabled render targets for 8-sample surfaces */ + return family == CHIP_RV610 ? 4 : 8; /* Timer queries, present when the clock frequency is non zero. */ case PIPE_CAP_TIMER_QUERY: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Help for a beginner
Le 26/09/2011 20:25, Romain Failliot a écrit : > At first, it would be questions like how to run my own compiled mesa drivers? > I should handle getting the code, compiling it and editing it. > Things I've never done (or almost never) is submitting a patch to a > floss project. I wrote some words on this (in french) here: http://forums.fedora-fr.org/viewtopic.php?id=51681 Its still updated despite the title of the topic. > But the ultimate first question would be: where is the bug tracker? :) https://bugs.freedesktop.org/ Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Help for a beginner
Le 06/10/2011 08:09, Romain Failliot a écrit : > 2011/9/27 Romain Failliot : >> I'll get my hand in the code now. >> Be right back as soon as I can run my own mesa code :) > > Sorry for the delay, I lost my internet connection for a week... > So I started compiling mesa thanks to the site Benjamin Bellec gave to > me http://forums.fedora-fr.org/viewtopic.php?id=51681 > And with this simple command line: > > $ ./autogen.sh --with-gallium-drivers=nouveau --with-dri-drivers= > > Everything went well. (I'm not sure about the empty parameter for the > dri drivers though) > > But my first problem occured: although I changed my LD_LIBRARY_PATH, > graphic drivers are still those from nvidia. Here is the result of the > glxinfo: > > $ glxinfo | grep "OpenGL version string" > OpenGL version string: 2.1.2 NVIDIA 280.13 > > Any idea? Hello Romain. You should ask this kind of question in the related forum instead of in the mesa-dev list ;-) Regards. Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] r600g: add doubles support for CAYMAN
Hello all,
Do you know a game or app using doubles ?
2015-02-20 21:08 GMT+01:00 Ilia Mirkin :
> On Fri, Feb 20, 2015 at 3:07 PM, Ilia Mirkin wrote:
> > On Thu, Feb 19, 2015 at 9:59 PM, Glenn Kennard
> wrote:
> >>> + if ((write_mask & 0x3) != 0x3 &&
> >>> + (write_mask & 0xc) != 0xc) {
> >>> + fprintf(stderr, "illegal writemask for 64-bit: 0x%x\n",
> >>> write_mask);
> >>> + return -1;
> >>> + }
> >
> > I think I noted this on IRC, but did you mean this to be || instead of
> > && ? e.g. right now this will not trigger for a .xyz writemask, since
> > write_mask & 3 == 3.
>
> Oh but it can't be || either, since write_mask == 3 should pass this.
> I guess you want like
>
> if (write_mask & 3 && write_mask & 3 != 3)
> error
> if (writemask & c && writemaks & c != c)
> error
>
> -ilia
> ___
> 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] r600g: Implement GL_ARB_draw_indirect
Hello, You have defined some "define" but you don't use it everywhere, for instance : cs->buf[cs->cdw++] = PKT3(0x24 /* PKT3_DRAW_INDIRECT */, 1, rctx->b.predicate_drawing); instead of simply : cs->buf[cs->cdw++] = PKT3(PKT3_DRAW_INDIRECT, 1, rctx->b.predicate_drawing); There is 5 instances like that. Regards. - Benjamin 2014-11-08 23:52 GMT+01:00 Glenn Kennard : > Requires evergreen/cayman, and updated radeon kernel module. > > Signed-off-by: Glenn Kennard > --- > See also kernel side patch sent to dri-de...@lists.freedesktop.org > > docs/GL3.txt | 4 +- > docs/relnotes/10.4.html | 1 + > src/gallium/drivers/r600/evergreend.h| 7 ++- > src/gallium/drivers/r600/r600_pipe.c | 6 ++- > src/gallium/drivers/r600/r600_state_common.c | 80 > ++-- > 5 files changed, 77 insertions(+), 21 deletions(-) > > diff --git a/docs/GL3.txt b/docs/GL3.txt > index 2854431..06c52f9 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -95,7 +95,7 @@ GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, > radeonsi, llvmpipe, soft > GL 4.0, GLSL 4.00: > >GL_ARB_draw_buffers_blendDONE (i965, nv50, > nvc0, r600, radeonsi, llvmpipe, softpipe) > - GL_ARB_draw_indirect DONE (i965, nvc0, > radeonsi, llvmpipe, softpipe) > + GL_ARB_draw_indirect DONE (i965, nvc0, > r600, radeonsi, llvmpipe, softpipe) >GL_ARB_gpu_shader5 DONE (i965, nvc0) >- 'precise' qualifierDONE >- Dynamically uniform sampler array indices DONE (r600) > @@ -159,7 +159,7 @@ GL 4.3, GLSL 4.30: >GL_ARB_framebuffer_no_attachmentsnot started >GL_ARB_internalformat_query2 not started >GL_ARB_invalidate_subdataDONE (all drivers) > - GL_ARB_multi_draw_indirect DONE (i965, nvc0, > radeonsi, llvmpipe, softpipe) > + GL_ARB_multi_draw_indirect DONE (i965, nvc0, > r600, radeonsi, llvmpipe, softpipe) >GL_ARB_program_interface_query not started >GL_ARB_robust_buffer_access_behavior not started >GL_ARB_shader_image_size not started > diff --git a/docs/relnotes/10.4.html b/docs/relnotes/10.4.html > index d0fbd3b..9c2a491 100644 > --- a/docs/relnotes/10.4.html > +++ b/docs/relnotes/10.4.html > @@ -49,6 +49,7 @@ Note: some of the new features are only available with > certain drivers. > GL_ARB_texture_view on nv50, nvc0 > GL_ARB_clip_control on llvmpipe, softpipe, r300, r600, radeonsi > GL_KHR_context_flush_control on all drivers > +GL_ARB_draw_indirect, GL_ARB_multi_draw_indirect on r600 > > > > diff --git a/src/gallium/drivers/r600/evergreend.h > b/src/gallium/drivers/r600/evergreend.h > index 4989996..b8880c8 100644 > --- a/src/gallium/drivers/r600/evergreend.h > +++ b/src/gallium/drivers/r600/evergreend.h > @@ -64,6 +64,8 @@ > #define R600_TEXEL_PITCH_ALIGNMENT_MASK0x7 > > #define PKT3_NOP 0x10 > +#define PKT3_SET_BASE 0x11 > +#define PKT3_INDEX_BUFFER_SIZE 0x13 > #define PKT3_DEALLOC_STATE 0x14 > #define PKT3_DISPATCH_DIRECT 0x15 > #define PKT3_DISPATCH_INDIRECT 0x16 > @@ -72,12 +74,15 @@ > #define PKT3_REG_RMW 0x21 > #define PKT3_COND_EXEC 0x22 > #define PKT3_PRED_EXEC 0x23 > -#define PKT3_START_3D_CMDBUF 0x24 > +#define PKT3_DRAW_INDIRECT 0x24 > +#define PKT3_DRAW_INDEX_INDIRECT 0x25 > +#define PKT3_INDEX_BASE0x26 > #define PKT3_DRAW_INDEX_2 0x27 > #define PKT3_CONTEXT_CONTROL 0x28 > #define PKT3_DRAW_INDEX_IMMD_BE0x29 > #define PKT3_INDEX_TYPE0x2A > #define PKT3_DRAW_INDEX0x2B > +#define PKT3_DRAW_INDIRECT_MULTI 0x2C > #define PKT3_DRAW_INDEX_AUTO 0x2D > #define PKT3_DRAW_INDEX_IMMD 0x2E > #define PKT3_NUM_INSTANCES 0x2F > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index 0b571e4..829deaf 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -313,6 +313,11 @@ static int r600_get_param(struct pipe_screen* > pscreen, enum pipe_cap param) > return family >= CHIP_CEDAR ? 1 : 0; > case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS: > return family >= CHIP_CEDAR ? 4 : 0; > + case PIPE_CAP_DRAW_INDIRECT: > + /* needs kernel command checking support to work */ > +
Re: [Mesa-dev] rv635 geometry shader texel fetch
Hello, Did you tried with R600_DEBUG=nosb ? Regards. Le 19 nov. 2014 07:18, "Dave Airlie" a écrit : > Hey, > > I got piglit to run on my laptop rv635, > > two things seem to hang it > > geometry shader texel fetches (wierd incorrect values for 2D, hangs for > 2DMS) > and > the clip scissor msaa blits. > > The main wierdness is that texelFetch gs sampler2D is busted, > > you get wierd black lines in the middle of the result, like cache > lines, I wonder if we have some other badly setup geom shader stuff > and it just happens to hang these. > > Dave. > ___ > 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] [RFC 00/20] shader compiler cache
Hello, This patch set prevents me from launching Steam. I'm on r600g (Radeon HD5850 Evergreen). Here is the log : $ MESA_DEBUG=1 LIBGL_DEBUG=1 STEAM_RUNTIME=0 steam Running Steam on fedora 19 64-bit STEAM_RUNTIME is disabled by the user Installing breakpad exception handler for appid(steam)/version(1401381906_client) libGL: Can't open configuration file /home/benjamin/.drirc: Aucun fichier ou dossier de ce type. libGL: Can't open configuration file /home/benjamin/.drirc: Aucun fichier ou dossier de ce type. steam: ../../src/glsl/ralloc.c :84 : get_header: l'assertion « info->canary == 0x5A1106 » a échoué. [2014-06-02 19:39:21] Startup - updater built May 29 2014 09:19:23 Uploading dump (out-of-process) [proxy ''] /tmp/dumps/crash_20140602193921_1.dmp Finished uploading minidump (out-of-process): success = yes response: CrashID=bp-147d1385-d725-4927-9082-1dd942140602 /home/benjamin/.local/share/Steam/steam.sh : ligne 755 : 5546 Abandon (core dumped)$STEAM_DEBUGGER "$STEAMROOT/$PLATFORM/$STEAMEXE" "$@" Installing bootstrap /home/benjamin/.local/share/Steam/bootstrap.tar.xz Reset complete! Restarting Steam by request... Running Steam on fedora 19 64-bit STEAM_RUNTIME is disabled by the user Installing breakpad exception handler for appid(steam)/version(1401381906_client) libGL: Can't open configuration file /home/benjamin/.drirc: Aucun fichier ou dossier de ce type. libGL: Can't open configuration file /home/benjamin/.drirc: Aucun fichier ou dossier de ce type. steam: ../../src/glsl/ralloc.c :84 : get_header: l'assertion « info->canary == 0x5A1106 » a échoué. ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt". [2014-06-02 19:39:25] Startup - updater built Feb 10 2014 16:03:16 Uploading dump (out-of-process) [proxy ''] /tmp/dumps/crash_20140602193925_1.dmp /home/benjamin/.local/share/Steam/steam.sh : ligne 755 : 5645 Abandon (core dumped)$STEAM_DEBUGGER "$STEAMROOT/$PLATFORM/$STEAMEXE" "$@" Finished uploading minidump (out-of-process): success = yes response: CrashID=bp-b11e236c-ada1-4479-84c5-fdd2b2140602 The "canary error" on Google points to a previously closed bug from glsl-compiler : https://bugs.freedesktop.org/show_bug.cgi?id=58039 I can bisect if you need it. Regards. Le 02/06/2014 14:05, Tapani Pälli a écrit : > Hello; > > This series provides a disk cache for the shader compiler and is used > to 'skip glLinkProgram' like GL_ARB_get_program_binary does but under > the hood without api for the client. > > Many of the patches are from my 'GL_ARB_get_program_binary' series and > some were reviewed by Paul earlier. I've tried to split the whole thing > in smaller pieces when possible and added more validation in IR level > and also higher level. Most importantly sizeof(long) and some important > structure sizes must match, otherwise cache gets invalidated. > > There are some new 'uncomfortable' things that Mesa must do when having > a disk cache. This includes directory creation, cache size management > and just general file read/write. Some of these might not have been > written in a portable way (especially patch 20), feedback appreciated. > > This set passes all of other Piglit quick tests but not the transform > feedback tests. I believe most (if not all) of them can be fixed by > having key generation based on some of the variables used for xfb in > gl_shader_program and also serializing xfb related structures but I > have not done this yet as I think the key generation overall would need > some better algorithm based on the gl_shader_program contents (only > those contents which are always same for the same shader program), > would be good to get some feedback for this. Now these contents seem a > bit scattered, hard to generate a key. > > I've limiting the supported set of shaders by having additional checks > during shader serialization. This is simply because of some things may > not be implemented yet or not having good test cases, these will be > improved. > > With the series I get 50% improvement for L4D2 startup (goes down from > 30s to ~15s) This is the time after startup video to menu screen. With > some other apps the improvement varies a lot (as example I measured > ~10% improvement with GLBenchmark 2.7). It would be nice to get some > more test results, especially with modern games. > > The GL_ARB_get_program_binary extension can be implemented easily on > top of this. Also shader backend assembly and other additional data can > be added later as part of the same cache. > > If no objections I would be tempted to start pushing in patches that > were already reviewed as this is a lot of code to carry around. > > Any comments welcome; > > > Tapani Pälli (20): > glsl: memory_writer helper class for data serialization > glsl: glsl_type serialization > glsl: serialize methods for IR instructions > glsl: memory_map helper class for data deserialization > glsl: add MESA_SHADER_CACHE_MAGIC
Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D
Hi, Could you bisect? Or provide an easy way to build ogl-samples! Regards. Le 17/03/2014 15:34, Dieter Nützel a écrit : > Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP. > > /opt/ogl-samples> ./build/release/gl-320-primitive-sprite > libGL: screen 0 does not appear to be DRI3 capable > libGL: pci id for fd 4: 1002:9495, driver r600 > libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so > libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so > libGL: driver does not expose __driDriverGetExtensions_r600(): > /usr/lib/dri/updates/r600_dri.so: undefined symbol: > __driDriverGetExtensions_r600 > libGL: Can't open configuration file /home/dieter/.drirc: No such file > or directory. > libGL: Can't open configuration file /home/dieter/.drirc: No such file > or directory. > OpenGL Version Needed 3.2 ( 3.3 Found ) > OpenGL Error(GL_INVALID_OPERATION): initTexture2D > Running Test > Test Ended > > Worked OK ~10 days ago. > > When I run Mesa 10.1.0 final, it is OK. > > OpenGL vendor string: X.Org > OpenGL renderer string: Gallium 0.4 on AMD RV730 > OpenGL core profile version string: 3.3 (Core Profile) Mesa > 10.2.0-devel (git-7e0396d) > OpenGL core profile shading language version string: 3.30 > OpenGL core profile context flags: (none) > OpenGL core profile profile mask: core profile > OpenGL core profile extensions: > OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d) > OpenGL shading language version string: 1.30 > OpenGL context flags: (none) > OpenGL extensions: > > Thanks, >Dieter > ___ > 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] RFC: per-driver extension lists
Hi, Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is not enabled on Radeon HD2900 (R600 codename) due to hardware limitation. I have no R600 card to check glxinfo. David Airlie enabled this extension with this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8 And current code is still: /* Supported except the original R600. */ case PIPE_CAP_INDEP_BLEND_ENABLE: case PIPE_CAP_INDEP_BLEND_FUNC: /* R600 doesn't support per-MRT blends */ return family == CHIP_R600 ? 0 : 1; Regards. Benjamin Bellec Le 28/03/2014 22:38, Aaron Watry a écrit : > On Fri, Mar 28, 2014 at 10:32 AM, Ilia Mirkin wrote: >> On Fri, Mar 28, 2014 at 11:14 AM, Aaron Watry wrote: >>>> Do people have opinions on whether it'd be useful to also gather data >>>> for older hardware? FWIW I threw my TNT2 in there, which is probably >>>> among the oldest hw supported by mesa. >>>> >>> I'm not sure if it's worthwhile or not, but if you want/need it, I've >>> got a Radeon x1950 at home that I can pop in for a r300g run. >> I'm uncertain of the usefulness, but if you give it to me, I'll throw >> it up there. > I'll give it a run on a spare system later. Probably mesa 10.1, but > I'll have to see what's installed on that machine when I get home. > >>>> Any other suggestions? As a reminder, the current list is available at >>>> http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html (defaults >>>> to core context, so older stuff doesn't show up, click on 'compat' to >>>> see it). >>>> >>> I like the UI in general, the one suggestion that I have at the moment >>> is to split into two divs. Anchor the driver >>> names/generations to the top of the window (position:fixed) and allow >>> the table content to continue to be scrolled. That way you always >>> have the card names at the top of your screen. You'll probably need >>> to add a dynamically-sized spacer to the top of the 2nd div, but I'll >>> leave that as an exercise to the reader. >> Good idea. One problem with position:fixed is that it doesn't >> (didn't?) work on mobile browsers. I'll give it a shot though. > Ahh, yeah... I haven't tried it on mobile... I spend my days doing > desktop web software, not mobile. If it works, great, if not, then > it's not the end of the world.. > >> -ilia > ___ > 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] RFC: per-driver extension lists
I tried to get some data in the Phoronix forum, without success for the moment: http://www.phoronix.com/forums/showthread.php?98234-Can-someone-provides-me-an-glxinfo-output-of-Radeon-HD2900-series-%28R600%29 Maybe we should ask Michael Larabel to write an appeal to witnesses :-) That said, is this extension is mandatory do be "OpenGL 3.0 compliant"? (I don't know how really works the OpenGL specification) Does the R600 cards can expose GL3.0 in glxinfo without this extension? Benjamin Le 31/03/2014 20:43, Ilia Mirkin a écrit : > On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec wrote: >> Hi, >> >> Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is >> not enabled on Radeon HD2900 (R600 codename) due to hardware limitation. >> I have no R600 card to check glxinfo. >> >> David Airlie enabled this extension with this commit: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8 >> >> And current code is still: >> /* Supported except the original R600. */ >> case PIPE_CAP_INDEP_BLEND_ENABLE: >> case PIPE_CAP_INDEP_BLEND_FUNC: >> /* R600 doesn't support per-MRT blends */ >> return family == CHIP_R600 ? 0 : 1; > That seems likely, given the code :) I'll be happy to split up the > R600/R700 columns should I get a R600 glxinfo output (in case there > are further discrepancies, best to go off the "real thing" rather than > hand-editing). I believe the one I have now is from a RV770 which is a > R700. > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: per-driver extension lists
As Alex said, this is more like : R600/R700* support GL3.3. * except original R600 (Radeon HD 2900 series). I don't know if this can be easily added in your tool or it's even important to say here. But I think this information should be mentioned somewhere (on the RadeonFeature web page at least). And is your tool strictly from a Mesa perspective? I mean, for instance, GL3.3 is only supported for R600/R700 with kernel 3.14. Before, only GL3.1 is exposed. This information is - indirectly - noted on RadeonFeature web page though. Benjamin Le 31/03/2014 20:43, Ilia Mirkin a écrit : > On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec wrote: >> Hi, >> >> Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is >> not enabled on Radeon HD2900 (R600 codename) due to hardware limitation. >> I have no R600 card to check glxinfo. >> >> David Airlie enabled this extension with this commit: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8 >> >> And current code is still: >> /* Supported except the original R600. */ >> case PIPE_CAP_INDEP_BLEND_ENABLE: >> case PIPE_CAP_INDEP_BLEND_FUNC: >> /* R600 doesn't support per-MRT blends */ >> return family == CHIP_R600 ? 0 : 1; > That seems likely, given the code :) I'll be happy to split up the > R600/R700 columns should I get a R600 glxinfo output (in case there > are further discrepancies, best to go off the "real thing" rather than > hand-editing). I believe the one I have now is from a RV770 which is a > R700. > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] add a bugfix in 10.2 release notes
Signed-off-by: Benjamin Bellec diff --git a/docs/relnotes/10.2.html b/docs/relnotes/10.2.html index da79e7d..05fd502 100644 --- a/docs/relnotes/10.2.html +++ b/docs/relnotes/10.2.html @@ -51,7 +51,11 @@ Note: some of the new features are only available with certain drivers. Bug fixes -TBD. + + +https://bugs.freedesktop.org/show_bug.cgi?id=71138";>Bug 71138 - flashlight bug in L4D2 + + Changes ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] add a bugfix in 10.2 release notes
Oh OK, I wasn't aware of this process and script. That said, the commit that fixed the bug was not intended to. And it will not be caught by the script. Noted for git send-email. Benjamin Le 11/04/2014 20:24, Emil Velikov a écrit : > On 11/04/14 19:07, Benjamin Bellec wrote: >> Signed-off-by: Benjamin Bellec >> > Hi Benjamin, > > The bugfixes section is generated as part of the release process, and is > automated via the bin/bugzilla_mesa.sh script, so I do not think that "we're > ready" for this patch yet :) > > For a future reference can you please send patches via git send-email - this > way people can easily reply in-line with questions/comments that they may > have. > > Thanks > -Emil > >> >> ___ >> 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] Heavy ioq3 regression in mesa (r600g/cayman/aruba)
Hi Lauri, I tested with both commit but cannot seeing something relevant, I got 60 FPS in both case. I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6 (from Fedora 19 repo). The command used (for both commit) was: $ vblank_mode=0 R600_DEBUG=nohyperz phoronix-test-suite Test pts/tremulous I have a Radeon HD5850 (with 1 GB VRAM). Any idea to try to spot your issue? (decrease VRAM size?) Regards. Benjamin Le 15/04/2014 09:35, Lauri Kasanen a écrit : > Hi, > > Tremulous and Smoking Guns regressed in Mesa master, ok in 020c43f, > broken in 4ddf51db. > > Tremulous 133 to 33 fps, Smoking Guns 153 to 40. In the ok version, > hyperz was enabled by default; in the more recent master, it was > disabled by default, but enabled via the R600_DEBUG env var. The env > var applied correctly, because other games' perf reacted to it. > > This is a week old master, so it might be fixed already; just in case > it's not, I thought I'd report this, as a release is about to be > branched. Wouldn't do to have 4x regressions in a release ;) > > Anyway, that's a fairly wide area to bisect, and I'm busy with other > things, so just this email instead of a bug and a bisect. > > - Lauri > ___ > 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] Heavy ioq3 regression in mesa (r600g/cayman/aruba)
I disabled vsync and tested with Tremulous. I didn't see any regression on my system, I got 256-257 FPS with or without HyperZ, with this 2 commits and also current master (git-352e06d). So it doesn't hit Evergreen at least. Le 18/04/2014 09:20, Lauri Kasanen a écrit : > On Fri, 18 Apr 2014 10:16:53 +0300 > Lauri Kasanen wrote: > >> On Fri, 18 Apr 2014 01:41:46 +0200 >> Benjamin Bellec wrote: >> >>> Hi Lauri, >>> >>> I tested with both commit but cannot seeing something relevant, I got 60 >>> FPS in both case. >>> I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6 >>> (from Fedora 19 repo). >>> >>> The command used (for both commit) was: >>> $ vblank_mode=0 R600_DEBUG=nohyperz phoronix-test-suite Test pts/tremulous >>> >>> I have a Radeon HD5850 (with 1 GB VRAM). >>> >>> Any idea to try to spot your issue? (decrease VRAM size?) >> Hi, >> >> It was visible at all VRAM sizes (both 256mb limited, and 768mb full). >> I also used hyperz to rule it out, ie >> >> R600_DEBUG=hyperz phoronix-test-suite run pts/tremulous pts/smokingguns >> >> It's possible this bug only affects Cayman and/or APUs. Though just >> recently a similar ioq3 regression was reported on Intel. > PS: Please disable swapbufferswait in xorg.conf so you're not limited > to 60fps. PTS passes vblank_mode by itself. > > - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fix GetStringi error message with correct name function
Signed-off-by: Benjamin Bellec --- src/mesa/main/getstring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c index 3ac62d4..1ac92e2 100644 --- a/src/mesa/main/getstring.c +++ b/src/mesa/main/getstring.c @@ -166,7 +166,7 @@ _mesa_GetStringi(GLenum name, GLuint index) } return _mesa_get_enabled_extension(ctx, index); default: - _mesa_error( ctx, GL_INVALID_ENUM, "glGetString" ); + _mesa_error( ctx, GL_INVALID_ENUM, "glGetStringi" ); return (const GLubyte *) 0; } } -- 1.8.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-users] Problem with ARB_copy_buffer on Mesa 9.2.4
Hello Jonas,
I tested your program and on my system (Fedora 19) on an Evergreen
(Radeon HD 5850) and I have the same issue indeed.
Here is my result :
Mesa 9.2.4 (from F19 repo) => Data does NOT match up!
Mesa 9.2.5 => Data does NOT match up!
Mesa 10.0.5 => Data does NOT match up!
Mesa 10.1.0 => Data matches.
So this is fixed in newer version.
That said, Mesa 9.2 is not supported anymore and I really don't know if
there will be a new Mesa 10.0.x release given the imminence of Mesa 10.2.
If yes, I can bisect and you can open a bug.
Mesa-dev, any new 10.0.x release planned ?
Regards.
Benjamin
Le 06/05/2014 13:40, Jonas Kulla a écrit :
> Hello list,
>
> after about 3 days of debugging, I was able to isolate a rather weird
> behavior in Mesa GL.
> The gist of it is the following: When I create a buffer object and
> allocate uninitilaized
> memory for it (glBufferData() with nullptr as 'data'),
> then glCopyBufferSubData() data into
> it from another buffer object, then subsequently fill a part of it
> with glBufferSubData(),
> this new data isn't visible to the buffer object. In fact, it seems
> that the SubData'ed bytes
> are completely lost. Any further data uploads however work as
> expected. I will attach
> a small C test case below that demonstrates this behavior.
>
> I realize that I am working with an old Mesa release (on Fedora 19),
> but I'm afraid of
> upgrading my system to the newest distro release as I might break my
> working environment.
> That's why I would like to kindly ask if someone could verify that
> this problem still persists
> on the newest Mesa code, in which case I would go ahead and file a bug
> report. At the
> same time, maybe someone could spot a critical mistake in my code that
> would explain
> this strange behavior I'm seeing. I think the code paths I'm hitting
> here in the driver are
> sufficiently obscure though.
>
> I should probably mention that my card is a Mobility Radeon HD 3650
> (ie. r600).
>
> Here's the code sample (you can replace the GL setup code with your own):
>
> #include
> #include
>
> #include
> #include
>
> static SDL_Window *win;
> static SDL_GLContext *ctx;
>
> void setupGL()
> {
> SDL_Init(SDL_INIT_VIDEO);
> win = SDL_CreateWindow("CopyBufferBug",
> SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 64, 64,
> SDL_WINDOW_OPENGL);
> ctx = SDL_GL_CreateContext(win);
> glewInit();
> }
>
> static void teardownGL()
> {
> SDL_GL_DeleteContext(ctx);
> SDL_DestroyWindow(win);
>
> SDL_Quit();
> }
>
> int main(int argc, char *argv[])
> {
> setupGL();
>
> /* These don't matter I think */
> #define BLOCK_SIZE 128
> #define BUFFER1_SIZE BLOCK_SIZE
> #define BUFFER2_SIZE BLOCK_SIZE
> #define BUFFER1_TARGET GL_COPY_READ_BUFFER
> #define BUFFER2_TARGET GL_COPY_WRITE_BUFFER
> #define BUFFER1_USAGE GL_DYNAMIC_DRAW
> #define BUFFER2_USAGE GL_DYNAMIC_DRAW
>
> GLuint buffers[2];
> glGenBuffers(2, buffers);
>
> /* We allocate both buffers with undefined memory */
> glBindBuffer(BUFFER1_TARGET, buffers[0]);
> glBufferData(BUFFER1_TARGET, BUFFER1_SIZE, 0, BUFFER1_USAGE);
>
> glBindBuffer(BUFFER2_TARGET, buffers[1]);
> glBufferData(BUFFER2_TARGET, BUFFER2_SIZE, 0, BUFFER2_USAGE);
>
> /* Then copy (undefined) bytes from the first into the second
> buffer */
> /* Note: If I comment this line out, everything works */
> glCopyBufferSubData(BUFFER1_TARGET, BUFFER2_TARGET, 0, 0,
> BUFFER1_SIZE);
>
> /* Generate random string */
> FILE *rand = fopen("/dev/urandom", "r");
> char data[BLOCK_SIZE];
> fread(data, 1, sizeof(data), rand);
> fclose(rand);
>
> /* We fill the second buffer with defined data */
> /* Note: If I execute this call twice (just copy paste the
> line), everything works */
> glBufferSubData(BUFFER2_TARGET, 0, sizeof(data), data);
>
> /* Then download it again to compare its contents against our
> test string */
> char data2[BLOCK_SIZE];
> glGetBufferSubData(BUFFER2_TARGET, 0, sizeof(data2), data2);
>
> if (memcmp(data, data2, sizeof(data)))
> printf("Data does NOT match up!\n");
> else
> printf("Data matches.\n");
>
> glDeleteBuffers(2, buffers);
>
> teardownGL();
>
> return 0;
> }
>
> Thank you very much for your time.
> Jonas
>
>
> ___
> mesa-users mailing list
> mesa-us...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-users
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa fails to build (32 bit chroot on 64 bit machine)
Hello, This error is due to the recent removal of "--disable-64-bit" and "--enable-32-bit" options. You should now replace them by "--build=i686-pc-linux-gnu" and "--host=i686-pc-linux-gnu" See here : http://lists.freedesktop.org/archives/mesa-dev/2014-August/065574.html - Benjamin Le 17/08/2014 23:00, Kertesz Laszlo a écrit : > Hello. > I have an issue building mesa on a 32 bit chroot. Compiling fails with > the below messages (the Error ones repeated 9000+ times): > > /tmp/ccvEhPCW.s: Assembler messages: > /tmp/ccvEhPCW.s:13: Error: bad register name `%rip)' > /tmp/ccvEhPCW.s:14: Error: bad register name `%rax)' > /tmp/ccvEhPCW.s:15: Error: bad register name `%r11)' > /tmp/ccvEhPCW.s:21: Error: bad register name `%rip)' > /tmp/ccvEhPCW.s:22: Error: bad register name `%rax)' > /tmp/ccvEhPCW.s:23: Error: bad register name `%r11)' > /tmp/ccvEhPCW.s:29: Error: bad register name `%rip)' > /tmp/ccvEhPCW.s:30: Error: bad register name `%rax)' > > I built mesa before with the very same config file 2 days ago. What > could be wrong? > > Note: 64 bit builds fine. > mesa build script: > > #!/bin/bash > ./autogen.sh --sysconfdir=/etc --prefix=/usr \ > LDFLAGS="-L/usr/lib/i386-linux-gnu -L/usr/lib > -L/usr/local/lib/llvm32/lib" \ > --disable-64-bit --enable-32-bit \ > --libdir=/usr/lib/i386-linux-gnu --enable-debug \ > --enable-texture-float \ > --with-gallium-drivers=r600,swrast,radeonsi \ > --with-dri-drivers="" \ > --enable-vdpau \ > --enable-egl --enable-gles1 --enable-gles2 \ > --enable-glx-tls \ > --with-egl-platforms=x11,drm \ > --enable-gbm \ > --enable-gallium-egl \ > --enable-gallium-osmesa \ > --with-osmesa-bits=32 \ > --disable-dri3 \ > --enable-shared-glapi \ > --enable-gallium-llvm \ > --enable-r600-llvm-compiler \ > --disable-llvm-shared-libs \ > --with-llvm-prefix=/usr/local/lib/llvm32 \ > CPPFLAGS="-m32" \ > CXXFLAGS="-m32" \ > LDFLAGS="-ltinfo -lpthread -ldl" > > Its a bit messed up, but it was working before in this exact form (i > build llvm too and static link agains it). Debian Testing 64 bit. > > -- > O zi buna, > Kertesz Laszlo > > > ___ > 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
[Mesa-dev] RadeonProgram webpage access
Hello, I would like to have an access to the RadeonProgram web page (http://www.x.org/wiki/RadeonProgram/) in order to update and improve it. I requested this access 9 months ago to jrayh...@freedesktop.org and tfh...@freedesktop.org and still have no access. - Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
No problem with Valley on Evergeen (CYPRESS). Unigine Valley 1.0 (64-bit) Basic preset without "forcedma" : Benchmark results: Time:188.792 Frames:9194 FPS:48.6992 Min FPS:20.5505 Max FPS:78.946 Score:2037.5 Unigine Valley 1.0 (64-bit) Basic preset with "forcedma" : Benchmark results: Time:188.915 Frames:9180 FPS:48.5934 Min FPS:24.7402 Max FPS:77.8441 Score:2033.15 2014-09-06 19:15 GMT+02:00 Andy Furniss : > Andy Furniss wrote: > >> Marek Olšák wrote: >> >>> From: Marek Olšák >>> >>> --- >>> >>> Turn this on, run piglit, and pray for mercy. >>> It might be interesting to see if it makes 3D apps any faster. Or piglit. >>> >> >> Well it's not piglit and I haven't benchmarked anything yet, but I get a >> couple of faults at the start of Unigine Valley. >> > > Forgot to put h/w is pitcairn - R9 270X > > > > ___ > 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] r600g, radeonsi: add debug option which forces DMA for copy_region and blit
Oh you're right. With the Extreme preset, the sun's lens flare are buggy. Other than that, it seems to work. And I get this kernel errors : [23018.037267] radeon :01:00.0: DMA L2L, dw src buffer too small (2097152 524288) [23018.037270] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! 2014-09-07 22:47 GMT+02:00 Andy Furniss : > Benjamin Bellec wrote: > >> No problem with Valley on Evergeen (CYPRESS). >> >> Unigine Valley 1.0 (64-bit) Basic preset without "forcedma" : >> > > It doesn't produce them on basic for me - so maybe if you try a higher > setting. > > It still runs after producing the errors, though for me valley is very > glitchy. I get time stopping pauses is it smooth for you? > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [r600g + s3tc] bug or missing kernel piece of software ?
Hello, I have compiled the last Mesa code (and libtxc_dxtn from Marek Olšák's branch) in order to test the S3TC support recently pushed in r600g. In his commit (http://cgit.freedesktop.org/mesa/mesa/commit/?id=8e0437914bb786d0b05be8f95e4ff37bf5a19f44), Dave Airlie says "Still requires R600_ENABLE_S3TC until the kernel fixes are in, this has only been tested on evergreen where the kernel doesn't yet get in the way." My GPU is a RV770 (Radeon 4850) and I have some mitigated results within Enemy Territory Quake Wars, so should I file a bug or wait for a kernel piece of software ? And if so which one ? (I'm currently on 2.6.38-rc8). Benjamin Bellec ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g and S3TC
You must use kernel 2.6.39. And then R600_ENABLE_S3TC is not useful anymore. Le 07/04/2011 21:35, Alexandre Demers a écrit : Hi all, A simple question: is enabling S3TC supposed to work with latest git on r600g? I'm using latest git and kernel 2.6.38.2. Libdrm is 2.4.24+ (git from a couple of days). Libtxc_dxtn is latest version available from git. When I try R600_ENABLE_S3TC=1 RendererFeatTest.bin64, I only see garbage (automatic screenshots from the application are all black). If I don't use the flag, the extension is disabled and RendererFeatTest works as usual (still as some issues compared to another driver like i915 though like no background and crippled text). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.
Le 18/04/2011 10:20, Dave Airlie a écrit : > On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie wrote: >> From: Dave Airlie >> >> This is a first step to decreasing the CPU usage, by decreasing how much >> stuff we pass to the GPU and hence to the kernel CS checker. >> >> This adds a check to see if the values we need to write are actually dirty, >> and avoids writing if they are. However certain register need to always >> be written so we add a new flag to say which ones should be always written >> if used. (Note this could probably be done cleaner with a larger refactoring, >> since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might >> be better off as a special state). >> >> It also moves the need_bo to be a flags on the register now. >> >> With this, a frame of gears goes from emitting 3k dwords to emitting 2k >> dwords, >> and I'm sure it could get a lot smaller. >> >> TODO: >> Currently we flush if we have a BO, this could probably be improved. >> Drop the special flush flag and move the buffer size ps/vs to a special >> state. >> > > I've pushed a v2 of this to the r600g-dirty branch in my repo with > another couple of patches on top > > the v2 just fixes the evergreen paths. > > The other patches cause regressions, but decrease further the amount > of dwords per frame which should decrease time in the kernel parser, > just have to figure out the regressions. > > Dave. > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev Hello, I just test your branch, it breaks the 3 apps I tested : - glxgears, I do not see gears. I can see them quickly by moving the window at the border of my screen - nexuiz-sdl : the menu is break. (not tested ingame) - etqw : the menu is break too. In game, I have "phantom" frame. This is hard to describe, and I have no screenshots to show you exactly. To sum up, I have the impression that the frames are mixed. I will test your future patches (if any). Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.
Le 18/04/2011 16:37, Benjamin BELLEC a écrit : > Le 18/04/2011 10:20, Dave Airlie a écrit : >> On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie wrote: >>> From: Dave Airlie >>> >>> This is a first step to decreasing the CPU usage, by decreasing how much >>> stuff we pass to the GPU and hence to the kernel CS checker. >>> >>> This adds a check to see if the values we need to write are actually dirty, >>> and avoids writing if they are. However certain register need to always >>> be written so we add a new flag to say which ones should be always written >>> if used. (Note this could probably be done cleaner with a larger >>> refactoring, >>> since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might >>> be better off as a special state). >>> >>> It also moves the need_bo to be a flags on the register now. >>> >>> With this, a frame of gears goes from emitting 3k dwords to emitting 2k >>> dwords, >>> and I'm sure it could get a lot smaller. >>> >>> TODO: >>> Currently we flush if we have a BO, this could probably be improved. >>> Drop the special flush flag and move the buffer size ps/vs to a special >>> state. >>> >> >> I've pushed a v2 of this to the r600g-dirty branch in my repo with >> another couple of patches on top >> >> the v2 just fixes the evergreen paths. >> >> The other patches cause regressions, but decrease further the amount >> of dwords per frame which should decrease time in the kernel parser, >> just have to figure out the regressions. >> >> Dave. >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > Hello, > > I just test your branch, it breaks the 3 apps I tested : > > - glxgears, I do not see gears. I can see them quickly by moving the > window at the border of my screen > - nexuiz-sdl : the menu is break. (not tested ingame) > - etqw : the menu is break too. In game, I have "phantom" frame. This is > hard to describe, and I have no screenshots to show you exactly. To sum > up, I have the impression that the frames are mixed. > > I will test your future patches (if any). > > Benjamin All is now fixed. Also, I have 15.50 % of framerate improvements in nexuiz-sdl on my system (x86 - RV770 - 1680*1050 - No HDR - No sound) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glewinfo vs piglit
Hello, I have a simple question. If a feature is exposed by Mesa (checked by glewinfo), but piglit tests about this extension fails, is it a bug which must be reported ? Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Optimize logbase2() function
Hello,
I performed several tests of the logbase2() function.
This function is defined and used in these files:
src/mesa/main/teximage.c
src/mesa/drivers/dri/intel/intel_tex_image.c
src/mesa/drivers/dri/unichrome/via_tex.c
src/mesa/drivers/dri/i965/intel_tex_image.c
src/mesa/drivers/dri/tdfx/tdfx_tex.c
There is also a util_logbase2() function in
src/gallium/auxiliary/util/u_math.c which do the same thing.
Both functions from "src/mesa/main/teximage.c" and
"src/gallium/auxiliary/util/u_math.c" are called when I play to ETQW
with r600g.
First thing: is it possible to merge this function in one place? The
same function is implement in different place. I have no sufficient
experience of the Mesa architecture to answer this myself.
Second thing: there is a C implementation in Wikipedia (
http://en.wikipedia.org/wiki/Binary_logarithm#Algorithm ), I merged it
in Mesa and I noted that it is *at least* twice faster than logbase2()
and util_logbase2() (with or without GCC optimization).
Third thing: I think it's better to use an unsigned int than a int for
the logbase2's parameter. At least in "teximage.c" and
"intel_tex_image.c", the result is stored in a GLuint. But not in
"via_tex.c"
Here is a patch to merge it, at least in "src/mesa/main/teximage.c". I
will understand any comments, especially on the relevance of this patch.
(The patch still uses a integer parameter).
Regards.
Benjamin Bellec
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4ea9a48..e2eeaa0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -81,31 +81,25 @@ _mesa_free_texmemory(void *m)
/*
- * Compute floor(log_base_2(n)).
+ * Returns the floor form of binary logarithm for a 32 bit integer.
* If n < 0 return -1.
*/
static int
logbase2( int n )
{
- GLint i = 1;
- GLint log2 = 0;
+ if (n == 0)
+ return 0;
if (n < 0)
return -1;
- if (n == 0)
- return 0;
-
- while ( n > i ) {
- i *= 2;
- log2++;
- }
- if (i != n) {
- return log2 - 1;
- }
- else {
- return log2;
- }
+ int pos = 0;
+ if (n >= 1<<16) { n >>= 16; pos += 16; }
+ if (n >= 1<< 8) { n >>= 8; pos += 8; }
+ if (n >= 1<< 4) { n >>= 4; pos += 4; }
+ if (n >= 1<< 2) { n >>= 2; pos += 2; }
+ if (n >= 1<< 1) { pos += 1; }
+ return pos;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] faster util_next_power_of_two() function
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]".
Regards.
Benjamin Bellec
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..7d260ae 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -486,24 +486,44 @@ util_logbase2(unsigned n)
return pos;
}
-
/**
* Returns the smallest power of two >= x
*/
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
-
- if (x == 0)
- return 1;
-
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ unsigned val = x;
+
+ switch (x)
+ {
+ case 1:
+ case 2:
+ case 4:
+ case 8:
+ case 16:
+ case 32:
+ case 64:
+ case 128:
+ case 256:
+ case 512:
+ case 1024:
+ case 2048:
+ case 4096:
+ return x; /* this is the most commonly used values */
+ case 0:
+ return 1;
+ default:
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ if (sizeof(unsigned) == 8)
+val = (val >> 32) | val;
+ val++;
+ return val;
+ }
}
___
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
Le 03/06/2011 01:40, Brian Paul a écrit :
> 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?
Yes it fix, but as Matt Turner said, it's not necessary to check this.
Btw we don't check that in the other functions.
Le 03/06/2011 06:09, Matt Turner a écrit :
> Also, if you want to check if the value is already a power-of-two,
> instead of a case statement for every POT (including 0), just do the
> standard is-power-of-two check:
>
> (x & (x - 1)) == 0
My own tests (on a Core2) shows that it's less efficient to do that, at
least with -O2 optimization enabled. With -O0, it's equal.
So here is a v2 patch with a builtin GCC optimization which is the
fastest (thx Matt to point me to this solution).
Regards.
Benjamin Bellec
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..1b984b6 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -42,7 +42,6 @@
#include "pipe/p_compiler.h"
#include "util/u_debug.h"
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -486,24 +485,49 @@ util_logbase2(unsigned n)
return pos;
}
-
/**
* Returns the smallest power of two >= x
*/
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
-
+#if defined(PIPE_CC_GCC)
if (x == 0)
return 1;
-
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ else
+ return (1 << (32 - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
+
+ switch (x)
+ {
+ case 1:
+ case 2:
+ case 4:
+ case 8:
+ case 16:
+ case 32:
+ case 64:
+ case 128:
+ case 256:
+ case 512:
+ case 1024:
+ case 2048:
+ case 4096:
+ return x; /* this is the most commonly used values */
+ case 0:
+ return 1;
+ default:
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+ }
+#endif
}
___
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
Le 05/06/2011 03:05, Matt Turner a écrit :
> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote:
>> Le 03/06/2011 06:09, Matt Turner a écrit :
>>> Also, if you want to check if the value is already a power-of-two,
>>> instead of a case statement for every POT (including 0), just do the
>>> standard is-power-of-two check:
>>>
>>> (x & (x - 1)) == 0
>>
>> My own tests (on a Core2) shows that it's less efficient to do that, at
>> least with -O2 optimization enabled. With -O0, it's equal.
>
> For what input set? Powers of two?
Both, my test case loops with 29 POT and 6 NPOT.
I'm doing this because the OpenGL games that I have tested call the
function more often with "good" values.
>
> Doesn't really matter, since the function isn't a hot path or
> anything, but I'd suppose that the Linux kernel has its
> is_power_of_2() function for a reason--that it's pretty ugly to have
> lots of case statements like powers of two.
>
> Matt
Ok, so here is a v3 patch which replace the switch statement.
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..f37d9cc 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,30 @@ util_logbase2(unsigned n)
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
+#if defined(PIPE_CC_GCC)
+ if (x == 0)
+ return 1;
+ else
+ return (1 << (32 - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
if (x == 0)
return 1;
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ /* check if x is already a power of two */
+ if ((x & (x - 1)) == 0)
+ return x;
+
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+#endif
}
___
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
Le 06/06/2011 17:34, Roland Scheidegger a écrit : > Am 05.06.2011 03:55, schrieb Benjamin Bellec: >> Le 05/06/2011 03:05, Matt Turner a écrit : >>> On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec wrote: >>>> Le 03/06/2011 06:09, Matt Turner a écrit : >>>>> Also, if you want to check if the value is already a power-of-two, >>>>> instead of a case statement for every POT (including 0), just do the >>>>> standard is-power-of-two check: >>>>> >>>>> (x & (x - 1)) == 0 >>>> >>>> My own tests (on a Core2) shows that it's less efficient to do that, at >>>> least with -O2 optimization enabled. With -O0, it's equal. >>> >>> For what input set? Powers of two? >> Both, my test case loops with 29 POT and 6 NPOT. >> I'm doing this because the OpenGL games that I have tested call the >> function more often with "good" values. >> >>> >>> Doesn't really matter, since the function isn't a hot path or >>> anything, but I'd suppose that the Linux kernel has its >>> is_power_of_2() function for a reason--that it's pretty ugly to have >>> lots of case statements like powers of two. >>> >>> Matt >> Ok, so here is a v3 patch which replace the switch statement. > > I like this one better too. > Do we actually need the x == 0 special case or would it be ok if we just > remove that (which will return 0)? > > Roland If we delete this check, we need to specify (in a comment) that the function have an undetermined behavior when passing 0 in parameters. Why not, but then the most important thing to know is from where the parameters came from: "mesa" or "GL apps"? If it's from GL apps it could be dangerous to change the result of this function, even if 0 is a stupid input (no?). Benjamin ___ 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
Le 06/06/2011 23:54, Roland Scheidegger a écrit :
> Am 06.06.2011 23:18, schrieb Tormod Volden:
>> On Sun, Jun 5, 2011 at 1:14 AM, Benjamin Bellec wrote:
>>> So here is a v2 patch with a builtin GCC optimization which is the
>>> fastest (thx Matt to point me to this solution).
>>>
>>
>> From patch:
>> + return (1 << (32 - __builtin_clz(x - 1)));
>>
>> I don't know if the use of gcc guarantees that int will always be 32
>> bit, otherwise maybe use sizeof(int)*8 instead of 32? Or even
>> sizeof(int)*CHAR_BIT for good measures. Although probably the robots
>> have taken over before this becomes necessary :)
>>
>
> Hmm I think a lot more things will break if that's not 32bit.
> There's another problem though, gcc docs say this:
>
> — Built-in Function: int __builtin_clz (unsigned int x)
>
> Returns the number of leading 0-bits in x, starting at the most
> significant bit position. If x is 0, the result is undefined.
>
> Which means it's now undefined for x == 1 too - not handling x == 0
> correctly might not be much of a problem in practice, but the same
> certainly cannot be said for x == 1. So that should probably be
>
> +#if defined(PIPE_CC_GCC)
> + if (x <= 1)
> + return 1;
> + else
> + return (1 << (32 - __builtin_clz(x - 1)));
>
>
> Also I believe this builtin requires gcc 3.4 - not sure though if the
> rest of the code compiles on older gcc.
>
> Roland
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Here is the v4 patch.
Benjamin
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..93ac012 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,29 @@ util_logbase2(unsigned n)
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
+#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 340)
+ if (x <= 1)
+ return 1;
+ else
+ return (1 << ((sizeof(unsigned) * 8) - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
- if (x == 0)
+ if (x <= 1)
return 1;
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ if (util_is_power_of_two(x))
+ return x;
+
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+#endif
}
___
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
Le 06/06/2011 23:54, Roland Scheidegger a écrit : > Also I believe this builtin requires gcc 3.4 - not sure though if the > rest of the code compiles on older gcc. > > Roland Yes I checked, __builtin_clz() appeared first time in GCC 3.4.0 documentation. Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] faster logbase2() - again
On a Roland Scheidegger idea!
Benjamin
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 3e42911..da2e72f 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -86,6 +86,12 @@ _mesa_free_texmemory(void *m)
static GLuint
logbase2(GLuint n)
{
+#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 340)
+ if (n <= 1)
+ return 0;
+
+ return (31 - __builtin_clz(n | 1));
+#else
GLuint pos = 0;
if (n >= 1<<16) { n >>= 16; pos += 16; }
if (n >= 1<< 8) { n >>= 8; pos += 8; }
@@ -93,6 +99,7 @@ logbase2(GLuint n)
if (n >= 1<< 2) { n >>= 2; pos += 2; }
if (n >= 1<< 1) { pos += 1; }
return pos;
+#endif
}
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..cde9c92 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -477,6 +477,12 @@ float_to_byte_tex(float f)
static INLINE unsigned
util_logbase2(unsigned n)
{
+#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 340)
+ if (n <= 1)
+ return 0;
+
+ return (31 - __builtin_clz(n | 1));
+#else
unsigned pos = 0;
if (n >= 1<<16) { n >>= 16; pos += 16; }
if (n >= 1<< 8) { n >>= 8; pos += 8; }
@@ -484,6 +490,7 @@ util_logbase2(unsigned n)
if (n >= 1<< 2) { n >>= 2; pos += 2; }
if (n >= 1<< 1) { pos += 1; }
return pos;
+#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] faster logbase2() - again
Le 08/06/2011 22:08, Roland Scheidegger a écrit :
> Looks good to me - but skip the special n <= 1 case that's what the
> (n|1) input to the __builtin_clz is good for.
Ok, I'm not familiar with bit manipulation in fact...
> Oh and I didn't notice before but there's an error in the gcc version
> check (as that's defined as (__GNUC__ * 100 + __GNUC_MINOR__) - we're
> ignoring patchlevel). Though as said there's the popcount usage right
> next to it which doesn't do a version check neither - if that's the only
> thing requiring gcc 3.4 we should fix that otherwise could just make gcc
> 3.4 a requirement.
Ok I did'nt know that.
Here is my 3 patchs fixed. I hope this are the last of the series :-)
Benjamin
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..9d82cc5 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,29 @@ util_logbase2(unsigned n)
static INLINE unsigned
util_next_power_of_two(unsigned x)
{
- unsigned i;
+#if defined(PIPE_CC_GCC)
+ if (x <= 1)
+ return 1;
+
+ return (1 << ((sizeof(unsigned) * 8) - __builtin_clz(x - 1)));
+#else
+ unsigned val = x;
- if (x == 0)
+ if (x <= 1)
return 1;
- --x;
-
- for (i = 1; i < sizeof(unsigned) * 8; i <<= 1)
- x |= x >> i;
-
- return x + 1;
+ if (util_is_power_of_two(x))
+ return x;
+
+ val--;
+ val = (val >> 1) | val;
+ val = (val >> 2) | val;
+ val = (val >> 4) | val;
+ val = (val >> 8) | val;
+ val = (val >> 16) | val;
+ val++;
+ return val;
+#endif
}
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..294f964 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -477,6 +477,9 @@ float_to_byte_tex(float f)
static INLINE unsigned
util_logbase2(unsigned n)
{
+#if defined(PIPE_CC_GCC)
+ return (31 - __builtin_clz(n | 1));
+#else
unsigned pos = 0;
if (n >= 1<<16) { n >>= 16; pos += 16; }
if (n >= 1<< 8) { n >>= 8; pos += 8; }
@@ -484,6 +487,7 @@ util_logbase2(unsigned n)
if (n >= 1<< 2) { n >>= 2; pos += 2; }
if (n >= 1<< 1) { pos += 1; }
return pos;
+#endif
}
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 3e42911..6ca1bd9 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -86,6 +86,9 @@ _mesa_free_texmemory(void *m)
static GLuint
logbase2(GLuint n)
{
+#if defined(PIPE_CC_GCC)
+ return (31 - __builtin_clz(n | 1));
+#else
GLuint pos = 0;
if (n >= 1<<16) { n >>= 16; pos += 16; }
if (n >= 1<< 8) { n >>= 8; pos += 8; }
@@ -93,6 +96,7 @@ logbase2(GLuint n)
if (n >= 1<< 2) { n >>= 2; pos += 2; }
if (n >= 1<< 1) { pos += 1; }
return pos;
+#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] mesa: remove support for GCC older than 3.3.0
Hello, Maybe this change should be mentioned in the relnotes ? 2014-12-12 18:04 GMT+01:00 Matt Turner : > > Thanks Timothy. The whole series looks good to me: > > Reviewed-by: Matt Turner > > I'd wait a couple of days for objections before pushing the series. > ___ > 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] Removing out of date Mesa wiki pages
And what about removing the "RadeonProgram" page [1] ? >From my point of view, this page depicts a wrong picture of the Radeon Mesa driver. While I'm pretty sure most of the current and past games runs fine today with r300g/r600g/radeonsi, this is not what one could think at a first look when reading this page. Moreover, the table stops to the Radeon HD6000 series. This page is useful if user can update their input, but the wiki access is restricted. [1] http://xorg.freedesktop.org/wiki/RadeonProgram/ 2015-01-14 9:52 GMT+01:00 Kenneth Graunke : > On Wednesday, January 14, 2015 04:27:30 PM Timothy Arceri wrote: > > Hi all, > > > > Not sure how many of you have come across the webpage "Major Linux > > Problems on the Desktop 2015 edition" [1]. Accurate or not it seems to > > be getting a bit of attention. Anyway Mesa gets a bit of a bashing in > > there although most of the information the author uses to backup their > > claims are out of date Phoronix articles and this Mesa wiki page [2]. > > > > Anyway getting to my point maybe the wiki page should be removed as it > > seems its no longer useful and is being used to spread misinformation. > > > > Tim > > > > [1] > > > http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html > > [2] http://dri.freedesktop.org/wiki/MissingFunctionality/ > > Hooray for fact checking! I'm all for replacing that page - it hasn't been > useful in years. How about replacing it with links to other places: > > Ilia's glxinfo site - shows accurate information about what specific GPUs > support in actual Mesa releases: > http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html > > Current feature development status: > http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt > > which can be helpfully visualized at: > http://mesamatrix.net/ > > --Ken > ___ > 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] Removing out of date Mesa wiki pages
RadeonProgram page just removed. 2015-02-05 20:52 GMT+01:00 Alex Deucher : > On Thu, Feb 5, 2015 at 2:47 PM, Benjamin Bellec > wrote: > > And what about removing the "RadeonProgram" page [1] ? > > > > From my point of view, this page depicts a wrong picture of the Radeon > Mesa > > driver. While I'm pretty sure most of the current and past games runs > fine > > today with r300g/r600g/radeonsi, this is not what one could think at a > first > > look when reading this page. Moreover, the table stops to the Radeon > HD6000 > > series. > > > > This page is useful if user can update their input, but the wiki access > is > > restricted. > > > > [1] http://xorg.freedesktop.org/wiki/RadeonProgram/ > > I'm fine with removing it. It's mostly out of date anyway. > > Alex > > > > > > > 2015-01-14 9:52 GMT+01:00 Kenneth Graunke : > >> > >> On Wednesday, January 14, 2015 04:27:30 PM Timothy Arceri wrote: > >> > Hi all, > >> > > >> > Not sure how many of you have come across the webpage "Major Linux > >> > Problems on the Desktop 2015 edition" [1]. Accurate or not it seems to > >> > be getting a bit of attention. Anyway Mesa gets a bit of a bashing in > >> > there although most of the information the author uses to backup their > >> > claims are out of date Phoronix articles and this Mesa wiki page [2]. > >> > > >> > Anyway getting to my point maybe the wiki page should be removed as it > >> > seems its no longer useful and is being used to spread misinformation. > >> > > >> > Tim > >> > > >> > [1] > >> > > >> > > http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html > >> > [2] http://dri.freedesktop.org/wiki/MissingFunctionality/ > >> > >> Hooray for fact checking! I'm all for replacing that page - it hasn't > >> been > >> useful in years. How about replacing it with links to other places: > >> > >> Ilia's glxinfo site - shows accurate information about what specific > GPUs > >> support in actual Mesa releases: > >> http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html > >> > >> Current feature development status: > >> http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt > >> > >> which can be helpfully visualized at: > >> http://mesamatrix.net/ > >> > >> --Ken > >> ___ > >> 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 > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/radeon: fix r600g build if LLVM is disabled
Tested-by: Benjamin Bellec On Sat, Aug 8, 2015, at 10:05 PM, Marek Olšák wrote: >* From: Marek Olšák <http://lists.freedesktop.org/mailman/listinfo/mesa-dev>> *> >* MESA_LLVM_VERSION_PATCH is undefined. *>* --- *>* src/gallium/drivers/radeon/r600_pipe_common.c | 9 + *>* 1 file changed, 5 insertions(+), 4 deletions(-) *> >* diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c *>* b/src/gallium/drivers/radeon/r600_pipe_common.c *>* index d6b9a01..e50e768 100644 *>* --- a/src/gallium/drivers/radeon/r600_pipe_common.c *>* +++ b/src/gallium/drivers/radeon/r600_pipe_common.c *>* @@ -891,10 +891,11 @@ bool r600_common_screen_init(struct *>* r600_common_screen *rscreen, *> >* ws->query_info(ws, &rscreen->info); *> >* - if (HAVE_LLVM) *>* - snprintf(llvm_string, sizeof(llvm_string), *>* -", LLVM %i.%i.%i", (HAVE_LLVM >> 8) & 0xff, *>* -HAVE_LLVM & 0xff, MESA_LLVM_VERSION_PATCH); *>* +#if HAVE_LLVM *>* + snprintf(llvm_string, sizeof(llvm_string), *>* +", LLVM %i.%i.%i", (HAVE_LLVM >> 8) & 0xff, *>* +HAVE_LLVM & 0xff, MESA_LLVM_VERSION_PATCH); *>* +#endif *> >* snprintf(rscreen->renderer_string, sizeof(rscreen->renderer_string), *>* "%s (DRM %i.%i.%i%s)", *>* -- *>* 2.1.4 *> >* ___ *>* mesa-dev mailing list *>* mesa-dev at lists.freedesktop.org <http://lists.freedesktop.org/mailman/listinfo/mesa-dev> *>* http://lists.freedesktop.org/mailman/listinfo/mesa-dev <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 02/71] target/d3dadapter9: Return Windows like card names
Hello,
Where does this mapping list come from ? Is this an official map (Vendor or
Windows drivers) ? Is that used just for information ?
Because many of them are not really precise, if not completely wrong at all
(eg. the Radeon R400/R500 series names).
Regards.
--
Benjamin
2015-08-16 17:27 GMT+02:00 Axel Davy :
> From: Patrick Rudolph
>
> Add support for multiple cards and fill in Windows like card name, driver
> name and version info.
> Use fallback for unknown vendors and unknown card names.
>
> Reviewed-by: Axel Davy
> Signed-off-by: Patrick Rudolph
> ---
> src/gallium/targets/d3dadapter9/Makefile.am | 1 +
> src/gallium/targets/d3dadapter9/description.c | 324
> ++
> src/gallium/targets/d3dadapter9/drm.c | 76 +++---
> 3 files changed, 359 insertions(+), 42 deletions(-)
> create mode 100644 src/gallium/targets/d3dadapter9/description.c
>
> diff --git a/src/gallium/targets/d3dadapter9/Makefile.am
> b/src/gallium/targets/d3dadapter9/Makefile.am
> index fe5b0b1..e26ca33 100644
> --- a/src/gallium/targets/d3dadapter9/Makefile.am
> +++ b/src/gallium/targets/d3dadapter9/Makefile.am
> @@ -54,6 +54,7 @@ pkgconfigdir = $(libdir)/pkgconfig
> pkgconfig_DATA = d3d.pc
>
> d3dadapter9_la_SOURCES = \
> + description.c \
> getproc.c \
> drm.c
>
> diff --git a/src/gallium/targets/d3dadapter9/description.c
> b/src/gallium/targets/d3dadapter9/description.c
> new file mode 100644
> index 000..c0a8678
> --- /dev/null
> +++ b/src/gallium/targets/d3dadapter9/description.c
> @@ -0,0 +1,324 @@
> +/*
> + * Copyright 2015 Patrick Rudolph
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * on the rights to use, copy, modify, merge, publish, distribute, sub
> + * license, and/or sell copies of the Software, and to permit persons to
> whom
> + * the Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
> SHALL
> + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE. */
> +
> +#include
> +#include "adapter9.h"
> +
> +#define DBG_CHANNEL DBG_ADAPTER
> +
> +/* prototypes */
> +void
> +d3d_match_vendor_id( D3DADAPTER_IDENTIFIER9* drvid,
> +unsigned fallback_ven,
> +unsigned fallback_dev,
> +const char* fallback_name );
> +void d3d_fill_driver_version(D3DADAPTER_IDENTIFIER9* drvid);
> +void d3d_fill_cardname(D3DADAPTER_IDENTIFIER9* drvid);
> +
> +enum d3d_vendor_id
> +{
> +HW_VENDOR_SOFTWARE = 0x,
> +HW_VENDOR_AMD = 0x1002,
> +HW_VENDOR_NVIDIA= 0x10de,
> +HW_VENDOR_VMWARE= 0x15ad,
> +HW_VENDOR_INTEL = 0x8086,
> +};
> +
> +struct card_lookup_table {
> +const char *mesaname;
> +const char *d3d9name;
> +}
> +cards_amd[] = {
> +{"HAWAII", "AMD Radeon R9 290"},
> +{"KAVERI", "AMD Radeon(TM) R7 Graphics"},
> +{"KABINI", "AMD Radeon HD 8400 / R3 Series"},
> +{"BONAIRE", "AMD Radeon HD 8770"},
> +{"OLAND", "AMD Radeon HD 8670"},
> +{"HAINAN", "AMD Radeon HD 8600M Series"},
> +{"TAHITI", "AMD Radeon HD 7900 Series"},
> +{"PITCAIRN","AMD Radeon HD 7800 Series"},
> +{"CAPE VERDE", "AMD Radeon HD 7700 Series"},
> +{"ARUBA", "AMD Radeon HD 7660D"},
> +{"CAYMAN", "AMD Radeon HD 6900 Series"},
> +{"BARTS", "AMD Radeon HD 6800 Series"},
> +{"TURKS", "AMD Radeon HD 6600 Series"},
> +{"SUMO2", "AMD Radeon HD 6410D"},
> +{"SUMO","AMD Radeon HD 6550D"},
> +{"CAICOS", "AMD Radeon HD 6400 Series"},
> +{"PALM","AMD Radeon HD 6300 series Graphics"},
> +{"HEMLOCK", "ATI Radeon HD 5900 Series"},
> +{"CYPRESS", "ATI Radeon HD 5800 Series"},
> +{"JUNIPER", "ATI Radeon HD 5700 Series"},
> +{"REDWOOD",
Re: [Mesa-dev] [PATCH 2/2] r600g: Enable GL_ARB_gpu_shader5 extension
Hi Glenn, The series doesn't apply on current master. Regard. -- Benjamin 2015-10-07 19:00 GMT+02:00 Ilia Mirkin : > On Wed, Oct 7, 2015 at 12:53 PM, Marek Olšák wrote: > > On Wed, Oct 7, 2015 at 5:17 PM, Glenn Kennard > wrote: > >> Signed-off-by: Glenn Kennard > >> --- > >> Now that SB supports the GS5 features we can safely enable the > >> extension. > >> > >> Note that gallium state tracker clamps the GLSL language / GL version > >> since GL_ARB_tessellation_shader isn't implemented yet. > > > > Where is it clamped? > > There used to be a clamp in the st, but I'm not sure that it's still > there. However _mesa_compute_version does set the GLSL version to the > right thing now. > > -ilia > ___ > 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 2/2] r600g: Enable GL_ARB_gpu_shader5 extension
Le 07/10/2015 19:13, Glenn Kennard a écrit : > On Wed, 07 Oct 2015 19:04:15 +0200, Benjamin Bellec > wrote: > >> Hi Glenn, >> >> The series doesn't apply on current master. >> >> Regard. >> > > It's not meant to apply directly on master. Quoting from the notes in > patch 1/2: > > This patch depends on prior patch: > r600g/sb: Support gs5 sampler indexing > > > /Glenn OK sorry, I read too quickly. Is that normal glxinfo still reports GLSL 330 ? With your series applied I still get : OpenGL renderer string: Gallium 0.4 on AMD CYPRESS (DRM 2.42.0) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel (git-6ed8fd3) OpenGL core profile shading language version string: 3.30 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/71] target/d3dadapter9: Return Windows like card names
Don't hold your commit because of me. I haven't the skills to review this code. I just saw this mapping and asking myself about it. It can be be modified later if needed in any case. 2015-08-21 22:09 GMT+02:00 Axel Davy : > As far as I know, the mapping is not an official one. > > Games usually do not use the card name to apply > card specific workarounds, instead they use the vendor > or the device id. > > However the names are sometimes used in configuration files > to match the user set configuration to a card (and reset if the > card is changed). > > In general in game settings you will see the name advertised. > > Some apps may even have other usages of the names. > > Besides advertising the Windows like names, we want add in the future > an easy way to change the card advertised. For example to advertise older > card > of your vendor, or advertise another vendor (some games do disable > some features for some cards). > > Yours, > > Axel Davy > > On 17/08/2015 19:30, Benjamin Bellec write : > > Hello, >> >> Where does this mapping list come from ? Is this an official map (Vendor >> or Windows drivers) ? Is that used just for information ? >> Because many of them are not really precise, if not completely wrong at >> all (eg. the Radeon R400/R500 series names). >> >> Regards. >> >> -- >> Benjamin >> >> >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fix temperature display sign in hud
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 5 +
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
src/gallium/include/pipe/p_defines.h | 1 +
src/mesa/state_tracker/st_cb_perfmon.c| 5 +
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..8cbd322 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
{" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+ static const char *temperature_units[] = {"C"};
const char **units;
unsigned max_unit;
@@ -267,6 +268,10 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
max_unit = ARRAY_SIZE(hz_units)-1;
units = hz_units;
break;
+ case PIPE_DRIVER_QUERY_TYPE_TEMPERATURE:
+ max_unit = ARRAY_SIZE(temperature_units)-1;
+ units = temperature_units;
+ break;
default:
if (max_value == 100) {
max_unit = ARRAY_SIZE(percent_units)-1;
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..d6155ac 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE,
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size},
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
- {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+ {"temperature", R600_QUERY_GPU_TEMPERATURE, {120},
PIPE_DRIVER_QUERY_TYPE_TEMPERATURE},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
};
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 88e37e9..2b0c6be 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -821,6 +821,7 @@ enum pipe_driver_query_type
PIPE_DRIVER_QUERY_TYPE_BYTES= 4,
PIPE_DRIVER_QUERY_TYPE_MICROSECONDS = 5,
PIPE_DRIVER_QUERY_TYPE_HZ = 6,
+ PIPE_DRIVER_QUERY_TYPE_TEMPERATURE = 7,
};
enum pipe_driver_query_group_type
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 1bb5be3..2eec99b 100644
--- a/src/mesa/state_tracker/st_cb_perfmon.c
+++ b/src/mesa/state_tracker/st_cb_perfmon.c
@@ -383,6 +383,11 @@ st_init_perfmon(struct st_context *st)
c->Maximum.f = 100.0f;
c->Type = GL_PERCENTAGE_AMD;
break;
+case PIPE_DRIVER_QUERY_TYPE_TEMPERATURE:
+ c->Minimum.u32 = 0;
+ c->Maximum.u32 = 120;
+ c->Type = GL_UNSIGNED_INT;
+ break;
default:
unreachable("Invalid driver query type!");
}
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] fix temperature display sign in hud
Yes I meant "unit", "sign" is a bad translation. In gallium/hud, the temperature is displayed as a percentage, which is quite confusing. But maybe there is better and simpler approach to fix that. I do not really understand the code so I tried to copy other part of the code. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it
Signed-off-by: Benjamin Bellec
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE,
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size},
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
- {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+ {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
};
--
2.4.3
From 87a3e9a0fca72facb840d8c450fe9755b41e3b83 Mon Sep 17 00:00:00 2001
From: Benjamin Bellec
Date: Fri, 4 Sep 2015 20:02:23 +0200
Subject: [PATCH v2 2/2] gallium/hud: display the temperature unit
To: mesa-dev@lists.freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
{" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+ static const char *temperature_units[] = {"C"};
const char **units;
unsigned max_unit;
@@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
if (max_value == 100) {
max_unit = ARRAY_SIZE(percent_units)-1;
units = percent_units;
+ } else if (max_value == 125) {
+ max_unit = ARRAY_SIZE(temperature_units)-1;
+ units = temperature_units;
} else {
max_unit = ARRAY_SIZE(metric_units)-1;
units = metric_units;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it
Forgot this one.
I will resend correctly, just trying to understand how git-format-patch and
git-send-mail works...
2015-09-04 20:18 GMT+02:00 Benjamin Bellec :
> Signed-off-by: Benjamin Bellec
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index ed5d1da..2a8d906 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct
> pipe_screen *screen,
> {"VRAM-usage", R600_QUERY_VRAM_USAGE,
> {rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
> {"GTT-usage", R600_QUERY_GTT_USAGE,
> {rscreen->info.gart_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
> {"GPU-load", R600_QUERY_GPU_LOAD, {100}},
> - {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
> + {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
> {"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0},
> PIPE_DRIVER_QUERY_TYPE_HZ},
> {"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0},
> PIPE_DRIVER_QUERY_TYPE_HZ},
> };
> --
> 2.4.3
>
>
> From 87a3e9a0fca72facb840d8c450fe9755b41e3b83 Mon Sep 17 00:00:00 2001
> From: Benjamin Bellec
> Date: Fri, 4 Sep 2015 20:02:23 +0200
> Subject: [PATCH v2 2/2] gallium/hud: display the temperature unit
> To: mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org
>
> Signed-off-by: Benjamin Bellec
> ---
> src/gallium/auxiliary/hud/hud_context.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/auxiliary/hud/hud_context.c
> b/src/gallium/auxiliary/hud/hud_context.c
> index 95eed26..71529bc 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t
> max_value,
> static const char *hz_units[] =
>{" Hz", " KHz", " MHz", " GHz"};
> static const char *percent_units[] = {"%"};
> + static const char *temperature_units[] = {"C"};
>
> const char **units;
> unsigned max_unit;
> @@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t
> max_value,
>if (max_value == 100) {
> max_unit = ARRAY_SIZE(percent_units)-1;
> units = percent_units;
> + } else if (max_value == 125) {
> + max_unit = ARRAY_SIZE(temperature_units)-1;
> + units = temperature_units;
>} else {
> max_unit = ARRAY_SIZE(metric_units)-1;
> units = metric_units;
> --
> 2.4.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it
Signed-off-by: Benjamin Bellec
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE,
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size},
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
- {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+ {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0},
PIPE_DRIVER_QUERY_TYPE_HZ},
};
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
{" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+ static const char *temperature_units[] = {"C"};
const char **units;
unsigned max_unit;
@@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
if (max_value == 100) {
max_unit = ARRAY_SIZE(percent_units)-1;
units = percent_units;
+ } else if (max_value == 125) {
+ max_unit = ARRAY_SIZE(temperature_units)-1;
+ units = temperature_units;
} else {
max_unit = ARRAY_SIZE(metric_units)-1;
units = metric_units;
--
2.4.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit
Currently, the temperature is displayed with a "%" symbol in gallium/hud,
which is quite odd.
Marek suggested to only change the value "100" to another value so that
this symbol is no more displayed. That works very well. This is the patch
#1. I choose "125" because it can be divided nicely by 5, then the
threshold displayed on the hud graph are 25/50/75/100/etc. And also because
with this, the actual temperature value is generally in the middle of the
graph.
This second patch is totally optional. It "catch" the value "125" in order
to display a "C" instead of nothing.
Ref. your suggestion on PIPE_DRIVER_QUERY_TYPE_TEMPERATURE, I'm not skilled
enough to answer.
2015-09-04 20:42 GMT+02:00 Brian Paul :
> On 09/04/2015 12:30 PM, Benjamin Bellec wrote:
>
>> Signed-off-by: Benjamin Bellec
>> ---
>> src/gallium/auxiliary/hud/hud_context.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>> b/src/gallium/auxiliary/hud/hud_context.c
>> index 95eed26..71529bc 100644
>> --- a/src/gallium/auxiliary/hud/hud_context.c
>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>> @@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t
>> max_value,
>> static const char *hz_units[] =
>> {" Hz", " KHz", " MHz", " GHz"};
>> static const char *percent_units[] = {"%"};
>> + static const char *temperature_units[] = {"C"};
>>
>> const char **units;
>> unsigned max_unit;
>> @@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t
>> max_value,
>> if (max_value == 100) {
>>max_unit = ARRAY_SIZE(percent_units)-1;
>>units = percent_units;
>> + } else if (max_value == 125) {
>> + max_unit = ARRAY_SIZE(temperature_units)-1;
>> + units = temperature_units;
>> } else {
>>max_unit = ARRAY_SIZE(metric_units)-1;
>>units = metric_units;
>>
>>
>
> This seems like a bit of a magic number approach here. At the very least,
> this magic value should be documented somewhere.
> PIPE_DRIVER_QUERY_TYPE_TEMPERATURE seems better to me, actually.
>
> -Brian
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Adaptive Vsync
Hello Lauri, I saw that your patch implementing adaptive vsync is not committed to mesa. Ref, http://lists.freedesktop.org/archives/mesa-dev/2013-December/050184.html Why not ? Is there any issue with it ? As a end user, adaptive vsync seems a nice feature. But maybe I'm not aware of drawbacks. Regards. -- Benjamin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit
Le 05/09/2015 10:19, Samuel Pitoiset a écrit : > > On 09/04/2015 08:57 PM, Benjamin Bellec wrote: >> Currently, the temperature is displayed with a "%" symbol in >> gallium/hud, which is quite odd. >> Marek suggested to only change the value "100" to another value so >> that this symbol is no more displayed. That works very well. This is >> the patch #1. I choose "125" because it can be divided nicely by 5, >> then the threshold displayed on the hud graph are 25/50/75/100/etc. >> And also because with this, the actual temperature value is generally >> in the middle of the graph. >> >> This second patch is totally optional. It "catch" the value "125" in >> order to display a "C" instead of nothing. >> >> Ref. your suggestion on PIPE_DRIVER_QUERY_TYPE_TEMPERATURE, I'm not >> skilled enough to answer. >> > Your first attempt at writing this patch introduced this > PIPE_DRIVER_QUERY_TYPE_TEMPERATURE. > Please, re-introduce it correctly. :) I don't think to have the skills to do that. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
