[Mesa-dev] [PATCH] gallivm: Fix build with llvm-3.0 and llvm-2.9
This is a follow up to 40ae214067673edbda79371969d1730b6194d83e. As Vinson Lee noticed, those changes were made in 3.0svn not 2.9rc. So the previous patch fixed 3.0svn, but broke build with 2.9. I only checked 2.8 and the snapshot. Sorry for that. Signed-off-by: Tobias Droste --- src/gallium/auxiliary/gallivm/lp_bld_debug.cpp |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp index 76d63ce..0b724a3 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp @@ -209,12 +209,12 @@ lp_disassemble(const void* func) raw_debug_ostream Out; TargetMachine *TM = T->createTargetMachine(Triple, ""); -#if HAVE_LLVM >= 0x0209 +#if HAVE_LLVM >= 0x0300 unsigned int AsmPrinterVariant = AsmInfo->getAssemblerDialect(); #else int AsmPrinterVariant = AsmInfo->getAssemblerDialect(); #endif -#if HAVE_LLVM >= 0x0209 +#if HAVE_LLVM >= 0x0300 OwningPtr Printer( T->createMCInstPrinter(*TM, AsmPrinterVariant, *AsmInfo)); #elif HAVE_LLVM >= 0x0208 -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Moving from macro to inline for list manipulation
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote: > Hi, > > One short coming of macro has keep entertaining me until i figure out > what was wrong, here is > a simple scenario : > > Macro can lead to hard to debug list bugs. For instance consider > the following : > LIST_ADD(item, list->prev) > 3 instruction of the macro became : > (list->prev)->next->prev = item > which is equivalent to : > list->prev = item > Thus list prev field changes and next instruction in the macro > (list->prev)->next = item > became : > item->next = item > And you endup with list corruption, other case lead to similar > list corruption. Inline function are not affected by this short > coming > > Thus i propose to switch list manipulation from macro to inline > function, attached patch does exactly that. If there is no objection > in next couple of week i will merge it. (to avoid mass renaming it > keeps the macro that just wrap the functions it also add a bunch of > new list walking helper) I'm ok with this. Those macros were supposed to be quick & dirty, but they've been around much longer than I ever expected... Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Moving from macro to inline for list manipulation
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote: > Hi, > > One short coming of macro has keep entertaining me until i figure out > what was wrong, here is > a simple scenario : > > Macro can lead to hard to debug list bugs. For instance consider > the following : > LIST_ADD(item, list->prev) > 3 instruction of the macro became : > (list->prev)->next->prev = item > which is equivalent to : > list->prev = item > Thus list prev field changes and next instruction in the macro > (list->prev)->next = item > became : > item->next = item > And you endup with list corruption, other case lead to similar > list corruption. Inline function are not affected by this short > coming > > Thus i propose to switch list manipulation from macro to inline > function, attached patch does exactly that. If there is no objection > in next couple of week i will merge it. (to avoid mass renaming it > keeps the macro that just wrap the functions it also add a bunch of > new list walking helper) Hmm, another good thing to do would be to eliminate the u_simple_list.h code which is what I initially read this as being about. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : OpenCL over Gallium3D
Denis, This is a great proposal. I have a few comments and suggestions, though. I think the OpenCL state tracker should not be implemented using fragment shaders, framebuffers, and generally the 3D engine as is exposed via pipe_context. It might be useful for some initial experiments, but it's kinda non-natural, because there is hardware which can do OpenCL and/or CUDA more or less natively. So I think we should come up with a separate set of pipe_context functions for running compute kernels. This will be an advantage for you, because you will be able to design you own Gallium driver functions, assuming you commit to working on the OpenCL state tracker, of course. Besides reading the OpenCL spec, you might need to take a look at these interfaces when designing the Gallium interface for compute kernels: - DirectCompute and compute shaders (part of DirectX 11) - CUDA Especially you will need to make sure that the compute subset of DirectX 11 will be implementable (at least in theory). I only have experience with CUDA, so here are some ideas on new driver entrypoints that could be added to pipe_context, from the top of my head: void *create_compute_shader(...); // like shaders void bind_compute_shader(...); void delete_compute_shader(...); // set_constant_buffer can be reused void set_compute_shader_sampler_states(ctx, num, states); void set_compute_shader_sampler_views(ctx, num, views); void set_compute_shader_readwrite_resources(ctx, num, resources); // like samplers, but for read-write resources void run_compute_shader(ctx, info); // anything not specific to draw_vbo can be reused too, like transfers, resource_copy_region, etc. Don't take the list literally, I haven't given it much thought. Also, I wouldn't bother with TGSI at the beginning. Let's stick to the LLVM IR for simplicity and using llvmpipe to execute the compute kernels on a CPU, even that is a lot of work for GSoC. Once it works, we can resolve any remaining issues like what IR will be used etc. The complete OpenCL implementation will take more than a few months, so let's concentrate on making something work first. BTW I haven't taken a look at the clover codebase, so some of my comments might be a little off. Marek On Sat, Mar 26, 2011 at 9:52 PM, Denis Steckelmacher wrote: > Hello, > > After some messages on this list, I reconsidered my GSoC proposal and > decided > to give a try at an OpenCL state tracker. I will base my work on the Clover > branch of Mesa. > > I read its code, which is very well-done and clean, but I saw one big > difficulty : I don't know how to translate LLVM IR to TGSI. The big problem > is > that TGSI is made mostly with OpenGL in mind. We can use it to decode video > frames using vertex and fragment shader stages, but using it to run on the > GPU > the complex output given by LLVM, and without using any part of the OpenGL > pipeline (OpenCL can be used to do mathematics, and that doesn't draw > anything > on the screen), is tricky. > > The problem is how OpenCL can upload data on the GPU and then download the > computed results. One solution may be to create one or more textures > containing the input data (maybe one texture by input data type), and then > use > a fragment shader to compute the resulting values and to put them in a > render > buffer that will never be drawn on screen but instead downloaded from the > GPU > and sent back to the application. > > I don't know if it would be possible to do things like that, especially > considering that precise results across all graphics cards may be difficult > to > get with OpenGL. An other problem of this LLVM to TGSI conversion is that > the > TGSI instruction set is not completely implemented on all the pipe drivers, > and that unimplemented instructions may be needed by a specific LLVM IR > instruction. > > I'm open to any suggestion regarding this OpenCL state tracker. If you say > it > will be very difficult to do that during the summer, I think I will apply > to > work on the OpenGL 3+ support in Mesa (without doing a new state tracker) > and > the GLSL compiler. > > Best regards, > Denis Steckelmacher. > ___ > 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] [Bug 23884] Unigine Tropics demo requires float textures
https://bugs.freedesktop.org/show_bug.cgi?id=23884 --- Comment #11 from imamdxl8...@gmail.com 2011-03-29 04:06:23 PDT --- (In reply to comment #10) > The float textures are implemented and maintained in this branch: > > http://cgit.freedesktop.org/~mareko/mesa/?h=floating2 Can I have a patch for this, so that I can tryout the demo. Is it supported on Intel GMA 4500? Thank you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 23884] Unigine Tropics demo requires float textures
https://bugs.freedesktop.org/show_bug.cgi?id=23884 --- Comment #12 from Artem S. Tashkinov 2011-03-29 04:14:27 PDT --- (In reply to comment #11) > (In reply to comment #10) > > The float textures are implemented and maintained in this branch: > > > > http://cgit.freedesktop.org/~mareko/mesa/?h=floating2 > > Can I have a patch for this, so that I can tryout the demo. > Is it supported on Intel GMA 4500? > > Thank you AFAIK Intel Mesa drivers don't yet support float textures, so you are out of luck. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 23884] Unigine Tropics demo requires float textures
https://bugs.freedesktop.org/show_bug.cgi?id=23884 --- Comment #13 from Marek Olšák 2011-03-29 04:25:37 PDT --- (In reply to comment #11) > Is it supported on Intel GMA 4500? The only driver capable of running Unigine Tropics with the floating2 branch is r300g. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : Video decoding state tracker for Gallium3d
On Mon, 2011-03-28 at 15:59 -0700, Corbin Simpson wrote: > We talked about it already, in person, at XDC a few years ago. The > basic agreement was that Theora was the only reasonable codec that > could be shipped in Fedora and Debian; other codecs would probably be > #define'd or commented out. I'm not sure if this is something we need > to worry about immediately, especially if you're targeting VP8, which > is roughly as safe as Theora. I don't know about Fedora, but Debian is (for quite a while now) shipping a H264 decoder. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : OpenCL over Gallium3D
> Denis, > > This is a great proposal. I have a few comments and suggestions, though. > > I think the OpenCL state tracker should not be implemented using fragment > shaders, framebuffers, and generally the 3D engine as is exposed via > pipe_context. It might be useful for some initial experiments, but it's > kinda non-natural, because there is hardware which can do OpenCL and/or CUDA > more or less natively. So I think we should come up with a separate set of > pipe_context functions for running compute kernels. This will be an > advantage for you, because you will be able to design you own Gallium > driver functions, assuming you commit to working on the OpenCL state > tracker, of course. > > Besides reading the OpenCL spec, you might need to take a look at these > interfaces when designing the Gallium interface for compute kernels: > - DirectCompute and compute shaders (part of DirectX 11) > - CUDA > Especially you will need to make sure that the compute subset of DirectX 11 > will be implementable (at least in theory). > > I only have experience with CUDA, so here are some ideas on new driver > entrypoints that could be added to pipe_context, from the top of my head: > > void *create_compute_shader(...); // like shaders > void bind_compute_shader(...); > void delete_compute_shader(...); > // set_constant_buffer can be reused > void set_compute_shader_sampler_states(ctx, num, states); > void set_compute_shader_sampler_views(ctx, num, views); > void set_compute_shader_readwrite_resources(ctx, num, resources); // like > samplers, but for read-write resources > void run_compute_shader(ctx, info); > // anything not specific to draw_vbo can be reused too, like transfers, > resource_copy_region, etc. > > Don't take the list literally, I haven't given it much thought. > > Also, I wouldn't bother with TGSI at the beginning. Let's stick to the LLVM > IR for simplicity and using llvmpipe to execute the compute kernels on a > CPU, even that is a lot of work for GSoC. Once it works, we can resolve any > remaining issues like what IR will be used etc. The complete OpenCL > implementation will take more than a few months, so let's concentrate on > making something work first. > > BTW I haven't taken a look at the clover codebase, so some of my comments > might be a little off. > > Marek Hello, Using llvmpipe directly is a great idea especially considering that I will have to work two weeks on a small laptop without a properly supported graphics card. The plan would be to : * Implement a small Gallium interface to pass LLVM IR directly to llvmpipe, if an existing interface doesn't exist yet. * Implement the OpenCL state tracker using an abstraction layer between the compiler and the running software/hardware. Implementing proper accelerated support will be "as simple" as adding a new implementation of an interface, plus the work needed in Gallium. I have to send my official proposal today or tomorrow because I'm going on a school trip on 31th march. I will be back on 7th april, just one day before the application deadline. I really like your idea, it will give the chance to many users to use OpenCL and to develop with it without being required to use proprietary drivers on supported graphics card. Even users of Intel hardware (that lack a Gallium3D pipe driver) will be able to enjoy OpenCL ! Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] decoupling XCB from Mesa
On Tue, Mar 29, 2011 at 2:28 AM, Srini wrote: > So, can you please suggest me which is the exact API or place to do this > change. > is there any such pointer for FAKE_FRONT_LEFT been maintained in kernel DRM > module? or some where in x server kernel module? if it is so i can get some > reference from there. > > please suggest me. > > Regards, > Srini. > Question is what do you want to do exactly ? If you want to use mesa software renderer i suggest you use the llvmpipe one and add proper hook for your window system into mesa/src/gallium/state_tracker/egl/ (create a subdir their for your window system and look at the drm folder for the simpler example). If you also want to use the classic mesa driver than you need either to add a new API to all of them (mesa/src/mesa/drivers/dri/) or fake the dri interface (likely easier thought i can't remember if the dri stuff in driver do any X/DRI2 protocol directly or just use the callback stuff in mesa/include/GL/internal/dri_interface.h) in this case the egl implementation need to call flush callback of __DRI2flushExtensionRec also the invalidate callback will be call through glx_dri2 code. I think the biggest issue in faking dri api is that a lot of code is in the src/glx stuff and this code callback into the driver for things to happen. Basicly you will have to make sure that all call to appropriate dri_interface.h callback are made corresponding to each event (swapbuffer, new surface ...). Gallium driver are more easier to work with, basicly just add you window specific code into the mesa/src/gallium/state_tracker/egl/ Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
On Mon, 28 Mar 2011 22:59:31 -0700, Tom Stellard wrote: > This pass scans programs for instructions that read registers that have > not been written and replaces these reads with a read from a constant > register with the value of zero. This pass prevents phantom > dependencies from being introduced by the register allocator and > improves the efficiency of subsequent optimization passes. I'm not sure why optimizing a program with undefined behavior (using undefined register values) is interesting. It just seems like an opportunity to make a mistake and break programs that should have defined behavior. pgp6vHWM61sWN.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Gallium softpipe driver build instructions
Hi All, Am using Mesa 7.8.2. Can anyone please send out the instructions to building a gallium based softpipe driver? thanks K ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
On Tue, Mar 29, 2011 at 1:59 AM, Tom Stellard wrote:
> This pass scans programs for instructions that read registers that have
> not been written and replaces these reads with a read from a constant
> register with the value of zero. This pass prevents phantom
> dependencies from being introduced by the register allocator and
> improves the efficiency of subsequent optimization passes.
> ---
> src/mesa/program/prog_optimize.c | 81
> ++
> 1 files changed, 81 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/program/prog_optimize.c
> b/src/mesa/program/prog_optimize.c
> index b5f0fb3..bc698fb 100644
> --- a/src/mesa/program/prog_optimize.c
> +++ b/src/mesa/program/prog_optimize.c
> @@ -30,6 +30,7 @@
> #include "program.h"
> #include "prog_instruction.h"
> #include "prog_optimize.h"
> +#include "prog_parameter.h"
> #include "prog_print.h"
>
>
> @@ -1225,6 +1226,85 @@ print_it(struct gl_context *ctx, struct gl_program
> *program, const char *txt) {
> }
> #endif
>
> +/** This pass searches for registers that are read before they are written
> + * and replaces reads from these registers with a read from a constant
> + * register with the value of zero. This pass will not change the program
> + * if it has already been run, so it only needs to be run once per program.
> + *
> + * When CMP instructions are translated from GLSL IR to Mesa IR, usually
> + * source register 1 or source register 2 is set to value of the destination
> + * register. When the registers are reallocated by
> + * _mesa_reallocate_registers() there is the possibility of creating phantom
> + * dependencies where a source register is remapped so that it reads from a
> + * register that has been written by an instruction that is no longer live.
> + * Here is an example:
> + *
> + * 0: MUL TEMP[0], CONST[0] IN[0]
> + * 1: RCP TEMP[1], TEMP[0]
> + * 2: CMP TEMP[2], TEMP[1] CONST[0] TEMP[2]
> + * ...
> + *
> + * _mesa_reallocate_registers will remap registers 0->0, 1->1, 2->0 and
> + * the program will look like this:
> + *
> + * 0: MUL TEMP[0], CONST[0], IN[0]
> + * 1: RCP TEMP[1], TEMP[0]
> + * 2: CMP TEMP[0], TEMP[1] CONST[0] TEMP[0]
> + * ...
> + *
> + * This creates a phantom dependency, because instruction 2 now depends
> + * on the result of instruction 0 which was not the case in the original
> + * program.
> + */
> +static void
> +_mesa_reads_without_writes(struct gl_program * program)
> +{
> + GLfloat zeroArray[4] = {0.0f, 0.0f, 0.0f, 0.0f};
> + GLuint zeroSwizzle;
> + struct prog_src_register zeroReg;
> + GLuint regWrites[REG_ALLOCATE_MAX_PROGRAM_TEMPS];
> + GLuint i;
> +
> + if (dbg) {
> + printf("Optimize: Begin reads without writes\n");
> + _mesa_print_program(program);
> + }
> +
> + for (i = 0; i < REG_ALLOCATE_MAX_PROGRAM_TEMPS; i++) {
> + regWrites[i] = 0;
> + }
> +
> + memset(&zeroReg, 0, sizeof(zeroReg));
> + zeroReg.File = PROGRAM_CONSTANT;
> + zeroReg.Index = _mesa_add_unnamed_constant(program->Parameters, zeroArray,
> + 1, &zeroSwizzle);
> + zeroReg.Swizzle = zeroSwizzle;
> +
> + for (i = 0; i < program->NumInstructions; i++) {
> + struct prog_instruction *inst = program->Instructions + i;
> + GLuint numSrc = _mesa_num_inst_src_regs(inst->Opcode);
> + GLuint j;
> + for (j = 0; j < numSrc; j++) {
> + if (inst->SrcReg[j].File == PROGRAM_TEMPORARY) {
> + const GLuint index = inst->SrcReg[j].Index;
> + if (!inst->SrcReg[j].RelAddr
> + && !(regWrites[index] & get_src_arg_mask(inst, j, NO_MASK)))
> {
> + inst->SrcReg[j] = zeroReg;
> + }
> + }
> + }
> + if (inst->DstReg.File == PROGRAM_TEMPORARY) {
> + if (inst->DstReg.RelAddr) {
> + return;
> + }
> + regWrites[inst->DstReg.Index] |= inst->DstReg.WriteMask;
> + }
> + }
> + if (dbg) {
> + printf("Optimize: End reads without writes\n");
> + _mesa_print_program(program);
> + }
> +}
>
> /**
> * Apply optimizations to the given program to eliminate unnecessary
> @@ -1235,6 +1315,7 @@ _mesa_optimize_program(struct gl_context *ctx, struct
> gl_program *program)
> {
> GLboolean any_change;
>
> + _mesa_reads_without_writes(program);
> /* Stop when no modifications were output */
> do {
> any_change = GL_FALSE;
> --
> 1.7.3.4
>
Long time since i have look into mesa shader but your code seems to
completely ignore program flow and thus might face wrong positive. For
instance :
Consider a flow graph, in this flow graph consider B0 & B1 two
different block where B0 dominate B1 (ie in all execution flow
instruction that endup in B1 also goes through B0 before). Now
consider some instruction using temp 10 (with temp 10 never being used
outside B0 & B1) in B1 and some instruction defining temp 10 in B0. If
B1 instruction are first in the gl_program instructions array the
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
On Tue, Mar 29, 2011 at 10:19:13AM -0700, Eric Anholt wrote: > On Mon, 28 Mar 2011 22:59:31 -0700, Tom Stellard wrote: > > This pass scans programs for instructions that read registers that have > > not been written and replaces these reads with a read from a constant > > register with the value of zero. This pass prevents phantom > > dependencies from being introduced by the register allocator and > > improves the efficiency of subsequent optimization passes. > > I'm not sure why optimizing a program with undefined behavior (using > undefined register values) is interesting. It just seems like an > opportunity to make a mistake and break programs that should have > defined behavior. The main problem I am trying to fix with this is that these reads from undefined register values are causing the Mesa IR register allocator to alter the structure of the program by adding dependencies between instructions that should not be there. This is limiting the number of optimization opportunities that are available to drivers, especially on architectures like r300 that need IFs lowered and thus use a lot of CMP instructions. The other solution I considered was giving drivers the option to disable the register allocation pass in Mesa IR, but each driver would still need to do something like this anyway, so I figured it was better to just push this pass up to Mesa IR. -Tom Stellard ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
tOn Tue, 29 Mar 2011 11:35:33 -0700, Tom Stellard wrote: > On Tue, Mar 29, 2011 at 10:19:13AM -0700, Eric Anholt wrote: > > On Mon, 28 Mar 2011 22:59:31 -0700, Tom Stellard wrote: > > > This pass scans programs for instructions that read registers that have > > > not been written and replaces these reads with a read from a constant > > > register with the value of zero. This pass prevents phantom > > > dependencies from being introduced by the register allocator and > > > improves the efficiency of subsequent optimization passes. > > > > I'm not sure why optimizing a program with undefined behavior (using > > undefined register values) is interesting. It just seems like an > > opportunity to make a mistake and break programs that should have > > defined behavior. > > The main problem I am trying to fix with this is that these reads > from undefined register values are causing the Mesa IR register allocator > to alter the structure of the program by adding dependencies between > instructions that should not be there. This is limiting the number of > optimization opportunities that are available to drivers, especially > on architectures like r300 that need IFs lowered and thus use a lot of > CMP instructions. Why do you have programs reading undefined values? Why are these programs interesting? pgpqFaCrqV9Hg.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/dri: Don't leak bind counts on failure
Signed-off-by: Jakob Bornecrantz
NOTE: This is a candidate for the 7.10 branch.
---
.../state_trackers/dri/common/dri_context.c|6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_context.c
b/src/gallium/state_trackers/dri/common/dri_context.c
index e23c1bc..d23655a 100644
--- a/src/gallium/state_trackers/dri/common/dri_context.c
+++ b/src/gallium/state_trackers/dri/common/dri_context.c
@@ -173,12 +173,14 @@ dri_make_current(__DRIcontext * cPriv,
if (old_st && old_st != ctx->st)
old_st->flush(old_st, ST_FLUSH_FRONT, NULL);
+ /* check if either is not set */
+ if (!driDrawPriv ^ !driReadPriv)
+ return GL_FALSE;
+
++ctx->bind_count;
if (!driDrawPriv && !driReadPriv)
return ctx->stapi->make_current(ctx->stapi, ctx->st, NULL, NULL);
- else if (!driDrawPriv || !driReadPriv)
- return GL_FALSE;
draw->context = ctx;
if (ctx->dPriv != driDrawPriv) {
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] st/dri: Update the old drawable context bindings in make current
We never removed the bindings from the drawables in the old code, that doesn't seem to cause any troubles and could just be paranioa on my part. Signed-off-by: Jakob Bornecrantz NOTE: This is a candidate for the 7.10 branch. --- .../state_trackers/dri/common/dri_context.c|6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/gallium/state_trackers/dri/common/dri_context.c b/src/gallium/state_trackers/dri/common/dri_context.c index d23655a..0d6b881 100644 --- a/src/gallium/state_trackers/dri/common/dri_context.c +++ b/src/gallium/state_trackers/dri/common/dri_context.c @@ -177,6 +177,12 @@ dri_make_current(__DRIcontext * cPriv, if (!driDrawPriv ^ !driReadPriv) return GL_FALSE; + /* These bindings are setup again below */ + if (ctx->dPriv) + dri_drawable(ctx->dPriv)->context = NULL; + if (ctx->rPriv) + dri_drawable(ctx->rPriv)->context = NULL; + ++ctx->bind_count; if (!driDrawPriv && !driReadPriv) -- 1.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
On Tue, Mar 29, 2011 at 02:16:39PM -0700, Eric Anholt wrote: > t > On Tue, 29 Mar 2011 11:35:33 -0700, Tom Stellard wrote: > > On Tue, Mar 29, 2011 at 10:19:13AM -0700, Eric Anholt wrote: > > > On Mon, 28 Mar 2011 22:59:31 -0700, Tom Stellard > > > wrote: > > > > This pass scans programs for instructions that read registers that have > > > > not been written and replaces these reads with a read from a constant > > > > register with the value of zero. This pass prevents phantom > > > > dependencies from being introduced by the register allocator and > > > > improves the efficiency of subsequent optimization passes. > > > > > > I'm not sure why optimizing a program with undefined behavior (using > > > undefined register values) is interesting. It just seems like an > > > opportunity to make a mistake and break programs that should have > > > defined behavior. > > > > The main problem I am trying to fix with this is that these reads > > from undefined register values are causing the Mesa IR register allocator > > to alter the structure of the program by adding dependencies between > > instructions that should not be there. This is limiting the number of > > optimization opportunities that are available to drivers, especially > > on architectures like r300 that need IFs lowered and thus use a lot of > > CMP instructions. > > Why do you have programs reading undefined values? Why are these > programs interesting? The reason there are reads of undefined values is because of all the conditional assignments generated by the IF to conditional assignment lowering pass. ir_to_mesa transforms conditional assignments to CMP DST, COND SRC0 DST, with the assumption that if the condition fails assigning DST to itself will be a noop. This is normally a safe assumption to make since all bug-free programs should initialize a value before using it in a conditional assignment, if the value is going to be used later in the program. However, the conditional assignments that are generated by the IF lowering pass don't follow this pattern and the DST register is usually uninitialized when the instruction is executed, leading to a read from an undefined value. It seems like the real problem is that there is no good way to translate a GLSL IR conditional assignment to a MESA IR instruction. From what I can tell, the semantics of conditional assignment are: if (cond) assign value else do nothing; and the closest equivalent Mesa IR instruction (CMP) is: if (cond) assign value0 else assign value1 Since this is only an issue on architectures that don't support flow control, I should modify my patch so the 'reads without writes' pass only runs on architectures that don't support flow control. I'm also interested in hearing alternate solutions if anyone has other ideas, because I would really like to get this fixed. -Tom Stellard ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] prog_optimize: Add reads without writes optimization pass
On Tue, Mar 29, 2011 at 02:11:01PM -0400, Jerome Glisse wrote: > > Long time since i have look into mesa shader but your code seems to > completely ignore program flow and thus might face wrong positive. For > instance : > > Consider a flow graph, in this flow graph consider B0 & B1 two > different block where B0 dominate B1 (ie in all execution flow > instruction that endup in B1 also goes through B0 before). Now > consider some instruction using temp 10 (with temp 10 never being used > outside B0 & B1) in B1 and some instruction defining temp 10 in B0. If > B1 instruction are first in the gl_program instructions array then > your algorithm will wrongly believe that temp 10 is never written > before instruction using it. > > IIRC correctly on how mesa ir this case can happen. > Ok, I didn't realize the instructions could be ordered that way in the instruction array. This patch is really only necessary on hardware without support for control flow, so I'll try to modify it so it doesn't run if there are flow control instructions. -Tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium softpipe driver build instructions
Can someone please help out with the instructions. thx K On Tue, 2011-03-29 at 10:33 -0700, kumar vemuri wrote: > Hi All, > > Am using Mesa 7.8.2. Can anyone please send out the instructions > to building a gallium based softpipe driver? > > thanks > K > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] decoupling XCB from Mesa
Hi Jerome, Thanks for Reply, what you said is right for my attempt on software acceleration. I added a folder called "flip" in mesa/src/gallium/state_tracker/egl/ and created the egl software driver called "egl_flip_swrast.so" its working fine. My current attempt is to enable the hardware acceleration, I choose Mesa-7.9,and the configuration i used is "./configure --enable-gles2 --enable-egl --with-egl-platforms=x11 --with-dri-drivers=i965 --with-state-trackers=egl,dri --disable-gallium --disable-glw" This configuration totally disable the gallium driver this means I am using Classic mesa driver, I used the small GLES application to read the flow of the Hardware rendering path, accordingly I mocked the entire flow for my windowing system by faking the egl_dri2.c file, where actually the initialization for x11 and drm are happening, I added the new API "dri2_initialize_flip". The difference between dri2_initialize_flip and dri2_initialize_x11 is, all the calls to XCB are removed, and rather I am using my local library by this way, whole initialization is successful, I have touch few thing in libdrm_intel.so to fake the xcb connection. How I am telling the initialization is successful is because, my gles application returns success in creating shader and vertex program.the final call to glDrawaArray is also success. after glDrawaArray application calls eglSwapBuffers. If I see the eglSwapBuffers implementation it boils to "dri2_copy_region" where they directly delegates to libXCb. From dri2_copy_region the call to "xcb_dri2_copy_region_unchecked" has the source and destination as XCB_DRI2_ATTACHMENT_BUFFER_FAKE_FRONT_LEFT and XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT respectively. What I believe is, final GLES created scene is available in "FAKE_FRONT_LEFT" if by any chance I happen to get the pointer to FAKE_FRONT_LEFT, I can copy the content to my window surface and validate the scene. Sorry for the big mail, i want to put in detail. Happy to hear back. Regards, Srini. From: Jerome Glisse To: Srini Cc: mesa-dev@lists.freedesktop.org Sent: Tue, 29 March, 2011 8:38:07 PM Subject: Re: [Mesa-dev] decoupling XCB from Mesa On Tue, Mar 29, 2011 at 2:28 AM, Srini wrote: > So, can you please suggest me which is the exact API or place to do this > change. > is there any such pointer for FAKE_FRONT_LEFT been maintained in kernel DRM > module? or some where in x server kernel module? if it is so i can get some > reference from there. > > please suggest me. > > Regards, > Srini. > Question is what do you want to do exactly ? If you want to use mesa software renderer i suggest you use the llvmpipe one and add proper hook for your window system into mesa/src/gallium/state_tracker/egl/ (create a subdir their for your window system and look at the drm folder for the simpler example). If you also want to use the classic mesa driver than you need either to add a new API to all of them (mesa/src/mesa/drivers/dri/) or fake the dri interface (likely easier thought i can't remember if the dri stuff in driver do any X/DRI2 protocol directly or just use the callback stuff in mesa/include/GL/internal/dri_interface.h) in this case the egl implementation need to call flush callback of __DRI2flushExtensionRec also the invalidate callback will be call through glx_dri2 code. I think the biggest issue in faking dri api is that a lot of code is in the src/glx stuff and this code callback into the driver for things to happen. Basicly you will have to make sure that all call to appropriate dri_interface.h callback are made corresponding to each event (swapbuffer, new surface ...). Gallium driver are more easier to work with, basicly just add you window specific code into the mesa/src/gallium/state_tracker/egl/ Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
